968 Kb Sun Jan 15 10:25:58 2012 Unix Tape Archive http://www.ijg.org/files/jpegsrc.v8d.tar.gz Reproducible: Always Version 8d 15-Jan-2012 ----------------------- Add cjpeg -rgb option to create RGB JPEG files. Using this switch suppresses the conversion from RGB colorspace input to the default YCbCr JPEG colorspace. This feature allows true lossless JPEG coding of RGB color images. The recommended command for this purpose is currently cjpeg -rgb -block 1 -arithmetic. SmartScale capable decoder (introduced with IJG JPEG 8) required. Thank to Michael Koch for the initial suggestion. Add option to disable the region adjustment in the transupp crop code. Thank to Jeffrey Friedl for the suggestion. Thank to Richard Jones and Edd Dawson for various minor corrections. Thank to Akim Demaille for configure.ac cleanup.
In portage. But you should really be on libjpeg-turbo thesedays as it's the default.
(In reply to comment #1) > In portage. But you should really be on libjpeg-turbo thesedays as it's > the default. > 22 Apr 2012; Samuli Suominen <ssuominen@gentoo.org> -jpeg-8c-r1.ebuild, > -files/Makefile.in.extra: > old May I ask why you are removing a version that is STABILIZED on many archs (bug #401109) ? And why in this case an emerge -uDN world does not downgrade media-libs/jpeg ? emerge is leaving an old and removed version of media-libs/jpeg on the system. Third question : if libjpeg-turbo is now the default, why emerge does not propose me to migrate ?
Yes, libjpeg-turbo is now default but it's fine to leave the system use 8c-r1 (or 8d). None of these have any known issues that would require immediate action. With that said, I've just sent a small news item for review, that's basically just saying: emerge -C jpeg:0 emerge -1 libjpeg-turbo This is just an enchancement. Certainly nothing users should be getting worked up over, as in, you don't *have to do anything*.
(In reply to comment #3) the existence of libjpeg-turbo has no real bearing on keyword policy with jpeg. like any other package, you can't go dropping stable keywords.
(In reply to comment #4) > (In reply to comment #3) > > the existence of libjpeg-turbo has no real bearing on keyword policy with > jpeg. like any other package, you can't go dropping stable keywords. of course it has, it's like moving eg. from ntfsprogs to ntfs3g (just picked recent example). the only exception here is that i've left the obsolete package in tree as a fallback. the fallback doesn't get attention before it's needed. so tree is in consistent state with best possible outcome.
(In reply to comment #5) those examples are nothing alike. the ntfsprogs authors themselves have declared the project obsolete and all development has moved to ntfs3g. libjpeg is not is not obsolete.
(In reply to comment #6) > (In reply to comment #5) > > those examples are nothing alike. the ntfsprogs authors themselves have > declared the project obsolete and all development has moved to ntfs3g. > libjpeg is not is not obsolete. it's not supported to move from system built with libjpeg-turbo, to jpeg, it's compatible only in one direction, and the best way to reflect this is with KEYWORDS. was hoping to leave it in ~arch only for this, but if it's forced stable, there is no other option than drop it from the virtual completely just like we have done for virtual/libffi. leave only one provider, and if the provider gets broken, it can get replaced by media-libs/jpeg again.
