libjpeg-turbo Changelog

What's new in libjpeg-turbo 1.4.0

• Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build
• because OS X does not provide the le32toh() and htole32() functions.)
• The non-SIMD RGB565 color conversion code did not work correctly on big
• endian machines. This has been fixed.
• Fixed an issue in tjPlaneSizeYUV() whereby it would erroneously return 1
• instead of -1 if componentID was > 0 and subsamp was TJSAMP_GRAY.
• Fixed an issue in tjBufSizeYUV2() wherby it would erroneously return 0
• instead of -1 if width was < 1.
• The Huffman encoder now uses clz and bsr instructions for bit counting on
• ARM64 platforms (see 1.4 beta1 [5].)
• The close() method in the TJCompressor and TJDecompressor Java classes is
• now idempotent. Previously, that method would call the native tjDestroy()
• function even if the TurboJPEG instance had already been destroyed. This
• caused an exception to be thrown during finalization, if the close() method had
• already been called. The exception was caught, but it was still an expensive
• operation.
• The TurboJPEG API previously generated an error ("Could not determine
• subsampling type for JPEG image") when attempting to decompress grayscale JPEG
• images that were compressed with a sampling factor other than 1 (for instance,
• with 'cjpeg -grayscale -sample 2x2'). Subsampling technically has no meaning
• with grayscale JPEGs, and thus the horizontal and vertical sampling factors
• for such images are ignored by the decompressor. However, the TurboJPEG API
• was being too rigid and was expecting the sampling factors to be equal to 1
• before it treated the image as a grayscale JPEG.
• cjpeg, djpeg, and jpegtran now accept an argument of -version, which will
• print the library version and exit.
• Referring to 1.4 beta1 [15], another extremely rare circumstance was
• discovered under which the Huffman encoder's local buffer can be overrun
• when a buffered destination manager is being used and an
• extremely-high-frequency block (basically junk image data) is being encoded.
• Even though the Huffman local buffer was increased from 128 bytes to 136 bytes
• to address the previous issue, the new issue caused even the larger buffer to
• be overrun. Further analysis reveals that, in the absolute worst case (such as
• setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning
• order), the Huffman encoder can produce encoded blocks that approach double the
• size of the unencoded blocks. Thus, the Huffman local buffer was increased to
• 256 bytes, which should prevent any such issue from re-occurring in the future.
• The new tjPlaneSizeYUV(), tjPlaneWidth(), and tjPlaneHeight() functions
• were not actually usable on any platform except OS X and Windows, because
• those functions were not included in the libturbojpeg mapfile. This has been
• fixed.
• Restored the JPP(), JMETHOD(), and FAR macros in the libjpeg-turbo header
• files. The JPP() and JMETHOD() macros were originally implemented in libjpeg
• as a way of supporting non-ANSI compilers that lacked support for prototype
• parameters. libjpeg-turbo has never supported such compilers, but some
• software packages still use the macros to define their own prototypes.
• Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that
• have far symbols, but some software packages still use the FAR macro. A pretty
• good argument can be made that this is a bad practice on the part of the
• software in question, but since this affects more than one package, it's just
• easier to fix it here.
• Fixed issues that were preventing the ARM 64-bit SIMD code from compiling
• for iOS, and included an ARMv8 architecture in all of the binaries installed by
• the "official" libjpeg-turbo SDK for OS X.