Package signatures

To ensure the integrity of the libjpeg-turbo binary packages, the RPM and DEB files and the source tarball are signed using the following key:
http://www.libjpeg-turbo.org/key/LJT-GPG-KEY-1024
http://pgp.mit.edu/pks/lookup?op=get&search=0x85C7044E033FDE16
and the Windows installers are signed using a code signing certificate.

Packaging changes

• A new build of libjpeg-turbo-1.4.0.dmg was uploaded on 2015-05-17 to address an issue whereby attempting to link libjpeg-turbo with an i386 iOS simulator program would generate an undefined symbol error (_putenv$UNIX2003). The fix for this was to build the 32-bit OS X fork of the libjpeg-turbo libraries with -D_NONSTD_SOURCE.
• A new build of libjpeg-turbo-1.4.0.dmg was uploaded on 2015-05-06 to address an issue whereby, when using libjpeg-turbo in a 64-bit iOS Objective-C program, exceptions thrown from within one of the libjpeg callback functions would not be caught. The fix for this was to build the 64-bit iOS fork of the libjpeg-turbo libraries with -funwind-tables.

Cygwin

See http://www.libjpeg-turbo.org/Documentation/Cygwin for Cygwin installation instructions.

1.4.0

Significant changes relative to 1.4 beta1:

1. Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build because OS X does not provide the le32toh() and htole32() functions.)

2. The non-SIMD RGB565 color conversion code did not work correctly on big endian machines. This has been fixed.

3. Fixed an issue in tjPlaneSizeYUV() whereby it would erroneously return 1 instead of -1 if componentID was > 0 and subsamp was TJSAMP_GRAY.

4. Fixed an issue in tjBufSizeYUV2() whereby it would erroneously return 0 instead of -1 if width was < 1.

5. The Huffman encoder now uses clz and bsr instructions for bit counting on ARM64 platforms (see 1.4 beta1[5].)

6. 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.

7. 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.

8. cjpeg, djpeg, and jpegtran now accept an argument of -version, which will print the library version and exit.

9. 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.

10. 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.

11. 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.

12. 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.