Bug#774737: unblock: libjpeg9/1:9a-2
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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: