• View
• Edit
• History
• Print

"libjpeg-turbo" != "TurboJPEG"

There has been some confusion regarding the names "libjpeg-turbo" and "TurboJPEG", so we felt it prudent to include this explanation.

libjpeg-turbo is the name of our open source project that provides a SIMD-accelerated implementation of the industry-standard libjpeg API. The library we provide that implements that API is both API/ABI-compatible and mathematically compatible with libjpeg v6b. It can also optionally be configured to be API/ABI-compatible with libjpeg v7 and v8, but it does not include support for the non-standard SmartScale format introduced in libjpeg v8.

"TurboJPEG" is a higher-level API originally developed for use by VirtualGL and TurboVNC (but other projects, both open source and proprietary, now use it as well.) TurboJPEG provides an easy-to-use interface for compressing and decompressing JPEG images in memory. Within libjpeg-turbo, the TurboJPEG API is provided by way of a wrapper library that calls down to the libjpeg API. However, other implementations of the TurboJPEG API exist. TurboJPEG/mediaLib and TurboJPEG/IPP, for instance, implement the TurboJPEG API on top of Sun mediaLib and the Intel Performance Primitives, respectively. Both of those implementations were developed within The VirtualGL Project, although neither is actively used anymore.

TurboJPEG is generally not as powerful of an API as libjpeg, but it provides some features that would not be straightforward to implement using the underlying libjpeg API, such as generating planar YUV images and performing multiple simultaneous lossless transforms on an image. The Java interface for libjpeg-turbo is written on top of the TurboJPEG API.

Both the libjpeg API library and the TurboJPEG API library benefit from libjpeg-turbo's SIMD extensions. There is no significant performance difference between the two, all else being equal.

Yes, we realize the names can be confusing (particularly to native speakers of languages that place adjectives after nouns instead of before), but there are historical reasons for them, and the TurboJPEG API has too much traction at this point to undergo a name change.