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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140809130349.ga8...@khazad-dum.debian.net
