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. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  2. Intel 120GB 530 Series SSD Linux Performance
  3. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
  4. AMD's Windows Catalyst Driver Remains Largely Faster Than Linux Drivers
Latest Linux Articles
  1. NVIDIA vs. Nouveau Drivers With Linux 3.18 + Mesa 10.4-devel
  2. Is The Open-Source NVIDIA Driver Fast Enough For Steam On Linux Gaming?
  3. Linux 3.18 File-System Performance Minimally Changed But Possible Regressions
  4. AMD Radeon Gallium3D Is Catching Up & Sometimes Beating Catalyst On Linux
Latest Linux News
  1. More File-System Tests Of The Linux 3.18 Kernel
  2. Using NVIDIA's NVENC On Linux With FFmpeg
  3. There's Talk Again About An "Open To The Core" Ubuntu Laptop
  4. PowerVR SGX Driver Code Gets Leaked
  5. V2 Of KDBUS Published For Linux Kernel Review
  6. VirtualBox 4.3.20 Arrives, Still No Sign Of VirtualBox 4.4
  7. Scientific Linux 6.6 vs. Scientific Linux 7.0 Benchmarks
  8. Qualcomm Looks To Get Into The ARM Server Business
  9. HHVM 3.4 Adds New Features, Support
  10. More Radeon Driver Changes Queued For Linux 3.19
Latest Forum Discussions
  1. Roadmap to Catalyst 14.10 ?
  2. Cant get working Kaveri APU - A10-7850k
  3. Debian Developer Resigns From The Systemd Maintainership Team
  4. Script for Fan Speed Control
  5. Debian Init System Coupling Vote Results
  6. The Slides Announcing The New "AMDGPU" Kernel Driver
  7. Updated and Optimized Ubuntu Free Graphics Drivers
  8. Ubuntu Developers Still Thinking What To Do About Adobe Flash Support