Skip to content

Releases: libjpeg-turbo/libjpeg-turbo

2.0.2

14 Feb 06:20
@dcommander dcommander
2.0.2
a4aa30d
Compare
Choose a tag to compare
2.0.2

Assets

Support

Code Quality: Stable
Current Support Category: Extended

Release Notes

Significant changes relative to 2.0.1:

  1. Fixed a regression introduced by 2.0.1[5] that prevented a runtime search path (rpath) from being embedded in the libjpeg-turbo shared libraries and executables for macOS and iOS. This caused a fatal error of the form "dyld: Library not loaded" when attempting to use one of the executables, unless DYLD_LIBRARY_PATH was explicitly set to the location of the libjpeg-turbo shared libraries.

  2. Fixed an integer overflow and subsequent segfault (CVE-2018-20330) that occurred when attempting to load a BMP file with more than 1 billion pixels using the tjLoadImage() function.

  3. Fixed a buffer overrun (CVE-2018-19664) that occurred when attempting to decompress a specially-crafted malformed JPEG image to a 256-color BMP using djpeg.

  4. Fixed a floating point exception that occurred when attempting to decompress a specially-crafted malformed JPEG image with a specified image width or height of 0 using the C version of TJBench.

  5. The TurboJPEG API will now decompress 4:4:4 JPEG images with 2x1, 1x2, 3x1, or 1x3 luminance and chrominance sampling factors. This is a non-standard way of specifying 1x subsampling (normally 4:4:4 JPEGs have 1x1 luminance and chrominance sampling factors), but the JPEG format and the libjpeg API both allow it.

  6. Fixed a regression introduced by 2.0 beta1[7] that caused djpeg to generate incorrect PPM images when used with the -colors option.

  7. Fixed an issue whereby a static build of libjpeg-turbo (a build in which ENABLE_SHARED is 0) could not be installed using the Visual Studio IDE.

  8. Fixed a severe performance issue in the Loongson MMI SIMD extensions that occurred when compressing RGB images whose image rows were not 64-bit-aligned.

Assets 16

2.0.1

12 Nov 20:30
@dcommander dcommander
2.0.1
bb3d325
Compare
Choose a tag to compare
2.0.1

Assets

Support

Code Quality: Stable
Current Support Category: Extended

Release Notes

Significant changes relative to 2.0.0:

  1. Fixed a regression introduced with the new CMake-based Un*x build system, whereby jconfig.h could cause compiler warnings of the form "HAVE_*_H" redefined if it was included by downstream Autotools-based projects that used AC_CHECK_HEADERS() to check for the existence of locale.h, stddef.h, or stdlib.h.

  2. The jsimd_quantize_float_dspr2() and jsimd_convsamp_float_dspr2() functions in the MIPS DSPr2 SIMD extensions are now disabled at compile time if the soft float ABI is enabled. Those functions use instructions that are incompatible with the soft float ABI.

  3. Fixed a regression in the SIMD feature detection code, introduced by the AVX2 SIMD extensions (2.0 beta1[1]), that caused libjpeg-turbo to crash on Windows 7 if Service Pack 1 was not installed.

  4. Fixed out-of-bounds read in cjpeg that occurred when attempting to compress a specially-crafted malformed color-index (8-bit-per-sample) Targa file in which some of the samples (color indices) exceeded the bounds of the Targa file's color table.

  5. Fixed an issue whereby installing a fully static build of libjpeg-turbo (a build in which CFLAGS contains -static and ENABLE_SHARED is 0) would fail with "No valid ELF RPATH or RUNPATH entry exists in the file."

Assets 16

2.0.0

27 Jul 21:04
@dcommander dcommander
2.0.0
574f3a7
Compare
Choose a tag to compare
2.0.0

Assets

Support

Code Quality: Stable
Current Support Category: Extended

Release Sponsors

This release was made possible via a generous MOSS (Mozilla Open Source Support) grant from Mozilla Research.

Mozilla Research

