1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

JPEG Library Update Raises Compatibility Concerns

Free Software

Published on 15 January 2013 01:28 PM EST
Written by Michael Larabel in Free Software
13 Comments

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."

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  2. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  3. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
  4. AMD Radeon R9 285 Tonga Performance On Linux
Latest Linux Articles
  1. AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver
  2. MSI: Update Your BIOS From The Linux Desktop
  3. NVIDIA vs. AMD 2D Linux Drivers: Catalyst Is Getting Quite Good At 2D
  4. 15-Way GPU Comparison With Mesa 10.3 + Linux 3.17
Latest Linux News
  1. Linux 3.19 To Have Skylake Graphics, PPGTT Enablement
  2. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  3. Imagination Releases Full ISA Documentation For PowerVR Rogue GPUs
  4. Features GNOME Developers Want In The Linux Kernel
  5. GTK+ Gains Experimental Overlay Scrollbars
  6. Phoronix Test Suite 5.4 M3 Is Another Hearty Update
  7. GParted 0.20 Improves Btrfs Support
  8. EXT4 In Linux 3.18 Has Clean-ups, Bug Fixes
  9. Emacs 24.4 Has Built-In Web Browser, Improved Multi-Monitor Support
  10. NVIDIA's NVPTX Support For GCC Is Close To Being Merged
Latest Forum Discussions
  1. HOPE: The Ease Of Python With The Speed Of C++
  2. Users/Developers Threatening Fork Of Debian GNU/Linux
  3. Proof that strlcpy is un-needed
  4. Bye bye BSD, Hello Linux: A Sys Admin's Story
  5. Updated and Optimized Ubuntu Free Graphics Drivers
  6. NVIDIA Presents Its Driver Plans To Support Mir/Wayland & KMS On Linux
  7. AMD Is Restructuring Again, Losing 7% Of Employees
  8. Open-Source AMD Fusion E-350 Support Takes A Dive