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
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.
2.1.0
Significant changes relative to 2.1 beta1
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.
2.0.90 (2.1 beta1)
Significant changes relative to 2.0.6:
The build system, x86-64 SIMD extensions, and accelerated Huffman codec now support the x32 ABI on Linux, which allows for using x86-64 instructions with 32-bit pointers. The x32 ABI is generally enabled by adding -mx32 to the compiler flags.
Caveats:
CMake 3.9.0 or later is required in order for the build system to automatically detect an x32 build.
Java does not support the x32 ABI, and thus the TurboJPEG Java API will automatically be disabled with x32 builds.
Added Loongson MMI SIMD implementations of the RGB-to-grayscale, 4:2:2 fancy chroma upsampling, 4:2:2 and 4:2:0 merged chroma upsampling/color conversion, and fast integer DCT/IDCT algorithms. Relative to libjpeg-turbo 2.0.x, this speeds up:
the compression of RGB source images into grayscale JPEG images by approximately 20%
the decompression of 4:2:2 JPEG images by approximately 40-60% when using fancy upsampling
the decompression of 4:2:2 and 4:2:0 JPEG images by approximately 15-20% when using merged upsampling
the compression of RGB source images by approximately 30-45% when using the fast integer DCT
the decompression of JPEG images into RGB destination images by approximately 2x when using the fast integer IDCT
The overall decompression speedup for RGB images is now approximately 2.3-3.7x (compared to 2-3.5x with libjpeg-turbo 2.0.x.)
32-bit (Armv7 or Armv7s) iOS builds of libjpeg-turbo are no longer supported, and the libjpeg-turbo build system can no longer be used to package such builds. 32-bit iOS apps cannot run in iOS 11 and later, and the App Store no longer allows them.
32-bit (i386) OS X/macOS builds of libjpeg-turbo are no longer supported, and the libjpeg-turbo build system can no longer be used to package such builds. 32-bit Mac applications cannot run in macOS 10.15 "Catalina" and later, and the App Store no longer allows them.
The SSE2 (x86 SIMD) and C Huffman encoding algorithms have been significantly optimized, resulting in a measured average overall compression speedup of 12-28% for 64-bit code and 22-52% for 32-bit code on various Intel and AMD CPUs, as well as a measured average overall compression speedup of 0-23% on platforms that do not have a SIMD-accelerated Huffman encoding implementation.
The block smoothing algorithm that is applied by default when decompressing progressive Huffman-encoded JPEG images has been improved in the following ways:
The algorithm is now more fault-tolerant. Previously, if a particular scan was incomplete, then the smoothing parameters for the incomplete scan would be applied to the entire output image, including the parts of the image that were generated by the prior (complete) scan. Visually, this had the effect of removing block smoothing from lower-frequency scans if they were followed by an incomplete higher-frequency scan. libjpeg-turbo now applies block smoothing parameters to each iMCU row based on which scan generated the pixels in that row, rather than always using the block smoothing parameters for the most recent scan.
When applying block smoothing to DC scans, a Gaussian-like kernel with a 5x5 window is used to reduce the "blocky" appearance.
Added SIMD acceleration for progressive Huffman encoding on Arm platforms. This speeds up the compression of full-color progressive JPEGs by about 30-40% on average (relative to libjpeg-turbo 2.0.x) when using modern Arm CPUs.
Added configure-time and run-time auto-detection of Loongson MMI SIMD instructions, so that the Loongson MMI SIMD extensions can be included in any MIPS64 libjpeg-turbo build.
Added fault tolerance features to djpeg and jpegtran, mainly to demonstrate methods by which applications can guard against the exploits of the JPEG format described in the report "Two Issues with the JPEG Standard".
Both programs now accept a -maxscans argument, which can be used to limit the number of allowable scans in the input file.
Both programs now accept a -strict argument, which can be used to treat all warnings as fatal.
CMake package config files are now included for both the libjpeg and TurboJPEG API libraries. This facilitates using libjpeg-turbo with CMake's find_package() function. For example:
find_package(libjpeg-turbo CONFIG REQUIRED)
add_executable(libjpeg_program libjpeg_program.c)
target_link_libraries(libjpeg_program PUBLIC libjpeg-turbo::jpeg)
add_executable(libjpeg_program_static libjpeg_program.c)
target_link_libraries(libjpeg_program_static PUBLIC
libjpeg-turbo::jpeg-static)
add_executable(turbojpeg_program turbojpeg_program.c)
target_link_libraries(turbojpeg_program PUBLIC
libjpeg-turbo::turbojpeg)
add_executable(turbojpeg_program_static turbojpeg_program.c)
target_link_libraries(turbojpeg_program_static PUBLIC
libjpeg-turbo::turbojpeg-static)
Since the Unisys LZW patent has long expired, cjpeg and djpeg can now read/write both LZW-compressed and uncompressed GIF files (feature ported from jpeg-6a and jpeg-9d.)
jpegtran now includes the -wipe and -drop options from jpeg-9a and jpeg-9d, as well as the ability to expand the image size using the -crop option. Refer to jpegtran.1 or usage.txt for more details.
Added a complete intrinsics implementation of the Arm Neon SIMD extensions, thus providing SIMD acceleration on Arm platforms for all of the algorithms that are SIMD-accelerated on x86 platforms. This new implementation is significantly faster in some cases than the old GAS implementation-- depending on the algorithms used, the type of CPU core, and the compiler. GCC, as of this writing, does not provide a full or optimal set of Neon intrinsics, so for performance reasons, the default when building libjpeg-turbo with GCC is to continue using the GAS implementation of the following algorithms:
32-bit RGB-to-YCbCr color conversion
32-bit fast and accurate inverse DCT
64-bit RGB-to-YCbCr and YCbCr-to-RGB color conversion
64-bit accurate forward and inverse DCT
64-bit Huffman encoding
A new CMake variable (NEON_INTRINSICS) can be used to override this default.
Since the new intrinsics implementation includes SIMD acceleration for merged upsampling/color conversion, 1.5.1[5] is no longer necessary and has been reverted.
The Arm Neon SIMD extensions can now be built using Visual Studio.
The build system can now be used to generate a universal x86-64 + Armv8 libjpeg-turbo SDK package for both iOS and macOS.
2.0.6
Significant changes relative to 2.0.5:
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.)
2.0.5
Significant changes relative to 2.0.4:
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.
2.0.4
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.
2.0.3
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.
2.0.2
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.
2.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.
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."
2.0.0
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.
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.
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.)
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.
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.)
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.)
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.
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.
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.
pkglint -r --network --only "migrate"
As a side-effect of migrating the homepages, pkglint also fixed a few
indentations in unrelated lines. These and the new homepages have been
checked manually.
1.5.0
=====
### 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. 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.
1.4.90 (1.5 beta1)
==================
### 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](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 slow 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.
1.4.2
=====
### 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.
Problems found with existing digests:
Package fotoxx distfile fotoxx-14.03.1.tar.gz
ac2033f87de2c23941261f7c50160cddf872c110 [recorded]
118e98a8cc0414676b3c4d37b8df407c28a1407c [calculated]
Package ploticus-examples distfile ploticus-2.00/plnode200.tar.gz
34274a03d0c41fae5690633663e3d4114b9d7a6d [recorded]
da39a3ee5e6b4b0d3255bfef95601890afd80709 [calculated]
Problems found locating distfiles:
Package AfterShotPro: missing distfile AfterShotPro-1.1.0.30/AfterShotPro_i386.deb
Package pgraf: missing distfile pgraf-20010131.tar.gz
Package qvplay: missing distfile qvplay-0.95.tar.gz
Otherwise, existing SHA1 digests verified and found to be the same on
the machine holding the existing distfiles (morden). All existing
SHA1 digests retained for now as an audit trail.
Changes:
1.4.0
=====
[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.
[3] Fixed an issue in tjBufSizeYUV2() wherby 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.
1.3.90 (1.4 beta1)
==================
[1] New features in the TurboJPEG API:
-- YUV planar images can now be generated with an arbitrary line padding
(previously only 4-byte padding, which was compatible with X Video, was
supported.)
-- The decompress-to-YUV function has been extended to support image scaling.
-- JPEG images can now be compressed from YUV planar source images.
-- YUV planar images can now be decoded into RGB or grayscale images.
-- 4:1:1 subsampling is now supported. This is mainly included for
compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no
significant advantages relative to 4:2:0.
-- CMYK images are now supported. This feature allows CMYK source images to be
compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to CMYK
destination images. Conversion between CMYK/YCCK and RGB or YUV images is not
supported. Such conversion requires a color management system and is thus out
of scope for a codec library.
-- The handling of YUV images in the Java API has been significantly refactored
and should now be much more intuitive.
-- The Java API now supports encoding a YUV image from an arbitrary position in
a large image buffer.
-- All of the YUV functions now have a corresponding function that operates on
separate image planes instead of a unified image buffer. This allows for
compressing/decoding from or decompressing/encoding to a subregion of a larger
YUV image. It also allows for handling YUV formats that swap the order of the
U and V planes.
[2] Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up
the compression of full-color JPEGs by 70-80% on such platforms and
decompression by 25-35%.
[3] If an application attempts to decompress a Huffman-coded JPEG image whose
header does not contain Huffman tables, libjpeg-turbo will now insert the
default Huffman tables. In order to save space, many motion JPEG video frames
are encoded without the default Huffman tables, so these frames can now be
successfully decompressed by libjpeg-turbo without additional work on the part
of the application. An application can still override the Huffman tables, for
instance to re-use tables from a previous frame of the same video.
[5] The Huffman encoder now uses clz and bsr instructions for bit counting on
ARM platforms rather than a lookup table. This reduces the memory footprint
by 64k, which may be important for some mobile applications. Out of four
Android devices that were tested, two demonstrated a small overall performance
loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with
ARMv7 code when enabling this new feature, but the other two devices
demonstrated a significant overall performance gain with both ARMv6 and ARMv7
code (~10-20%) when enabling the feature. Actual mileage may vary.
[7] Improved the accuracy and performance of the non-SIMD implementation of the
floating point inverse DCT (using code borrowed from libjpeg v8a and later.)
The accuracy of this implementation now matches the accuracy of the SSE/SSE2
implementation. Note, however, that the floating point DCT/IDCT algorithms are
mainly a legacy feature. They generally do not produce significantly better
accuracy than the slow integer DCT/IDCT algorithms, and they are quite a bit
slower.
[8] Added a new output colorspace (JCS_RGB565) to the libjpeg API that allows
for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not
used, then this code path is SIMD-accelerated on ARM platforms.
[13] Restored 12-bit-per-component JPEG support. A 12-bit version of
libjpeg-turbo can now be built by passing an argument of --with-12bit to
configure (Unix) or -DWITH_12BIT=1 to cmake (Windows.) 12-bit JPEG support is
included only for convenience. Enabling this feature disables all of the
performance features in libjpeg-turbo, as well as arithmetic coding and the
TurboJPEG API. The resulting library still contains the other libjpeg-turbo
features (such as the colorspace extensions), but in general, it performs no
faster than libjpeg v6b.
[14] Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion
and IDCT algorithms (both are used during JPEG decompression.) For unknown
reasons (probably related to clang), this code cannot currently be compiled for
iOS.
[15] Fixed an extremely rare bug that could cause the Huffman encoder's local
buffer to overrun when a very high-frequency MCU is compressed using quality
100 and no subsampling, and when the JPEG output buffer is being dynamically
resized by the destination manager. This issue was so rare that, even with a
test program specifically designed to make the bug occur (by injecting random
high-frequency YUV data into the compressor), it was reproducible only once in
about every 25 million iterations.
[16] Fixed an oversight in the TurboJPEG C wrapper: if any of the JPEG
compression functions was called repeatedly with the same
automatically-allocated destination buffer, then TurboJPEG would erroneously
assume that the jpegSize parameter was equal to the size of the buffer, when in
fact that parameter was probably equal to the size of the most recently
compressed JPEG image. If the size of the previous JPEG image was not as large
as the current JPEG image, then TurboJPEG would unnecessarily reallocate the
destination buffer.
1.3.1
=====
[3] 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".
[4] Fixed a couple of issues whereby malformed JPEG images would cause
libjpeg-turbo to use uninitialized memory during decompression.
[5] 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.
=====
[1] 'make test' now works properly on FreeBSD, and it no longer requires the
md5sum executable to be present on other Un*x platforms.
[2] 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".
-- The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the
official Linux and Mac packages, to avoid conflict with vendor-supplied
packages and also to streamline the packaging system.
-- 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.
[3] Fixed a Huffman encoder bug that prevented I/O suspension from working
properly.
COMMENT should not be longer than 70 characters.
COMMENT should not begin with 'A'.
COMMENT should not begin with 'An'.
COMMENT should not begin with 'a'.
COMMENT should not end with a period.
COMMENT should start with a capital letter.
pkglint warnings. Some files also got minor formatting, spelling, and style
corrections.
it should provide the jpeg-8 API/ABI rather than the -6b one.
So switch to 1.1.0 with the jpeg8 "configure" option.
Tested to be binary compatible on i386, at least for simple
image viewers.
being here, add "test" target
instructions to accelerate baseline JPEG compression/decompression by about
2-4x on x86 and x86-64 platforms.
XXX Conflicts with graphics/jpeg - which rather demands a solution.