Release Notes

Significant changes relative to 2.0 beta1:

  1. The TurboJPEG API can now decompress CMYK JPEG images that have subsampled M and Y components (not to be confused with YCCK JPEG images, in which the C/M/Y components have been transformed into luma and chroma.) Previously, an error was generated ("Could not determine subsampling type for JPEG image") when such an image was passed to tjDecompressHeader3(), tjTransform(), tjDecompressToYUVPlanes(), tjDecompressToYUV2(), or the equivalent Java methods.

  2. Fixed an issue (CVE-2018-11813) whereby a specially-crafted malformed input file (specifically, a file with a valid Targa header but incomplete pixel data) would cause cjpeg to generate a JPEG file that was potentially thousands of times larger than the input file. The Targa reader in cjpeg was not properly detecting that the end of the input file had been reached prematurely, so after all valid pixels had been read from the input, the reader injected dummy pixels with values of 255 into the JPEG compressor until the number of pixels specified in the Targa header had been compressed. The Targa reader in cjpeg now behaves like the PPM reader and aborts compression if the end of the input file is reached prematurely. Because this issue only affected cjpeg and not the underlying library, and because it did not involve any out-of-bounds reads or other exploitable behaviors, it was not believed to represent a security threat.

  3. Fixed an issue whereby the tjLoadImage() and tjSaveImage() functions would produce a "Bogus message code" error message if the underlying bitmap and PPM readers/writers threw an error that was specific to the readers/writers (as opposed to a general libjpeg API error.)

  4. Fixed an issue (CVE-2018-1152) whereby a specially-crafted malformed BMP file, one in which the header specified an image width of 1073741824 pixels, would trigger a floating point exception (division by zero) in the tjLoadImage() function when attempting to load the BMP file into a 4-component image buffer.

  5. Fixed an issue whereby certain combinations of calls to jpeg_skip_scanlines() and jpeg_read_scanlines() could trigger an infinite loop when decompressing progressive JPEG images that use vertical chroma subsampling (for instance, 4:2:0 or 4:4:0.)

  6. Fixed a segfault in jpeg_skip_scanlines() that occurred when decompressing a 4:2:2 or 4:2:0 JPEG image using the merged (non-fancy) upsampling algorithms (that is, when setting cinfo.do_fancy_upsampling to FALSE.)

  7. The new CMake-based build system will now disable the MIPS DSPr2 SIMD extensions if it detects that the compiler does not support DSPr2 instructions.

  8. Fixed out-of-bounds read in cjpeg (CVE-2018-14498) that occurred when attempting to compress a specially-crafted malformed color-index (8-bit-per-sample) BMP file in which some of the samples (color indices) exceeded the bounds of the BMP file's color table.

  9. Fixed a signed integer overflow in the progressive Huffman decoder, detected by the Clang and GCC undefined behavior sanitizers, that could be triggered by attempting to decompress a specially-crafted malformed JPEG image. This issue did not pose a security threat, but removing the warning made it easier to detect actual security issues, should they arise in the future.

Assets 16

1.5.90 (2.0 beta1)

24 Mar 13:19
@dcommander dcommander
1.5.90
c80ddef
Compare
Choose a tag to compare
1.5.90 (2.0 beta1) Pre-release
Pre-release

Assets

Support

Code Quality: Beta
Current Support Category: EOL

Release Notes

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.

Assets 16

1.5.3

14 Dec 06:08
@dcommander dcommander
1.5.3
bf6c774
Compare
Choose a tag to compare
1.5.3

Assets

Support

Code Quality: Stable
Current Support Category: EOL

Release Notes

