On Thu, Jan 29, 2015 at 08:32:58PM +0100, Niels Thykier wrote: > 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 agree. > I am still not convinced that this is sufficient to turn over the > decision to only have one libjpeg implementation in Jessie. The two previous Debian releases had several libjpeg implementations. Why this change and why now ? I find rather unfair that I spend time packaging libjpeg9 to be told several month later than it would not be included in stable for some unspecified reason. Cheers, -- Bill. <[email protected]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/20150129194037.GA30687@yellowpig
