Bug#774737: unblock: libjpeg9/1:9a-2

[Niels Thykier <niels@thykier.net>]

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