Significant changes relative to 1.5.2:

  1. Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred when using the YUVImage constructor that creates an instance backed by separate image planes and allocates memory for the image planes.

  2. Fixed an issue whereby the Java version of TJUnitTest would fail when testing BufferedImage encoding/decoding on big endian systems.

  3. Fixed a segfault in djpeg that would occur if an output format other than PPM/PGM was selected along with the -crop option. The -crop option now works with the GIF and Targa formats as well (unfortunately, it cannot be made to work with the BMP and RLE formats due to the fact that those output engines write scanlines in bottom-up order.) djpeg will now exit gracefully if an output format other than PPM/PGM, GIF, or Targa is selected along with the -crop option.

  4. Fixed an issue (CVE-2017-15232) whereby jpeg_skip_scanlines() would segfault if color quantization was enabled.

  5. TJBench (both C and Java versions) will now display usage information if any command-line argument is unrecognized. This prevents the program from silently ignoring typos.

  6. Fixed an access violation in tjbench.exe (Windows) that occurred when the program was used to decompress an existing JPEG image.

  7. Fixed an ArrayIndexOutOfBoundsException in the TJExample Java program that occurred when attempting to decompress a JPEG image that had been compressed with 4:1:1 chrominance subsampling.

  8. Fixed an issue whereby, when using jpeg_skip_scanlines() to skip to the end of a single-scan (non-progressive) image, subsequent calls to jpeg_consume_input() would return JPEG_SUSPENDED rather than JPEG_REACHED_EOI.

  9. jpeg_crop_scanline() now works correctly when decompressing grayscale JPEG images that were compressed with a sampling factor other than 1 (for instance, with cjpeg -grayscale -sample 2x2).

Assets 16

1.5.2

09 Aug 21:30
@dcommander dcommander
1.5.2
e5c1613
Compare
Choose a tag to compare
1.5.2

Assets

Support

Code Quality: Stable
Current Support Category: EOL

Release Notes

Significant changes relative to 1.5.1:

  1. Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from building with Android NDK platforms prior to android-21 (5.0).

  2. Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD code in libjpeg-turbo from building.

  3. Fixed a regression introduced by 1.5 beta1[11] that prevented the Java version of TJBench from outputting any reference images (the -nowrite switch was accidentally enabled by default.)

  4. libjpeg-turbo should now build and run with full AltiVec SIMD acceleration on PowerPC-based AmigaOS 4 and OpenBSD systems.

  5. Fixed build and runtime errors on Windows that occurred when building libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory source/destination managers. Due to an oversight, the jpeg_skip_scanlines() and jpeg_crop_scanline() functions were not being included in jpeg7.dll when libjpeg-turbo was built with -DWITH_JPEG7=1 and -DWITH_MEMSRCDST=1.

  6. Fixed "Bogus virtual array access" error that occurred when using the lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was built with libjpeg v7 API/ABI emulation. This was apparently a long-standing bug that has existed since the introduction of libjpeg v7/v8 API/ABI emulation in libjpeg-turbo v1.1.

  7. The lossless transform features in jpegtran and the TurboJPEG API will now always attempt to adjust the EXIF image width and height tags if the image size changed as a result of the transform. This behavior has always existed when using libjpeg v8 API/ABI emulation. It was supposed to be available with libjpeg v7 API/ABI emulation as well but did not work properly due to a bug. Furthermore, there was never any good reason not to enable it with libjpeg v6b API/ABI emulation, since the behavior is entirely internal. Note that -copy all must be passed to jpegtran in order to transfer the EXIF tags from the source image to the destination image.

  8. Fixed several memory leaks in the TurboJPEG API library that could occur if the library was built with certain compilers and optimization levels (known to occur with GCC 4.x and clang with -O1 and higher but not with GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error after a TurboJPEG API function allocated a local buffer.

  9. The libjpeg-turbo memory manager will now honor the max_memory_to_use structure member in jpeg_memory_mgr, which can be set to the maximum amount of memory (in bytes) that libjpeg-turbo should use during decompression or multi-pass (including progressive) compression. This limit can also be set using the JPEGMEM environment variable or using the -maxmemory switch in cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.) This has been a documented feature of libjpeg since v5, but the malloc()/free() implementation of the memory manager (jmemnobs.c) never implemented the feature. Restricting libjpeg-turbo's memory usage is useful for two reasons: it allows testers to more easily work around the 2 GB limit in libFuzzer, and it allows developers of security-sensitive applications to more easily defend against one of the progressive JPEG exploits (LJT-01-004) identified in this report.

  10. TJBench will now run each benchmark for 1 second prior to starting the timer, in order to improve the consistency of the results. Furthermore, the -warmup option is now used to specify the amount of warmup time rather than the number of warmup iterations.

  11. Fixed an error (short jump is out of range) that occurred when assembling the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a regression introduced by 1.5 beta1[12].

