libjpeg-turbo/libjpeg-turbo 1.5.90

1.5.90 (2.0 beta1)

on GitHub

Official binaries and source tarball are available at:
https://sourceforge.net/projects/libjpeg-turbo/files/1.5.90%20%282.0%20beta1%29/

Significant changes relative to 1.5.3:

1. Added AVX2 SIMD implementations of the colorspace conversion, chroma downsampling and upsampling, integer quantization and sample conversion, and accurate integer DCT/IDCT algorithms. When using the accurate integer DCT/IDCT algorithms on AVX2-equipped CPUs, the compression of RGB images is approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x) with 64-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the decompression of RGB images is approximately 9-35% (avg. 17%) faster with 64-bit code and 7-17% (avg. 12%) faster with 32-bit code. (As tested on a 3 GHz Intel Core i7. Actual mileage may vary.)

2. Overhauled the build system to use CMake on all platforms, and removed the autotools-based build system. This decision resulted from extensive discussions within the libjpeg-turbo community. libjpeg-turbo traditionally used CMake only for Windows builds, but there was an increasing amount of demand to extend CMake support to other platforms. However, because of the unique nature of our code base (the need to support different assemblers on each platform, the need for Java support, etc.), providing dual build systems as other OSS imaging libraries do (including libpng and libtiff) would have created a maintenance burden. The use of CMake greatly simplifies some aspects of our build system, owing to CMake's built-in support for various assemblers, Java, and unit testing, as well as generally fewer quirks that have to be worked around in order to implement our packaging system. Eliminating autotools puts our project slightly at odds with the traditional practices of the OSS community, since most "system
   libraries" tend to be built with autotools, but it is believed that the benefits of this move outweigh the risks. In addition to providing a unified build environment, switching to CMake allows for the use of various build tools and IDEs that aren't supported under autotools, including XCode, Ninja, and Eclipse. It also eliminates the need to install autotools via MacPorts/Homebrew on OS X and allows libjpeg-turbo to be configured without the use of a terminal/command prompt. Extensive testing was conducted to ensure that all features provided by the autotools-based build system are provided by the new build system.

3. The libjpeg API in this version of libjpeg-turbo now includes two additional functions, jpeg_read_icc_profile() and jpeg_write_icc_profile(), that can be used to extract ICC profile data from a JPEG file while decompressing or to embed ICC profile data in a JPEG file while compressing or transforming. This eliminates the need for downstream projects, such as color management libraries and browsers, to include their own glueware for accomplishing this.

4. Improved error handling in the TurboJPEG API library:

   • Introduced a new function (tjGetErrorStr2()) in the TurboJPEG C API that allows compression/decompression/transform error messages to be retrieved in a thread-safe manner. Retrieving error messages from global functions, such as tjInitCompress() or tjBufSize(), is still thread-unsafe, but since those functions will only throw errors if passed an invalid argument or if a memory allocation failure occurs, thread safety is not as much of a concern.
   • Introduced a new function (tjGetErrorCode()) in the TurboJPEG C API and a new method (TJException.getErrorCode()) in the TurboJPEG Java API that can be used to determine the severity of the last compression/decompression/transform error. This allows applications to choose whether to ignore warnings (non-fatal errors) from the underlying libjpeg API or to treat them as fatal.
   • Introduced a new flag (TJFLAG_STOPONWARNING in the TurboJPEG C API and TJ.FLAG_STOPONWARNING in the TurboJPEG Java API) that causes the library to immediately halt a compression/decompression/transform operation if it encounters a warning from the underlying libjpeg API (the default behavior is to allow the operation to complete unless a fatal error is encountered.)

5. Introduced a new flag in the TurboJPEG C and Java APIs (TJFLAG_PROGRESSIVE and TJ.FLAG_PROGRESSIVE, respectively) that causes the library to use progressive entropy coding in JPEG images generated by compression and transform operations. Additionally, a new transform option (TJXOPT_PROGRESSIVE in the C API and TJTransform.OPT_PROGRESSIVE in the Java API) has been introduced, allowing progressive entropy coding to be enabled for selected transforms in a multi-transform operation.

6. Introduced a new transform option in the TurboJPEG API (TJXOPT_COPYNONE in the C API and TJTransform.OPT_COPYNONE in the Java API) that allows the copying of markers (including EXIF and ICC profile data) to be disabled for a particular transform.

7. Added two functions to the TurboJPEG C API (tjLoadImage() and tjSaveImage()) that can be used to load/save a BMP or PPM/PGM image to/from a memory buffer with a specified pixel format and layout. These functions replace the project-private (and slow) bmp API, which was previously used by TJBench, and they also provide a convenient way for first-time users of libjpeg-turbo to quickly develop a complete JPEG compression/decompression program.

8. The TurboJPEG C API now includes a new convenience array (tjAlphaOffset[]) that contains the alpha component index for each pixel format (or -1 if the pixel format lacks an alpha component.) The TurboJPEG Java API now includes a new method (TJ.getAlphaOffset()) that returns the same value. In addition, the tjRedOffset[], tjGreenOffset[], and tjBlueOffset[] arrays-- and the corresponding TJ.getRedOffset(), TJ.getGreenOffset(), and TJ.getBlueOffset() methods-- now return -1 for TJPF_GRAY/TJ.PF_GRAY rather than 0. This allows programs to easily determine whether a pixel format has red, green, blue, and alpha components.

9. Added a new example (tjexample.c) that demonstrates the basic usage of the TurboJPEG C API. This example mirrors the functionality of TJExample.java. Both files are now included in the libjpeg-turbo documentation.

10. Fixed two signed integer overflows in the arithmetic decoder, detected by the Clang undefined behavior sanitizer, that could be triggered by attempting to decompress a specially-crafted malformed JPEG image. These issues did not pose a security threat, but removing the warnings makes it easier to detect actual security issues, should they arise in the future.

11. Fixed a bug in the merged 4:2:0 upsampling/dithered RGB565 color conversion algorithm that caused incorrect dithering in the output image. This algorithm now produces bitwise-identical results to the unmerged algorithms.

12. The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64] (if libjpeg-turbo is built with Yasm), and iOS/Arm[64] builds are now private. This prevents those symbols from being exposed in applications or shared libraries that link statically with libjpeg-turbo.

13. Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy chroma upsampling, integer quantization, and accurate integer DCT/IDCT algorithms. When using the accurate integer DCT/IDCT, this speeds up the compression of RGB images by approximately 70-100% and the decompression of RGB images by approximately 2-3.5x.

14. Fixed a build error when building with older MinGW releases (regression caused by 1.5.1[7].)

15. Added SIMD acceleration for progressive Huffman encoding on SSE2-capable x86 and x86-64 platforms. This speeds up the compression of full-color progressive JPEGs by about 85-90% on average (relative to libjpeg-turbo 1.5.x) when using modern Intel and AMD CPUs.