libjpeg-turbo is a JPEG image codec that uses SIMD instructions to accelerate baseline JPEG compression and decompression on x86, x86-64, Arm, PowerPC, and MIPS systems, as well as progressive JPEG compression on x86, x86-64, and Arm systems. On such systems, libjpeg-turbo is generally 2-6x as fast as libjpeg, all else being equal. On other types of systems, libjpeg-turbo can still outperform libjpeg by a significant amount, by virtue of its highly-optimized Huffman coding routines. In many cases, the performance of libjpeg-turbo rivals that of proprietary high-speed JPEG codecs.

2.1.3

Significant changes relative to 2.1.2

1. Fixed a regression introduced by 2.0 beta1[7] whereby cjpeg compressed PGM input files into full-color JPEG images unless the -grayscale option was used.

2. cjpeg now automatically compresses GIF and 8-bit BMP input files into grayscale JPEG images if the input files contain only shades of gray.

3. The build system now enables the intrinsics implementation of the AArch64 (Arm 64-bit) Neon SIMD extensions by default when using GCC 12 or later.

4. Fixed a segfault that occurred while decompressing a 4:2:0 JPEG image using the merged (non-fancy) upsampling algorithms (that is, with cinfo.do_fancy_upsampling set to FALSE) along with jpeg_crop_scanline(). Specifically, the segfault occurred if the number of bytes remaining in the output buffer was less than the number of bytes required to represent one uncropped scanline of the output image. For that reason, the issue could only be reproduced using the libjpeg API, not using djpeg.

2.1.2

Significant changes relative to 2.1.1

1. Fixed a regression introduced by 2.1 beta1[13] that caused the remaining GAS implementations of AArch64 (Arm 64-bit) Neon SIMD functions (which are used by default with GCC for performance reasons) to be placed in the .rodata section rather than in the .text section. This caused the GNU linker to automatically place the .rodata section in an executable segment, which prevented libjpeg-turbo from working properly with other linkers and also represented a potential security risk.

2. Fixed an issue whereby the tjTransform() function incorrectly computed the MCU block size for 4:4:4 JPEG images with non-unary sampling factors and thus unduly rejected some cropping regions, even though those regions aligned with 8x8 MCU block boundaries.

3. Fixed a regression introduced by 2.1 beta1[13] that caused the build system to enable the Arm Neon SIMD extensions when targetting Armv6 and other legacy architectures that do not support Neon instructions.

4. libjpeg-turbo now performs run-time detection of AltiVec instructions on FreeBSD/PowerPC systems if AltiVec instructions are not enabled at compile time. This allows both AltiVec-equipped and non-AltiVec-equipped CPUs to be supported using the same build of libjpeg-turbo.

5. cjpeg now accepts a -strict argument similar to that of djpeg and jpegtran, which causes the compressor to abort if an LZW-compressed GIF input image contains incomplete or corrupt image data.

2.1.1

Significant changes relative to 2.1.0

1. Fixed a regression introduced in 2.1.0 that caused build failures with non-GCC-compatible compilers for Un*x/Arm platforms.

2. Fixed a regression introduced by 2.1 beta1[13] that prevented the Arm 32-bit (AArch32) Neon SIMD extensions from building unless the C compiler flags included -mfloat-abi=softfp or -mfloat-abi=hard.

3. Fixed an issue in the AArch32 Neon SIMD Huffman encoder whereby reliance on undefined C compiler behavior led to crashes ("SIGBUS: illegal alignment") on Android systems when running AArch32/Thumb builds of libjpeg-turbo built with recent versions of Clang.

4. Added a command-line argument (-copy icc) to jpegtran that causes it to copy only the ICC profile markers from the source file and discard any other metadata.

5. libjpeg-turbo should now build and run on CHERI-enabled architectures, which use capability pointers that are larger than the size of size_t.

6. Fixed a regression (CVE-2021-37972) introduced by 2.1 beta1[5] that caused a segfault in the 64-bit SSE2 Huffman encoder when attempting to losslessly transform a specially-crafted malformed JPEG image.

2.1.0

Significant changes relative to 2.1 beta1

1. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to decompress certain progressive JPEG images with one or more component planes of width 8 or less caused a buffer overrun.

2. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to decompress a specially-crafted malformed progressive JPEG image caused the block smoothing algorithm to read from uninitialized memory.

3. Fixed an issue in the Arm Neon SIMD Huffman encoders that caused the encoders to generate incorrect results when using the Clang compiler with Visual Studio.

4. Fixed a floating point exception (CVE-2021-20205) that occurred when attempting to compress a specially-crafted malformed GIF image with a specified image width of 0 using cjpeg.

5. Fixed a regression introduced by 2.0 beta1[15] whereby attempting to generate a progressive JPEG image on an SSE2-capable CPU using a scan script containing one or more scans with lengths divisible by 32 and non-zero successive approximation low bit positions would, under certain circumstances, result in an error ("Missing Huffman code table entry") and an invalid JPEG image.

6. Introduced a new flag (TJFLAG_LIMITSCANS in the TurboJPEG C API and TJ.FLAG_LIMIT_SCANS in the TurboJPEG Java API) and a corresponding TJBench command-line argument (-limitscans) that causes the TurboJPEG decompression and transform functions/operations to return/throw an error if a progressive JPEG image contains an unreasonably large number of scans. This allows applications that use the TurboJPEG API to guard against an exploit of the progressive JPEG format described in the report "Two Issues with the JPEG Standard".

7. The PPM reader now throws an error, rather than segfaulting (due to a buffer overrun) or generating incorrect pixels, if an application attempts to use the tjLoadImage() function to load a 16-bit binary PPM file (a binary PPM file with a maximum value greater than 255) into a grayscale image buffer or to load a 16-bit binary PGM file into an RGB image buffer.

8. Fixed an issue in the PPM reader that caused incorrect pixels to be generated when using the tjLoadImage() function to load a 16-bit binary PPM file into an extended RGB image buffer.

9. Fixed an issue whereby, if a JPEG buffer was automatically re-allocated by one of the TurboJPEG compression or transform functions and an error subsequently occurred during compression or transformation, the JPEG buffer pointer passed by the application was not updated when the function returned.