Opened 3 years ago

Closed 3 years ago

#10576 closed enhancement (fixed)

libjpeg-turbo-2.0.0

Reported by: Bruce Dubbs Owned by: Bruce Dubbs
Priority: normal Milestone: 8.3
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

Need to check if this is just a development release.

Change History (8)

comment:1 by Bruce Dubbs, 3 years ago

Owner: changed from blfs-book to Bruce Dubbs
Status: newassigned

comment:2 by Bruce Dubbs, 3 years ago

Note -- Changing to cmake with removal of autotools. I expect the next stable version to be either 1.6 or 2.0.

It is beta1. Will defer until a stable release. Release notes so far:

  1. Added AVX2 SIMD implementations of the colorspace conversion, chroma

downsampling and upsampling, integer quantization and sample conversion, and slow integer DCT/IDCT algorithms. When using the slow 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.)

  1. 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.

  1. 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.

  1. 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.)

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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 slow integer DCT/IDCT algorithms. When using the slow 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.

  1. Fixed a build error when building with older MinGW releases (regression

caused by 1.5.1[7].)

  1. 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.

comment:3 by Bruce Dubbs, 3 years ago

Summary: libjpeg-turbo-1.5.90libjpeg-turbo-1.5.90 (wait for 1.6.0)

comment:4 by Bruce Dubbs, 3 years ago

Milestone: 8.3y-hold

comment:5 by Bruce Dubbs, 3 years ago

Milestone: y-holdhold

Milestone renamed

comment:6 by Bruce Dubbs, 3 years ago

Milestone: hold8.3
Summary: libjpeg-turbo-1.5.90 (wait for 1.6.0)libjpeg-turbo-2.0.0

Now at version 2.0.0. Changing milestone to 8.3.

comment:7 by Bruce Dubbs, 3 years ago

### 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.

  1. 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.

  1. 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.)

  1. Fixed an issue 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.

  1. 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.)

  1. 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.)

  1. 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.

  1. Fixed out-of-bounds read in cjpeg 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.

  1. 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.

comment:8 by Bruce Dubbs, 3 years ago

Resolution: fixed
Status: assignedclosed

Fixed at revision 20329.

Note: See TracTickets for help on using tickets.