Softpedia >Windows >Multimedia >Graphic >Graphic Others >libjpeg-turbo >  Changelog

libjpeg-turbo Changelog

What's new in libjpeg-turbo 2.1.1

Aug 10, 2021
  • Significant changes relative to 2.1.0:
  • Fixed a regression introduced in 2.1.0 that caused build failures with non-GCC-compatible compilers for Un*x/Arm platforms.
  • 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.
  • 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.
  • 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.
  • libjpeg-turbo should now build and run on CHERI-enabled architectures, which use capability pointers that are larger than the size of size_t.
  • Fixed a regression 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.

New in libjpeg-turbo 2.1.0 (Apr 23, 2021)

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

New in libjpeg-turbo 2.0.6 (Mar 31, 2021)

  • Fixed "using JNI after critical get" errors that occurred on Android
  • Platforms when using any of the YUV encoding/compression/decompression/decoding
  • Methods in the TurboJPEG Java API.
  • Fixed or worked around multiple issues with `jpeg_skip_scanlines()`:
  • Fixed segfaults or "Corrupt JPEG data: premature end of data segment"
  • Errors in `jpeg_skip_scanlines()` that occurred when decompressing 4:2:2 or
  • 4:2:0 JPEG images using merged (non-fancy) upsampling/color conversion (that
  • Is, when setting `cinfo.do_fancy_upsampling` to `FALSE`.) 2.0.0[6] was a
  • Similar fix, but it did not cover all cases.
  • `jpeg_skip_scanlines()` now throws an error if two-pass color
  • Quantization is enabled. Two-pass color quantization never worked properly
  • With `jpeg_skip_scanlines()`, and the issues could not readily be fixed.
  • Fixed an issue whereby `jpeg_skip_scanlines()` always returned 0 when
  • Skipping past the end of an image.
  • The Arm 64-bit (Armv8) Neon SIMD extensions can now be built using MinGW
  • Toolchains targetting Arm64 (AArch64) Windows binaries.
  • Fixed unexpected visual artifacts that occurred when using
  • `jpeg_crop_scanline()` and interblock smoothing while decompressing only the DC
  • Scan of a progressive JPEG image.
  • Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-component
  • JPEG support (`WITH_12BIT`) was enabled along with libjpeg v7 or libjpeg v8
  • API/ABI emulation (`WITH_JPEG7` or `WITH_JPEG8`.)

New in libjpeg-turbo 2.0.5 (Jun 24, 2020)

  • Worked around issues in the MIPS DSPr2 SIMD extensions that caused failures in the libjpeg-turbo regression tests. Specifically, the jsimd_h2v1_downsample_dspr2() and jsimd_h2v2_downsample_dspr2() functions in the MIPS DSPr2 SIMD extensions are now disabled until/unless they can be fixed, and other functions that are incompatible with big endian MIPS CPUs are disabled when building libjpeg-turbo for such CPUs.
  • Fixed an oversight in the TJCompressor.compress(int) method in the TurboJPEG Java API that caused an error ("java.lang.IllegalStateException: No source image is associated with this instance") when attempting to use that method to compress a YUV image.
  • Fixed an issue (CVE-2020-13790) in the PPM reader that caused a buffer overrun in cjpeg, TJBench, or the tjLoadImage() function 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 less than 255. libjpeg-turbo 1.5.0 already included a similar fix for binary PPM/PGM files with maximum values greater than 255.
  • The TurboJPEG API library's global error handler, which is used in functions such as tjBufSize() and tjLoadImage() that do not require a TurboJPEG instance handle, is now thread-safe on platforms that support thread-local storage.