Assets 16

1.5.1

21 Sep 00:25
@dcommander dcommander
1.5.1
cb88e5d
Compare
Choose a tag to compare
1.5.1

Assets

  • libjpeg-turbo-1.5.1.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
  • Refer to https://libjpeg-turbo.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
  • Refer to https://libjpeg-turbo.org/Documentation/OfficialBinaries for information regarding the compatibility of the binary packages in this release.
  • The iOS binaries are now built using Clang in Xcode 7.2.x with bitcode enabled. Testing has revealed no significant performance regression from this, and it greatly facilitates using libjpeg-turbo to develop applications for iOS 9 and later, as well as watchOS and tvOS (both of which require bitcode.)

Packaging Changes

  • The iOS binaries are now built using Clang in Xcode 7.2.x with bitcode enabled. Testing has revealed no significant performance regression from this, and it greatly facilitates using libjpeg-turbo to develop applications for iOS 9 and later, as well as watchOS and tvOS (both of which require bitcode.)

Support

Code Quality: Stable
Current Support Category: EOL

Release Notes

Significant changes relative to 1.5.0:

  1. Previously, the undocumented JSIMD_FORCE* environment variables could be used to force-enable a particular SIMD instruction set if multiple instruction sets were available on a particular platform. On x86 platforms, where CPU feature detection is bulletproof and multiple SIMD instruction sets are available, it makes sense for those environment variables to allow forcing the use of an instruction set only if that instruction set is available. However, since the ARM implementations of libjpeg-turbo can only use one SIMD instruction set, and since their feature detection code is less bulletproof (parsing /proc/cpuinfo), it makes sense for the JSIMD_FORCENEON environment variable to bypass the feature detection code and really force the use of NEON instructions. A new environment variable (JSIMD_FORCEDSPR2) was introduced in the MIPS implementation for the same reasons, and the existing JSIMD_FORCENONE environment variable was extended to that implementation. These environment variables provide a workaround for those attempting to test ARM and MIPS builds of libjpeg-turbo in QEMU, which passes through /proc/cpuinfo from the host system.

  2. libjpeg-turbo previously assumed that AltiVec instructions were always available on PowerPC platforms, which led to "illegal instruction" errors when running on PowerPC chips that lack AltiVec support (such as the older 7xx/G3 and newer e5500 series.) libjpeg-turbo now examines /proc/cpuinfo on Linux/Android systems and enables AltiVec instructions only if the CPU supports them. It also now provides two environment variables, JSIMD_FORCEALTIVEC and JSIMD_FORCENONE, to force-enable and force-disable AltiVec instructions in environments where /proc/cpuinfo is an unreliable means of CPU feature detection (such as when running in QEMU.) On OS X, libjpeg-turbo continues to assume that AltiVec support is always available, which means that libjpeg-turbo cannot be used with G3 Macs unless you set the environment variable JSIMD_FORCENONE to 1.

  3. Fixed an issue whereby 64-bit ARM (AArch64) builds of libjpeg-turbo would crash when built with recent releases of the Clang/LLVM compiler. This was caused by an ABI conformance issue in some of libjpeg-turbo's 64-bit NEON SIMD routines. Those routines were incorrectly using 64-bit instructions to transfer a 32-bit JDIMENSION argument, whereas the ABI allows the upper (unused) 32 bits of a 32-bit argument's register to be undefined. The new Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit structure members into a single 64-bit register, and this exposed the ABI conformance issue.

  4. Fancy upsampling is now supported when decompressing JPEG images that use 4:4:0 (h1v2) chroma subsampling. These images are generated when losslessly rotating or transposing JPEG images that use 4:2:2 (h2v1) chroma subsampling. The h1v2 fancy upsampling algorithm is not currently SIMD-accelerated.

  5. If merged upsampling isn't SIMD-accelerated but YCbCr-to-RGB conversion is, then libjpeg-turbo will now disable merged upsampling when decompressing YCbCr JPEG images into RGB or extended RGB output images. This significantly speeds up the decompression of 4:2:0 and 4:2:2 JPEGs on ARM platforms if fancy upsampling is not used (for example, if the -nosmooth option to djpeg is specified.)

  6. The TurboJPEG API will now decompress 4:2:2 and 4:4:0 JPEG images with 2x2 luminance sampling factors and 2x1 or 1x2 chrominance sampling factors. This is a non-standard way of specifying 2x subsampling (normally 4:2:2 JPEGs have 2x1 luminance and 1x1 chrominance sampling factors, and 4:4:0 JPEGs have 1x2 luminance and 1x1 chrominance sampling factors), but the JPEG format and the libjpeg API both allow it.

  7. Fixed an unsigned integer overflow in the libjpeg memory manager, detected by the Clang undefined behavior sanitizer, that could be triggered by attempting to decompress a specially-crafted malformed JPEG image. This issue affected only 32-bit code and did not pose a security threat, but removing the warning makes it easier to detect actual security issues, should they arise in the future.

  8. Fixed additional negative left shifts and other issues reported by the GCC and Clang undefined behavior sanitizers when attempting to decompress specially-crafted malformed JPEG images. None of these issues posed a security threat, but removing the warnings makes it easier to detect actual security issues, should they arise in the future.

  9. Fixed an out-of-bounds array reference, introduced by 1.4.90[2] (partial image decompression) and detected by the Clang undefined behavior sanitizer, that could be triggered by a specially-crafted malformed JPEG image with more than four components. Because the out-of-bounds reference was still within the same structure, it was not known to pose a security threat, but removing the warning makes it easier to detect actual security issues, should they arise in the future.

  10. Fixed another ABI conformance issue in the 64-bit ARM (AArch64) NEON SIMD code. Some of the routines were incorrectly reading and storing data below the stack pointer, which caused segfaults in certain applications under specific circumstances.

