libjpeg-turbo | About / What About libjpeg v9?

libjpeg-turbo provides emulation of the libjpeg v8 API/ABI as a means of allowing applications that have already migrated to libjpeg v8 to take advantage of accelerated baseline JPEG encoding/decoding at run time. At this time, we do not see a similar need to emulate the libjpeg v9 API/ABI, and this article attempts to explain our justification for that decision.

The only major new feature in jpeg-9 relative to jpeg-8 is a new color transform for the "Lossless SmartScale" format. SmartScale is a non-standard format (it was rejected by the ITU-T) that was introduced in jpeg-8, and our own research has revealed that, in general, it does not accomplish anything that can't already be accomplished with existing, standard formats (such as PNG, webp, baseline JPEG, or JPEG with arithmetic coding.)

If SmartScale proved to be significantly advantageous in terms of compression ratio, image quality, or performance, then it might have some hope of becoming a new de facto standard, but given that it doesn't appear to provide any such advantages, it is our opinion that supporting this new format is antithetical to the original goals of the IJG, which were to encourage the industry to standardize around a common JPEG format. SmartScale files can currently only be decoded using jpeg-8, and Lossless SmartScale files that use the new color transform can only be decoded using jpeg-9. Regardless of its lack of proven usefulness, we'd probably still be on board with supporting SmartScale if it had been accepted by a standards committee or if prominent open source software wanted to support it. However, since the format is not an official standard, there is no guarantee that it will not change arbitrarily in the future. How do we know that jpeg-10 won't introduce an all-new version of SmartScale that is incompatible with previous releases?

Every version of the IJG's software from v7 onward has broken backward ABI compatibility with previous releases, and in fact, it was not necessary to do so in the case of libjpeg v9. The new color transform could have been implemented as a JPEG colorspace constant, thus preserving backward ABI compatibility with libjpeg v8. We feel that the IJG is not paying sufficient heed to change management, and this has created difficulties for O/S distributions and commercial applications that have adopted libjpeg v7 and v8. Further, most of the incompatible ABI changes have been implemented in the name of supporting DCT scaling and the non-standard SmartScale format, features whose usefulness has (in our opinion) not been adequately demonstrated and features which (to our knowledge) have not been implemented by any prominent applications.

It's not that these technologies aren't clever. It's more that they are unproven, and thus we feel that a stable, de facto standard JPEG codec library is not the right place to introduce them. We feel that there is little or no community visibility into the development of libjpeg, as well as little or no comprehensive research into the technical justification for SmartScale and DCT scaling. Further, whenever anyone dares to ask "why", the current maintainer of the IJG has often responded with blind dogma, accusations of corruption, etc. Fedora finally had enough of it and decided, based on our research and impolitic statements made by the current IJG maintainer, to scrap their plans to adopt the jpeg-8 ABI.

In a nutshell, The libjpeg-turbo Project has decided to use the release of jpeg-9 as an opportunity to draw a line in the sand and say "enough!" We could emulate the libjpeg v9 API/ABI easily enough, but why? The only purpose would be to support applications or O/S distributions that had upgraded from jpeg-8 to jpeg-9, but it is our opinion that no technical justification exists for this upgrade. We have yet to identify any prominent software that has adopted the non-standard SmartScale format introduced by jpeg-8 (but if you know of any, please let us know), and thus we are left to wonder whether there was even much of a justification for the upgrade to jpeg-8 or whether those who upgraded did so because it was the latest & greatest code and appeared to come from an authoritative source. We have no intention of adopting the SmartScale format unless it is at least accepted as a community standard, but that probably won't ever happen unless it is accepted as an industry standard. We do not feel that the impolitic statements made by the current maintainer of the IJG, as well as the lack of compelling research demonstrating the usefulness of SmartScale, are conducive to it ever being accepted as an industry standard. And without that standardization process, the community will have no confidence that the format won't change arbitrarily in the future.

The IJG is not a standards organization. The whole purpose of the organization was to encourage the industry to adopt one of the existing standard JPEG formats, and Tom Lane did so by providing a FOSS library that encoded/decoded said format. libjpeg became a de facto standard because of his work, but since the IJG has changed hands, it is our opinion that its software has ceased being mindful of these original goals and has instead become more of a science fair project to demonstrate new ways of using the DCT algorithm. In our opinion, this research, while clever, has not been proven to provide any functionality that can't already be provided using other means. Until or unless its usefulness is proven, it is our opinion that these new features do not belong in a library that is being used as a de facto industry standard. So, rather than support the libjpeg v9 API/ABI, we have chosen instead to use this opportunity to cast light upon the issues associated with continuing to source the IJG's software, and to officially stop viewing the IJG as our "upstream" source.