JPEG Library Update Raises Compatibility Concerns

This week brought the release of IJG's libjpeg v9 library, which brought noticeable lossless JPEG compression improvements so that it can even surpass PNG images on the compress lossless image size. While the improvements are nice, backwards incompatible changes with this JPEG library are causing concern for some users and developers.

On the libjpeg-turbo mailing list is a lengthy message about concerns over libjpeg v9 from the libjpeg-turbo maintainer. For those out of the loop, libjpeg-turbo is a fork of libjpeg that brings SIMD instructions and other performance enhancements to provide for faster JPEG encoding/decoding. The libjpeg-turbo fork isn't some uncommon fork, but it's used by Mozilla Firefox, Google Chrome, and many other software projects. This forked JPEG library also is found in use within Fedora.

The libjpeg-turbo fork has managed to maintain API/ABI compatibility with upstream libjpeg for its v6/7/8 releases, but now its maintainer is trying to decide what to do about libjpeg v9. This new libjpeg release breaks the API/ABI once more as it introduces a new field used for lossless RGB JPEG files and requires the JPEG SmartScale format. The libjpeg-turbo API/ABI emulation for libjpeg-7/8 was done as the result of a commercial software company financing the work but now for jpeg-9 the future role of libjpeg-turbo is being questioned.

The libjpeg-turbo project could deviate more from upstream libjpeg in not being API/ABI compatible but that could result in some fragmentation among JPEG files, the new field could be stubbed out but not implemented, or the new libjpeg functionality could in theory be implemented within libjpeg-turbo.

The libjpeg-turbo maintainer writes, "My personal take on it is that tracking the upstream code may no longer be a battle worth fighting. Most of the recent IJG changes (post jpeg-8b) have been related to lossless JPEG encoding or SmartScale. Best case, SmartScale is a new format that has not been adopted as a standard yet and is not widely used, and worst case, it may be a mostly useless extension. The IJG's method for generating lossless JPEG files using SmartScale is interesting, but I struggle to think of a reason why one would want to use SmartScale for any other purpose. And it hasn't been proven that the use of this extension for lossless encoding is significantly better than, for instance, PNG."

In the end, the future of libjpeg-turbo is up in the air depending upon the community's response:

I guess what I'm saying is-- libjpeg-turbo may have reached a point at which there isn't really a whole lot more we can add to it feature-wise without either adopting the unproven SmartScale technology or diverging from IJG to implement some other format, like JPEG XR. Personally, I feel that both would be out of scope for what is still, at the end of the day, a turbo baseline JPEG library. I've always believed that new formats should be implemented by a new library. The libjpeg API is dated and really ill-equipped to handle new formats, which is why these API/ABI incompatibilities keep popping up with the IJG's software.

However, I want this project to be whatever the community wants it to be. I don't think we're well-positioned to be a haven for new formats, but if enough people are interested in one that they want to either pay for the implementation or contribute code, I'm definitely open to that. "Keep things the way they are" is also a perfectly acceptable answer, as is "continue focusing on baseline and coming up with new ways to make it faster."