New in libjpeg-turbo 2.0.4 (Dec 31, 2019)

  • Fixed a regression in the Windows packaging system (introduced by 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo SDK for GCC and the 64-bit libjpeg-turbo SDK for Visual C++ were installed on the same system, only one of them could be uninstalled.
  • Fixed a signed integer overflow and subsequent segfault that occurred when attempting to decompress images with more than 715827882 pixels using the 64-bit C version of TJBench.
  • Fixed out-of-bounds write in tjDecompressToYUV2() and tjDecompressToYUVPlanes() (sometimes manifesting as a double free) that occurred when attempting to decompress grayscale JPEG images that were compressed with a sampling factor other than 1 (for instance, with cjpeg -grayscale -sample 2x2).
  • Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to incorrectly identify some JPEG images with unusual sampling factors as 4:4:4 JPEG images. This was known to cause a buffer overflow when attempting to decompress some such images using tjDecompressToYUV2() or tjDecompressToYUVPlanes().
  • Fixed an issue, detected by ASan, whereby attempting to losslessly transform a specially-crafted malformed JPEG image containing an extremely-high-frequency coefficient block (junk image data that could never be generated by a legitimate JPEG compressor) could cause the Huffman encoder's local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) Given that the buffer overrun was fully contained within the stack and did not cause a segfault or other user-visible errant behavior, and given that the lossless transformer (unlike the decompressor) is not generally exposed to arbitrary data exploits, this issue did not likely pose a security risk.
  • The ARM 64-bit (ARMv8) NEON SIMD assembly code now stores constants in a separate read-only data section rather than in the text section, to support execute-only memory layouts.

New in libjpeg-turbo 2.0.3 (Sep 5, 2019)

  • Fixed "using JNI after critical get" errors that occurred on Android platforms when passing invalid arguments to certain methods in the TurboJPEG Java API.
  • Fixed a regression in the SIMD feature detection code, introduced by the AVX2 SIMD extensions (2.0 beta1[1]), that was known to cause an illegal instruction exception, in rare cases, on CPUs that lack support for CPUID leaf 07H (or on which the maximum CPUID leaf has been limited by way of a BIOS setting.)
  • The 4:4:0 (h1v2) fancy (smooth) chroma upsampling algorithm in the decompressor now uses a similar bias pattern to that of the 4:2:2 (h2v1) fancy chroma upsampling algorithm, rounding up or down the upsampled result for alternate pixels rather than always rounding down. This ensures that, regardless of whether a 4:2:2 JPEG image is rotated or transposed prior to decompression (in the frequency domain) or after decompression (in the spatial domain), the final image will be similar.
  • Fixed an integer overflow and subsequent segfault that occurred when attempting to compress or decompress images with more than 1 billion pixels using the TurboJPEG API.
  • 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 16 would result in an error ("Missing Huffman code table entry") and an invalid JPEG image.
  • Fixed an issue whereby tjDecodeYUV() and tjDecodeYUVPlanes() would throw an error ("Invalid progressive parameters") or a warning ("Inconsistent progression sequence") if passed a TurboJPEG instance that was previously used to decompress a progressive JPEG image.

New in libjpeg-turbo 2.0.2 (Feb 14, 2019)

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Fixed a regression introduced by 2.0 beta1[7] that caused djpeg to generate incorrect PPM images when used with the -colors option.
  • 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.
  • 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.

New in libjpeg-turbo 2.0.1 (Nov 13, 2018)

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

New in libjpeg-turbo 1.5.3 (Dec 14, 2017)

  • 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.
  • Fixed an issue whereby the Java version of TJUnitTest would fail when testing BufferedImage encoding/decoding on big endian systems.
  • 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.
  • Fixed an issue whereby jpeg_skip_scanlines() would segfault if color quantization was enabled.
  • 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.
  • Fixed an access violation in tjbench.exe (Windows) that occurred when the program was used to decompress an existing JPEG image.
  • 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.
  • 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.
  • jpeg_crop_scanlines() 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).

New in libjpeg-turbo 1.5.2 (Jul 26, 2017)

  • 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() and jpeg_crop_scanlines() 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 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.
  • 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].

New in libjpeg-turbo 1.5.1 (Apr 14, 2017)

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.)
  • 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 specification and the libjpeg API both allow it.
  • 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.
  • 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.
  • 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.
  • 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.

New in libjpeg-turbo 1.3.1 (Mar 26, 2014)

  • The Windows installer now places a copy of the TurboJPEG DLLs in the same directory as the rest of the libjpeg-turbo binaries. This was mainly done to support TurboVNC 1.3, which bundles the DLLs in its Windows installation. When using a 32-bit version of CMake on 64-bit Windows, it is impossible to access the c:\WINDOWS\system32 directory, which made it impossible for the TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL.
  • Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic entropy coding (by passing arguments of -progressive -arithmetic to cjpeg or jpegtran, for instance) would result in an error, "Requested feature was omitted at compile time".
  • Fixed a couple of issues whereby malformed JPEG images would cause libjpeg-turbo to use uninitialized memory during decompression.
  • Fixed an error ("Buffer passed to JPEG library is too small") that occurred when calling the TurboJPEG YUV encoding function with a very small (< 5x5) source image, and added a unit test to check for this error.
  • The Java classes should now build properly under Visual Studio 2010 and later.
  • Numerous minor fixes to eliminate compilation and build/packaging system warnings, fix cosmetic issues, improve documentation clarity, and other general source cleanup.

