On Thu, Jul 31, 2014 at 07:24:29PM -0700, Don Armstrong wrote: > The technical committee was asked in #717076 to decide whether > libjpeg8 or libjpeg-turbo would be the default libjpeg implementation. > The decision is below:
Dear CTTE, I am concerned that the rationale for this decision contains misconceptions about the IJG JPEG library. Given the public nature of this announcement, I cannot completly ignore them. > ==== RESOLUTION ==== > > Whereas: > > 1. There is a dispute between Developers about whether libjpeg8/9 or > libjpeg-turbo should be the default libjpeg implementation in > Debian. The release team does not want to have more than one > libjpeg implementation. > > 2. The Debian libjpeg8 maintainer does not see libjpeg-turbo as a > suitable replacement, and notes that it does not implement the > full libjpeg8/9 ABI. > > 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. > 4. libjpeg-turbo is reported to have significantly better performance > than libjpeg, and to be API/ABI-compatible with libjpeg6b. This is one point where the CTTE could have bring technical content by quantifying the speed improvement in normal use and not in benchmark. > 5. libjpeg-turbo is in use by several other distributions (at least > Fedora, Gentoo, openSUSE, Ubuntu) and browser projects (WebKit, > Blink, Gecko). > > 6. The former organiser of the IJG advised Fedora of his opinion that > libjpeg8 was a "dead end" due to fragmentation. Alas the former organiser is mosty responsible for the issue by having frozen the IJG JPEG project for 10 years. > 7. The libjpeg-turbo packages in Debian are not yet in a state where > they could be a drop-in replacement for libjpeg8. However, > similar work has been done in Ubuntu and could be adopted. > > 8. In general it does not appear that other Debian packages require > the libjpeg8 API. The sole exception appears to be a "decode from > memory buffer" interface (jpeg_mem_src/jpeg_mem_dest), which is > implemented by libjpeg-turbo unless configured > --without-mem-srcdst. Obviously, this is a chicken and egg problem. However this does not address whether some Debian packages require the libjpeg8 _behaviour_, at least for passing the test-suite. > 9. While libjpeg-turbo can be configured with support for much of the > newer interfaces in libjpeg8, it does not support the SmartScale > API. However, images with this extension may have > interoperability problems. Those developers advocating > libjpeg-turbo generally suggest disabling the libjpeg7/libjpeg8 > APIs there. This shows a fundamental misunderstanding about the nature of the SmartScale extension. This extension can be used when converting JPEG image to bitmap or bitmap-based image format, without introducing non standard SmartScale-JPEG files. The purpose of non-standard SmartScale-JPEG files is to store the SmartScale parameters that should be used when decompressing the file, instead of requiring the caller to provide them. But in no way the use of the SmartScale extension requires to create such file, this is only a convenience. While writing such SmartScale-JPEG files can create interoperability problems, the ability of reading them does not and in fact reduce interoperability problems with files generated on other operating system that use libjpeg8. Also what has not been considered is 10. Security. The IJG JPEG library has an excellent track record with regard to security. On the other hand, there have been a number of security issues specific to libjpeg-turbo due to either mistake in the assembly or by change done to the code without understanding its purpose (e.g. CVE-2012-2806). Beside it has been reported that libjpeg-turbo do not play well with valgrind. 11. License. IJG JPEG is under a plain permissive licence. On the other hand, the license history of libjpeg-turbo is rather complexe. It is expected that the latest release has fixed all the license compatibility issues, but this should be reviewed (in particular the attribution). Respectfully submitted. -- Bill. <ballo...@debian.org> Imagine a large red swirl here. -- 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/20140808224912.GE27516@yellowpig