Assets 16

1.5.0

07 Jun 18:00
@dcommander dcommander
1.5.0
3ff13e6
Compare
Choose a tag to compare
1.5.0

Assets

Support

Code Quality: Stable
Current Support Category: EOL

Release Notes

Significant changes relative to 1.5 beta1:

  1. Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory.

  2. Added libjpeg-turbo version and build information to the global string table of the libjpeg and TurboJPEG API libraries. This is a common practice in other infrastructure libraries, such as OpenSSL and libpng, because it makes it easy to examine an application binary and determine which version of the library the application was linked against.

  3. Fixed a couple of issues in the PPM reader that would cause buffer overruns in cjpeg if one of the values in a binary PPM/PGM input file exceeded the maximum value defined in the file's header and that maximum value was greater than 255. libjpeg-turbo 1.4.2 already included a similar fix for ASCII PPM/PGM files. Note that these issues were not security bugs, since they were confined to the cjpeg program and did not affect any of the libjpeg-turbo libraries.

  4. Fixed an issue whereby attempting to decompress a JPEG file with a corrupt header using the tjDecompressToYUV2() function would cause the function to abort without returning an error and, under certain circumstances, corrupt the stack. This only occurred if tjDecompressToYUV2() was called prior to calling tjDecompressHeader3(), or if the return value from tjDecompressHeader3() was ignored (both cases represent incorrect usage of the TurboJPEG API.)

  5. Fixed an issue in the ARM 32-bit SIMD-accelerated Huffman encoder that prevented the code from assembling properly with clang.

  6. The jpeg_stdio_src(), jpeg_mem_src(), jpeg_stdio_dest(), and jpeg_mem_dest() functions in the libjpeg API will now throw an error if a source/destination manager has already been assigned to the compress or decompress object by a different function or by the calling program. This prevents these functions from attempting to reuse a source/destination manager structure that was allocated elsewhere, because there is no way to ensure that it would be big enough to accommodate the new source/destination manager.