New in libjpeg-turbo 1.3.0 (Jun 3, 2013)

  • 'make test' now works properly on FreeBSD, and it no longer requires the md5sum executable to be present on other Un*x platforms.
  • Overhauled the packaging system:
  • To avoid conflict with vendor-supplied libjpeg-turbo packages, the official RPMs and DEBs for libjpeg-turbo have been renamed to "libjpeg-turbo-official".
  • Release packages are now created with the directory structure defined by the configure variables "prefix", "bindir", "libdir", etc. (Un*x) or by the CMAKE_INSTALL_PREFIX variable (Windows.) The exception is that the docs are always located under the system default documentation directory on Un*x and Mac systems, and on Windows, the TurboJPEG DLL is always located in the Windows system directory.
  • To avoid confusion, official libjpeg-turbo packages on Linux/Unix platforms (except for Mac) will always install the 32-bit libraries in /opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64.
  • Fixed an issue whereby, in some cases, the libjpeg-turbo executables on Un*x systems were not properly linking with the shared libraries installed by the same package.
  • Fixed an issue whereby building the "installer" target on Windows when WITH_JAVA=1 would fail if the TurboJPEG JAR had not been previously built.
  • Building the "install" target on Windows now installs files into the same places that the installer does.
  • Fixed a Huffman encoder bug that prevented I/O suspension from working properly.

New in libjpeg-turbo 1.2.90 Beta (Feb 5, 2013)

  • Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4, 11/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing. Note that the IDCT will not be SIMD-accelerated when using any of these new scaling factors.
  • The TurboJPEG dynamic library is now versioned. It was not strictly necessary to do so, because TurboJPEG uses versioned symbols, and if a function changes in an ABI-incompatible way, that function is renamed and a legacy function is provided to maintain backward compatibility.
  • Extended the TurboJPEG Java API so that it can be used to compress a JPEG image from and decompress a JPEG image to an arbitrary position in a large image buffer.
  • The tjDecompressToYUV() function now supports the TJFLAG_FASTDCT flag.
  • The 32-bit supplementary package for amd64 Debian systems now provides symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32.
  • The TurboJPEG Java wrapper should now find the JNI library on Mac systems without having to pass -Djava.library.path=/usr/lib to java.
  • TJBench has been ported to Java to provide a convenient way of validating the performance of the TurboJPEG Java API. It can be run with 'java -cp turbojpeg.jar TJBench'.
  • cjpeg can now be used to generate JPEG files with the RGB colorspace (feature ported from jpeg-8d.)
  • The width and height in the -crop argument passed to jpegtran can now be suffixed with "f" to indicate that, when the upper left corner of the cropping region is automatically moved to the nearest iMCU boundary, the bottom right corner should be moved by the same amount. In other words, this feature causes jpegtran to strictly honor the specified width/height rather than the specified bottom right corner (feature ported from jpeg-8d.)
  • JPEG files using the RGB colorspace can now be decompressed into grayscale images (feature ported from jpeg-8d.)
  • Fixed a regression caused by 1.2.1 whereby the build would fail with multiple "Mismatch in operand sizes" errors when attempting to build the x86 SIMD code with NASM 0.98.
  • The in-memory source/destination managers (jpeg_mem_src() and jpeg_mem_dest()) are now included by default when building libjpeg-turbo with libjpeg v6b or v7 emulation, so that programs can take advantage of these functions without requiring the use of the backward-incompatible libjpeg v8 ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been incremented by 1 to reflect this. You can disable this feature with a configure/CMake switch in order to retain strict API/ABI compatibility with the libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See README-turbo.txt for more details.

New in libjpeg-turbo 1.2.1 (Aug 9, 2012)

  • Creating or decoding a JPEG file that uses the RGB colorspace should now properly work when the input or output colorspace is one of the libjpeg-turbo colorspace extensions.
  • When libjpeg-turbo was built without SIMD support and merged (non-fancy) upsampling was used along with an alpha-enabled colorspace during decompression, the unused byte of the decompressed pixels was not being set to 0xFF. This has been fixed. TJUnitTest has also been extended to test for the correct behavior of the colorspace extensions when merged upsampling is used.
  • Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the upper 64 bits of xmm6 and xmm7 on Win64 platforms, which violated the Win64 calling conventions.
  • Fixed a regression caused by 1.2.0 whereby decompressing corrupt JPEG images (specifically, images in which the component count was erroneously set to a large value) would cause libjpeg-turbo to segfault.
  • Worked around a severe performance issue with "Bobcat" (AMD Embedded APU) processors. The MASKMOVDQU instruction, which was used by the libjpeg-turbo SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and it is painfully slow on Bobcat processors in particular. Eliminating the use of this instruction improved performance by an order of magnitude on Bobcat processors and by a small amount (typically 5%) on AMD desktop processors.
  • Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such platforms.
  • Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or 4:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy upsampling would produce several incorrect columns of pixels at the right-hand side of the output image if each row in the output image was not evenly divisible by 16 bytes.
  • Fixed an issue whereby attempting to build the SIMD extensions with Xcode 4.3 on OS X platforms would cause NASM to return numerous errors of the form "'�fine' expects a macro identifier".
  • Added flags to the TurboJPEG API that allow the caller to force the use of either the fast or the accurate DCT/IDCT algorithms in the underlying codec.

