libjpeg-turbo/libjpeg-turbo 1.3.90

1.3.90 (1.4 beta1)

on GitHub

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

Significant changes relative to 1.3.1:

1. New features in the TurboJPEG API:

   • YUV planar images can now be generated with an arbitrary line padding (previously only 4-byte padding, which was compatible with X Video, was supported.)
   • The decompress-to-YUV function has been extended to support image scaling.
   • JPEG images can now be compressed from YUV planar source images.
   • YUV planar images can now be decoded into RGB or grayscale images.
   • 4:1:1 subsampling is now supported. This is mainly included for compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no significant advantages relative to 4:2:0.
   • CMYK images are now supported. This feature allows CMYK source images to be compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to CMYK destination images. Conversion between CMYK/YCCK and RGB or YUV images is not supported. Such conversion requires a color management system and is thus out of scope for a codec library.
   • The handling of YUV images in the Java API has been significantly refactored and should now be much more intuitive.
   • The Java API now supports encoding a YUV image from an arbitrary position in a large image buffer.
   • All of the YUV functions now have a corresponding function that operates on separate image planes instead of a unified image buffer. This allows for compressing/decoding from or decompressing/encoding to a subregion of a larger YUV image. It also allows for handling YUV formats that swap the order of the U and V planes.

2. Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up the compression of full-color JPEGs by 70-80% on such platforms and decompression by 25-35%.

3. If an application attempts to decompress a Huffman-coded JPEG image whose header does not contain Huffman tables, libjpeg-turbo will now insert the default Huffman tables. In order to save space, many motion JPEG video frames are encoded without the default Huffman tables, so these frames can now be successfully decompressed by libjpeg-turbo without additional work on the part of the application. An application can still override the Huffman tables, for instance to re-use tables from a previous frame of the same video.

4. The Mac packaging system now uses pkgbuild and productbuild rather than PackageMaker (which is obsolete and no longer supported.) This means that OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo, although the packages produced can be installed on OS X 10.5 "Leopard" or later. OS X 10.4 "Tiger" is no longer supported.

5. The Huffman encoder now uses clz and bsr instructions for bit counting on ARM platforms rather than a lookup table. This reduces the memory footprint by 64k, which may be important for some mobile applications. Out of four Android devices that were tested, two demonstrated a small overall performance loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with ARMv7 code when enabling this new feature, but the other two devices demonstrated a significant overall performance gain with both ARMv6 and ARMv7 code (~10-20%) when enabling the feature. Actual mileage may vary.

6. Worked around an issue with Visual C++ 2010 and later that caused incorrect pixels to be generated when decompressing a JPEG image to a 256-color bitmap, if compiler optimization was enabled when libjpeg-turbo was built. This caused the regression tests to fail when doing a release build under Visual C++ 2010 and later.

7. Improved the accuracy and performance of the non-SIMD implementation of the floating point inverse DCT (using code borrowed from libjpeg v8a and later.) The accuracy of this implementation now matches the accuracy of the SSE/SSE2 implementation. Note, however, that the floating point DCT/IDCT algorithms are mainly a legacy feature. They generally do not produce significantly better accuracy than the accurate integer DCT/IDCT algorithms, and they are quite a bit slower.

8. Added a new output colorspace (JCS_RGB565) to the libjpeg API that allows for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not used, then this code path is SIMD-accelerated on ARM platforms.

9. Numerous obsolete features, such as support for non-ANSI compilers and support for the MS-DOS memory model, were removed from the libjpeg code, greatly improving its readability and making it easier to maintain and extend.

10. Fixed a segfault that occurred when calling output_message() with msg_code set to JMSG_COPYRIGHT.

11. Fixed an issue whereby wrjpgcom was allowing comments longer than 65k characters to be passed on the command line, which was causing it to generate incorrect JPEG files.

12. Fixed a bug in the build system that was causing the Windows version of wrjpgcom to be built using the rdjpgcom source code.

13. Restored 12-bit-per-component JPEG support. A 12-bit version of libjpeg-turbo can now be built by passing an argument of --with-12bit to configure (Unix) or -DWITH_12BIT=1 to cmake (Windows.) 12-bit JPEG support is included only for convenience. Enabling this feature disables all of the performance features in libjpeg-turbo, as well as arithmetic coding and the TurboJPEG API. The resulting library still contains the other libjpeg-turbo features (such as the colorspace extensions), but in general, it performs no faster than libjpeg v6b.

14. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion and IDCT algorithms (both are used during JPEG decompression.) For unknown reasons (probably related to clang), this code cannot currently be compiled for iOS.

15. Fixed an extremely rare bug (CVE-2014-9092) that could cause the Huffman encoder's local buffer to overrun when a very high-frequency MCU is compressed using quality 100 and no subsampling, and when the JPEG output buffer is being dynamically resized by the destination manager. This issue was so rare that, even with a test program specifically designed to make the bug occur (by injecting random high-frequency YUV data into the compressor), it was reproducible only once in about every 25 million iterations.

16. Fixed an oversight in the TurboJPEG C wrapper: if any of the JPEG compression functions was called repeatedly with the same automatically-allocated destination buffer, then TurboJPEG would erroneously assume that the jpegSize parameter was equal to the size of the buffer, when in fact that parameter was probably equal to the size of the most recently compressed JPEG image. If the size of the previous JPEG image was not as large as the current JPEG image, then TurboJPEG would unnecessarily reallocate the destination buffer.