Assets 16

1.4.90 (1.5 beta1)

29 Feb 18:40
@dcommander dcommander
1.4.90
056536f
Compare
Choose a tag to compare
1.4.90 (1.5 beta1) Pre-release
Pre-release

Assets

Support

Code Quality: Beta
Current Support Category: EOL

Release Notes

Significant changes relative to 1.4.2:

  1. Added full SIMD acceleration for PowerPC platforms using AltiVec VMX (128-bit SIMD) instructions. Although the performance of libjpeg-turbo on PowerPC was already good, due to the increased number of registers available to the compiler vs. x86, it was still possible to speed up compression by about 3-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the use of AltiVec instructions.

  2. Added two new libjpeg API functions (jpeg_skip_scanlines() and jpeg_crop_scanline()) that can be used to partially decode a JPEG image. See libjpeg.txt for more details.

  3. The TJCompressor and TJDecompressor classes in the TurboJPEG Java API now implement the Closeable interface, so those classes can be used with a try-with-resources statement.

  4. The TurboJPEG Java classes now throw unchecked idiomatic exceptions (IllegalArgumentException, IllegalStateException) for unrecoverable errors caused by incorrect API usage, and those classes throw a new checked exception type (TJException) for errors that are passed through from the C library.

  5. Source buffers for the TurboJPEG C API functions, as well as the jpeg_mem_src() function in the libjpeg API, are now declared as const pointers. This facilitates passing read-only buffers to those functions and ensures the caller that the source buffer will not be modified. This should not create any backward API or ABI incompatibilities with prior libjpeg-turbo releases.

  6. The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1 FPUs.

  7. Fixed additional negative left shifts and other issues reported by the GCC and Clang undefined behavior sanitizers. Most of these issues affected only 32-bit code, and none of them was known to pose a security threat, but removing the warnings makes it easier to detect actual security issues, should they arise in the future.

  8. Removed the unnecessary .arch directive from the ARM64 NEON SIMD code. This directive was preventing the code from assembling using the clang integrated assembler.

  9. Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora distributions. This was due to the addition of a macro in jconfig.h that allows the Huffman codec to determine the word size at compile time. Since that macro differs between 32-bit and 64-bit builds, this caused a conflict between the i386 and x86_64 RPMs (any differing files, other than executables, are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.) Since the macro is used only internally, it has been moved into jconfigint.h.

  10. The x86-64 SIMD code can now be disabled at run time by setting the JSIMD_FORCENONE environment variable to 1 (the other SIMD implementations already had this capability.)

  11. Added a new command-line argument to TJBench (-nowrite) that prevents the benchmark from outputting any images. This removes any potential operating system overhead that might be caused by lazy writes to disk and thus improves the consistency of the performance measurements.

  12. Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and x86-64 platforms. This speeds up the compression of full-color JPEGs by about 10-15% on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and AMD CPUs. Additionally, this works around an issue in the clang optimizer that prevents it (as of this writing) from achieving the same performance as GCC when compiling the C version of the Huffman encoder (https://llvm.org/bugs/show_bug.cgi?id=16035). For the purposes of benchmarking or regression testing, SIMD-accelerated Huffman encoding can be disabled by setting the JSIMD_NOHUFFENC environment variable to 1.

  13. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used compression algorithms (including the accurate integer forward DCT and h2v2 & h2v1 downsampling algorithms, which are not accelerated in the 32-bit NEON implementation.) This speeds up the compression of full-color JPEGs by about 75% on average on a Cavium ThunderX processor and by about 2-2.5x on average on Cortex-A53 and Cortex-A57 cores.

  14. Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit and 64-bit platforms.

    For 32-bit code, this speeds up the compression of full-color JPEGs by about 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by about 6-7% on average on a typical Android device (Nexus 5X, Cortex-A53 and Cortex-A57), relative to libjpeg-turbo 1.4.x. Note that the larger speedup under iOS is due to the fact that iOS builds use LLVM, which does not optimize the C Huffman encoder as well as GCC does.

    For 64-bit code, NEON-accelerated Huffman encoding speeds up the compression of full-color JPEGs by about 40% on average on a typical iOS device (iPhone 5S, Apple A7) and by about 7-8% on average on a typical Android device (Nexus 5X, Cortex-A53 and Cortex-A57), in addition to the speedup described in [13] above.

    For the purposes of benchmarking or regression testing, SIMD-accelerated Huffman encoding can be disabled by setting the JSIMD_NOHUFFENC environment variable to 1.

  15. pkg-config (.pc) scripts are now included for both the libjpeg and TurboJPEG API libraries on Un*x systems. Note that if a project's build system relies on these scripts, then it will not be possible to build that project with libjpeg or with a prior version of libjpeg-turbo.

  16. Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to improve performance on CPUs with in-order pipelines. This speeds up the decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX processor and by about 15% on average on a Cortex-A53 core.

  17. Fixed an issue in the accelerated Huffman decoder that could have caused the decoder to read past the end of the input buffer when a malformed, specially-crafted JPEG image was being decompressed. In prior versions of libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only if there were > 128 bytes of data in the input buffer. However, it is possible to construct a JPEG image in which a single Huffman block is over 430 bytes long, so this version of libjpeg-turbo activates the accelerated Huffman decoder only if there are > 512 bytes of data in the input buffer.

  18. Fixed a memory leak in tjunittest encountered when running the program with the -yuv option.

Assets 16

1.4.2

21 Sep 22:31
@dcommander dcommander
1.4.2
d8da49e
Compare
Choose a tag to compare
1.4.2

Assets

Packaging Changes

  • The OS X binaries are now built using GCC 5.x, which improves performance relative to libjpeg-turbo 1.4.1, particularly when using i386 code.
  • The source has been processed with a recent version of autotools, so it should no longer be necessary to run autoreconf on it before building iOS binaries.

Support

Code Quality: Stable
Current Support Category: EOL

Release Notes

Significant changes relative to 1.4.1:

  1. Fixed an issue whereby cjpeg would segfault if a Windows bitmap with a negative width or height was used as an input image (Windows bitmaps can have a negative height if they are stored in top-down order, but such files are rare and not supported by libjpeg-turbo.)

  2. Fixed an issue whereby, under certain circumstances, libjpeg-turbo would incorrectly encode certain JPEG images when quality=100 and the fast integer forward DCT were used. This was known to cause make test to fail when the library was built with -march=haswell on x86 systems.

  3. Fixed an issue whereby libjpeg-turbo would crash when built with the latest & greatest development version of the Clang/LLVM compiler. This was caused by an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD routines. Those routines were incorrectly using a 64-bit mov instruction to transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper (unused) 32 bits of a 32-bit argument's register to be undefined. The new Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit structure members into a single 64-bit register, and this exposed the ABI conformance issue.

  4. Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged) upsampling routine that caused a buffer overflow (and subsequent segfault) when decompressing a 4:2:0 JPEG image whose scaled output width was less than 16 pixels. The "plain" upsampling routines are normally only used when decompressing a non-YCbCr JPEG image, but they are also used when decompressing a JPEG image whose scaled output height is 1.

  5. Fixed various negative left shifts and other issues reported by the GCC and Clang undefined behavior sanitizers. None of these was known to pose a security threat, but removing the warnings makes it easier to detect actual security issues, should they arise in the future.

Assets 16