Bug#717076: tech-ctte: Decide what jpeg library the Debian project will use

On Thu, Jul 25, 2013 at 6:16 PM, Don Armstrong <don@debian.org> wrote:

On Thu, 25 Jul 2013, Mike Gabriel wrote:
> I have been using the compat mode in LJT since Debian squeeze. As
> part of upstream X2Go I build packages just like the one in Debian
> but with compat mode enabled. The packages (still 1.2.90) can be
> obtained from
>
> deb http://packages.x2go.org/debian wheezy main heuler
>
> or with dget [1].

This is a good start. However, the package should also build libjpeg-dev
or whatever is appropriate so that the transition can be completely
tested. It would also be good to have all of the packages which depend
on libjpeg-dev built with this transition package, and a select few
tested without being rebuilt.[1]

I think that Ubuntu/Fedora/OpenSuSE already did that for us, but I think it would be nice to do the recompile using libjpeg-turbo.

Mike, can you prepare libjpeg8-dev and I will do a r-dep rebuild in clean pbuilder using the LJT packages.

Finally, what is the status of upstream supporting SmartScale?

http://www.libjpeg-turbo.org/About/SmartScale

Quote: "Lossless SmartScale is clever, but it does not generally accomplish anything that can't already be accomplished better with webp, and in most cases, the same task can also be accomplished as well or better, and more quickly, using PNG. Further, the performance and compression ratio of lossless SmartScale are generally worse than that of the JPEG-LS standard, and in the isolated cases in which they aren't, lossless SmartScale provides either an equal or worse performance vs. compression ratio tradeoff."

I think that the study looks valid, but even if it was biased it explains the status of the author – he won't implement SmartScale unless somebody pays him to do so, because he doesn't see usefulness of this technology.

What are the downsides of Debian not supporting it?

I did some code research on libjpeg8 reverse dependencies.

After cleaning the embedded libraries I did search for usage of not-supported fields in cinfo (see README-turbo.txt - the Not supported section), namely:

cinfo(\\.|->)(scale_num|scale_denom|block_size|do_fancy_downsampling)

The full output can be found at https://www.sury.org/libjpeg8-usage.txt

There are ~40 packages using downscaling (scale_num or scale_denom), but when you remove all usages in decompress (IDCT scaling in decompress is supported by libjpeg-turbo), you will not find a single usage of downscaling in compress.

The methodology:

- I have removed the packages where the source file name was obvious (like load/loader/read/...)

- I have checked the source files by hand and the package was removed if the scale_{num,denom} was followed by jpeg_start_decompress or precedded by struct jpeg_decompress_struct cinfo.

To eliminate any possible errors I have re-greped the source files for DCT_SCALING_SUPPORTED define and haven't found any usage.

To even further reduce the possibility of my mistake, I have re-grepped the sources with:

grep -r jpeg_compress_struct -A100 .

The output of that can be found at https://www.sury.org/libjpeg-jpeg_compress_struct.txt

and looked for the (scale_num|scale_denom|block_size|do_fancy_downsampling) in the methods using jpeg_compress_struct.

Again I haven't found any usage of downscaling in compression functions, but there's a still margin of error (the usage might be down deeper than 100 lines, etc.), but as far as I understand the technology the only downside would be larger output image size.

I haven't found a single usage of cinfo.block_size in the mentioned source files.

cinfo.do_fancy_downsampling was found only to be always set to FALSE and the comments indicate that the support was added to prevent segfaults:

./xawtv-3.103/libng/plugins/conv-mjpeg.c: h->mjpg_cinfo.do_fancy_downsampling = FALSE; // fix segfaulst with libjpeg v7++

./vdr-plugin-xineliboutput-1.0.7+cvs20130223.2117/xine_frontend.c: cinfo.do_fancy_downsampling = FALSE;

./gst-plugins-good0.10-0.10.31/ext/jpeg/smokecodec.c: newinfo->cinfo.do_fancy_downsampling = FALSE;

./gst-plugins-good0.10-0.10.31/ext/jpeg/gstjpegenc.c: jpegenc->cinfo.do_fancy_downsampling = FALSE;

./gst-plugins-good1.0-1.0.8/ext/jpeg/gstjpegenc.c: jpegenc->cinfo.do_fancy_downsampling = FALSE;

./transcode-1.1.7/export/export_jpg.c: encinfo.do_fancy_downsampling = FALSE;

./motion-3.2.12/picture.c: cinfo.do_fancy_downsampling = FALSE; // fix segfaulst with v7

./gmerlin-1.2.0~dfsg+1/plugins/jpeg/iw_jpeg.c: jpeg->cinfo.do_fancy_downsampling = FALSE;

I even think there are *downsides* of Debian _supporting_ it, see the usage.txt in libjpeg8 sources:

> CAUTION: An implementation of the JPEG SmartScale

> extension is required for this feature. SmartScale

> enabled JPEG is not yet widely implemented, so many

> decoders will be unable to view a SmartScale extended

> JPEG file at all.

This is really really bad for interoperability.

[Does Debian ship any images which use it?]

I highly doubt so due to research above.

1: You're probably already doing this, but details on the packages which
are known to work, and any which have problems would be important to
know.

P.S.: Sorry if the gmail messes the formatting of the email.

--
Ondřej Surý <ondrej@sury.org>