Control: tags -1 moreinfo On 2015-01-28 00:34, Bill Allombert wrote: > On Fri, Jan 23, 2015 at 08:02:38AM +0100, Niels Thykier wrote: >> Hi, >> >> Could you list the features that the turbo-variant is missing, which are >> present in the current version of libjpeg-progs from Wheezy? Are there >> any lacking features beyond the "SmartScale" feature? > > Yes, there are a number of missing features, most importantly, > libjpeg8 libjpeg-progs produces more accurate colors by using a higher quality > sampling. cjpeg and djpeg also provide options for better quality control. > > The "SmartScale" extension is essentially a way to store the scaling > parameter in > the JPEG image so that you do not to specify it when uncompressing the file. > But you can use the scaling code without ever creating an actual JFIF file > with the > SmartScale extension (e.g. when converting to a raster format). > > Cheers, >
As far as I am informed, regular jpegs encoded with libjpeg6 and libjpeg7 in general can be decoded by libjpeg-turbo. Therefore, there should not be an incompatibility issue there. The sole exception should be the use of non-standard DCT block sizes (i.e. any other than 8x8), which are only supported by the IJG version of libjpeg. I am still not convinced that this is sufficient to turn over the decision to only have one libjpeg implementation in Jessie. In regards to the upgrade path, I have conducted a trivial minor test and libjpeg-progs is indeed not migrated automatically to libjpeg-turbo-progs. We will need to find a solution for that problem. At first glance, adding a "Breaks" on the version of libjpeg8 from stable in libjpeg62-turbo looks like it will do the trick. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