New in libjpeg-turbo 1.2.0 (Feb 11, 2012)

  • Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system was not adding the current directory to the assembler include path, so YASM was not able to find jsimdcfg.inc.)
  • Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes. This was more of an annoyance than an actual bug, since it did not cause any actual run-time problems, but the issue showed up when running libjpeg-turbo in valgrind.
  • Added a compile-time macro (LIBJPEG_TURBO_VERSION) that can be used to check the version of libjpeg-turbo against which an application was compiled.
  • Added new RGBA/BGRA/ABGR/ARGB colorspace extension constants (libjpeg API) and pixel formats (TurboJPEG API), which allow applications to specify that, when decompressing to a 4-component RGB buffer, the unused byte should be set to 0xFF so that it can be interpreted as an opaque alpha channel.
  • Fixed regression issue whereby DevIL failed to build against libjpeg-turbo because libjpeg-turbo's distributed version of jconfig.h contained an INLINE macro, which conflicted with a similar macro in DevIL. This macro is used only internally when building libjpeg-turbo, so it was moved into config.h.
  • libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose K component is assigned a component ID of 1 instead of 4. Although these files are in violation of the spec, other JPEG implementations handle them correctly.
  • Added ARM v6 and ARM v7 architectures to libjpeg.a and libturbojpeg.a in the official OS X distribution package, so that those libraries can be used to build both OS X and iOS applications

New in libjpeg-turbo 1.1.90 (Oct 28, 2011)

  • Added a Java wrapper for the TurboJPEG API. See java/README for more
  • details.
  • The TurboJPEG API can now be used to scale down images during
  • decompression.
  • Added SIMD routines for RGB-to-grayscale color conversion, which
  • significantly improves the performance of grayscale JPEG compression from an RGB source image.
  • Improved the performance of the C color conversion routines, which are used
  • on platforms for which SIMD acceleration is not available.
  • Added a function to the TurboJPEG API that performs lossless transforms.
  • This function is implemented using the same back end as jpegtran, but it
  • performs transcoding entirely in memory and allows multiple transforms and/or crop operations to be batched together, so the source coefficients only need to be read once. This is useful when generating image tiles from a single source JPEG.
  • Added tests for the new TurboJPEG scaled decompression and lossless
  • transform features to tjbench (the TurboJPEG benchmark.)
  • Added support for 4:4:0 (transposed 4:2:2) subsampling in TurboJPEG, which
  • was necessary in order for it to read 4:2:2 JPEG files that had been losslessly
  • transposed or rotated 90 degrees.
  • All legacy VirtualGL code has been re-factored, and this has allowed
  • libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license.
  • libjpeg-turbo can now be built with YASM.
  • Added SIMD acceleration for ARM Linux and iOS platforms that support
  • NEON instructions.
  • Refactored the TurboJPEG C API and documented it using Doxygen. The
  • TurboJPEG 1.2 API uses pixel formats to define the size and component order of
  • the uncompressed source/destination images, and it includes a more efficient
  • version of TJBUFSIZE() that computes a worst-case JPEG size based on the level
  • of chrominance subsampling. The refactored implementation of TurboJPEG/OSS
  • now uses the libjpeg memory source and destination managers, which allows the
  • TurboJPEG compressor to grow the JPEG buffer as necessary.
  • Eliminated errors in the output of jpegtran on Windows that occurred when
  • the application was invoked using I/O redirection
  • (jpegtran output.jpg).
  • The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding
  • support in libjpeg-turbo v1.1.0 introduced several new error constants in
  • jerror.h, and these were mistakenly enabled for all emulation modes, causing
  • the error enum in libjpeg-turbo to sometimes have different values than the
  • same enum in libjpeg. This represents an ABI incompatibility, and it caused
  • problems with rare applications that took specific action based on a particular
  • error value. The fix was to include the new error constants conditionally
  • based on whether libjpeg v7 or v8 emulation was enabled.
  • Fixed an issue whereby Windows applications that used libjpeg-turbo would
  • fail to compile if the Windows system headers were included before jpeglib.h.
  • This issue was caused by a conflict in the definition of the INT32 type.
  • Fixed 32-bit supplementary package for amd64 Debian systems, which was
  • broken by enhancements to the packaging system in 1.1.
  • When decompressing a JPEG image using an output colorspace of
  • JCS_EXT_RGBX, JCS_EXT_BGRX, JCS_EXT_XBGR, or JCS_EXT_XRGB, libjpeg-turbo will
  • now set the unused byte to 0xFF, which allows applications to interpret that
  • byte as an alpha channel (0xFF = opaque).