Bug#717076: [CTTE #717076] Default libjpeg implementation in Debian
On Sat, 09 Aug 2014, Bill Allombert wrote:
> > 3. libjpeg8 adds new features to the JPEG image format. These have
> > however been rejected from the ISO standard, and their
> > contributions to image quality and compression appear to be widely
> > disputed.
>
> This is not really relevant. What is relevant, however, is that nobody is
> disputing that libjpeg8 produce higher quality images than libjpeg62 when
> decompressing standard JPEG images.
If this is true, it is a concern: at least the bitmap editors and image
processing utilities (gimp, imagemagick, etc) would regress on output
quality.
Are there any examples of this output difference? And I do mean between IJG
libjpeg and libjpeg-turbo, not IJG libjpeg62 and IJG libjpeg8/9.
> Beside it has been reported that libjpeg-turbo do not play well with valgrind.
This could also be a serious problem. Any lib that impairs the use of
valgrind-style tools is going to be trouble as they interfere with valgrind
runs on the applications/libraries linked to them.
So, what exactly are the drawbacks of running valgrind on something linked
to libjpeg-turbo? If it is just invisible to valgrind, it is not the end of
the world. If it breaks valgrind, OTOH, that should be fixed before it can
be made the default implementation *IMHO*.
Should the two points above be pressing concerns that cannot be easily
addressed by changes in libjpeg-turbo in a short timeframe, could we keep
both libraries in light of this new information? libjpeg-turbo could be
recommended for web-renderer / simple-image-viewer use cases, and IJG
libjpeg for the high-quality image editing and processing use cases.
Obviously, if the decision is to have libjpeg-turbo as the default
implementation doesn't change, to allow both implementations to be kept IJG
libjpeg should be subject to symbol versioning changes to avoid clashes
(assuming it will use the libjpeg9 soname, otherwise it also has to be
renamed).
This would ensure that our packages can be directed to which of the two
implementations is more recommended for that package's use case through
build-depends, and won't cause any headaches when lib-A is linked to
libjpeg-turbo, lib-B is linked to libjpeg8, and app C wants to link to lib-A
and lib-B.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: