1.5.2
Assets
- libjpeg-turbo-1.5.2.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.
Support
Code Quality: Stable
Current Support Category: EOL
Release Notes
Significant changes relative to 1.5.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).
-
Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD code in libjpeg-turbo from building.
-
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.) -
libjpeg-turbo should now build and run with full AltiVec SIMD acceleration on PowerPC-based AmigaOS 4 and OpenBSD systems.
-
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()
andjpeg_crop_scanline()
functions were not being included in jpeg7.dll when libjpeg-turbo was built with-DWITH_JPEG7=1
and-DWITH_MEMSRCDST=1
. -
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.
-
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. -
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. -
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 theJPEGMEM
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 themalloc()
/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. -
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. -
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].