diff options
Diffstat (limited to 'src/3rdparty/libjpeg/src/ChangeLog.md')
-rw-r--r-- | src/3rdparty/libjpeg/src/ChangeLog.md | 286 |
1 files changed, 281 insertions, 5 deletions
diff --git a/src/3rdparty/libjpeg/src/ChangeLog.md b/src/3rdparty/libjpeg/src/ChangeLog.md index a547522a15..a929b62a8c 100644 --- a/src/3rdparty/libjpeg/src/ChangeLog.md +++ b/src/3rdparty/libjpeg/src/ChangeLog.md @@ -1,3 +1,279 @@ +3.0.2 +===== + +### Significant changes relative to 3.0.1: + +1. Fixed a signed integer overflow in the `tj3CompressFromYUV8()`, +`tj3DecodeYUV8()`, `tj3DecompressToYUV8()`, and `tj3EncodeYUV8()` functions, +detected by the Clang and GCC undefined behavior sanitizers, that could be +triggered by setting the `align` parameter to an unreasonably large value. +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. + +2. Introduced a new parameter (`TJPARAM_MAXMEMORY` in the TurboJPEG C API and +`TJ.PARAM_MAXMEMORY` in the TurboJPEG Java API) and a corresponding TJBench +option (`-maxmemory`) for specifying the maximum amount of memory (in +megabytes) that will be allocated for intermediate buffers, which are used with +progressive JPEG compression and decompression, optimized baseline entropy +coding, lossless JPEG compression, and lossless transformation. The new +parameter and option serve the same purpose as the `max_memory_to_use` field in +the `jpeg_memory_mgr` struct in the libjpeg API, the `JPEGMEM` environment +variable, and the cjpeg/djpeg/jpegtran `-maxmemory` option. + +3. Introduced a new parameter (`TJPARAM_MAXPIXELS` in the TurboJPEG C API and +`TJ.PARAM_MAXPIXELS` in the TurboJPEG Java API) and a corresponding TJBench +option (`-maxpixels`) for specifying the maximum number of pixels that the +decompression, lossless transformation, and packed-pixel image loading +functions/methods will process. + +4. Fixed an error ("Unsupported color conversion request") that occurred when +attempting to decompress a 3-component lossless JPEG image without an Adobe +APP14 marker. The decompressor now assumes that a 3-component lossless JPEG +image without an Adobe APP14 marker uses the RGB colorspace if its component +IDs are 1, 2, and 3. + + +3.0.1 +===== + +### Significant changes relative to 3.0.0: + +1. The x86-64 SIMD functions now use a standard stack frame, prologue, and +epilogue so that debuggers and profilers can reliably capture backtraces from +within the functions. + +2. Fixed two minor issues in the interblock smoothing algorithm that caused +mathematical (but not necessarily perceptible) edge block errors when +decompressing progressive JPEG images exactly two MCU blocks in width or that +use vertical chrominance subsampling. + +3. Fixed a regression introduced by 3.0 beta2[6] that, in rare cases, caused +the C Huffman encoder (which is not used by default on x86 and Arm CPUs) to +generate incorrect results if the Neon SIMD extensions were explicitly disabled +at build time (by setting the `WITH_SIMD` CMake variable to `0`) in an AArch64 +build of libjpeg-turbo. + + +3.0.0 +===== + +### Significant changes relative to 3.0 beta2: + +1. The TurboJPEG API now supports 4:4:1 (transposed 4:1:1) chrominance +subsampling, which allows losslessly transposed or rotated 4:1:1 JPEG images to +be losslessly cropped, partially decompressed, or decompressed to planar YUV +images. + +2. Fixed various segfaults and buffer overruns (CVE-2023-2804) that occurred +when attempting to decompress various specially-crafted malformed +12-bit-per-component and 16-bit-per-component lossless JPEG images using color +quantization or merged chroma upsampling/color conversion. The underlying +cause of these issues was that the color quantization and merged chroma +upsampling/color conversion algorithms were not designed with lossless +decompression in mind. Since libjpeg-turbo explicitly does not support color +conversion when compressing or decompressing lossless JPEG images, merged +chroma upsampling/color conversion never should have been enabled for such +images. Color quantization is a legacy feature that serves little or no +purpose with lossless JPEG images, so it is also now disabled when +decompressing such images. (As a result, djpeg can no longer decompress a +lossless JPEG image into a GIF image.) + +3. Fixed an oversight in 1.4 beta1[8] that caused various segfaults and buffer +overruns when attempting to decompress various specially-crafted malformed +12-bit-per-component JPEG images using djpeg with both color quantization and +RGB565 color conversion enabled. + +4. Fixed an issue whereby `jpeg_crop_scanline()` sometimes miscalculated the +downsampled width for components with 4x2 or 2x4 subsampling factors if +decompression scaling was enabled. This caused the components to be upsampled +incompletely, which caused the color converter to read from uninitialized +memory. With 12-bit data precision, this caused a buffer overrun or underrun +and subsequent segfault if the sample value read from uninitialized memory was +outside of the valid sample range. + +5. Fixed a long-standing issue whereby the `tj3Transform()` function, when used +with the `TJXOP_TRANSPOSE`, `TJXOP_TRANSVERSE`, `TJXOP_ROT90`, or +`TJXOP_ROT270` transform operation and without automatic JPEG destination +buffer (re)allocation or lossless cropping, computed the worst-case transformed +JPEG image size based on the source image dimensions rather than the +transformed image dimensions. If a calling program allocated the JPEG +destination buffer based on the transformed image dimensions, as the API +documentation instructs, and attempted to transform a specially-crafted 4:2:2, +4:4:0, 4:1:1, or 4:4:1 JPEG source image containing a large amount of metadata, +the issue caused `tj3Transform()` to overflow the JPEG destination buffer +rather than fail gracefully. The issue could be worked around by setting +`TJXOPT_COPYNONE`. Note that, irrespective of this issue, `tj3Transform()` +cannot reliably transform JPEG source images that contain a large amount of +metadata unless automatic JPEG destination buffer (re)allocation is used or +`TJXOPT_COPYNONE` is set. + +6. Fixed a regression introduced by 3.0 beta2[6] that prevented the djpeg +`-map` option from working when decompressing 12-bit-per-component lossy JPEG +images. + +7. Fixed an issue that caused the C Huffman encoder (which is not used by +default on x86 and Arm CPUs) to read from uninitialized memory when attempting +to transform a specially-crafted malformed arithmetic-coded JPEG source image +into a baseline Huffman-coded JPEG destination image. + + +2.1.91 (3.0 beta2) +================== + +### Significant changes relative to 2.1.5.1: + +1. Significantly sped up the computation of optimal Huffman tables. This +speeds up the compression of tiny images by as much as 2x and provides a +noticeable speedup for images as large as 256x256 when using optimal Huffman +tables. + +2. All deprecated fields, constructors, and methods in the TurboJPEG Java API +have been removed. + +3. Arithmetic entropy coding is now supported with 12-bit-per-component JPEG +images. + +4. Overhauled the TurboJPEG API to address long-standing limitations and to +make the API more extensible and intuitive: + + - All C function names are now prefixed with `tj3`, and all version +suffixes have been removed from the function names. Future API overhauls will +increment the prefix to `tj4`, etc., thus retaining backward API/ABI +compatibility without versioning each individual function. + - Stateless boolean flags have been replaced with stateful integer API +parameters, the values of which persist between function calls. New +functions/methods (`tj3Set()`/`TJCompressor.set()`/`TJDecompressor.set()` and +`tj3Get()`/`TJCompressor.get()`/`TJDecompressor.get()`) can be used to set and +query the value of a particular API parameter. + - The JPEG quality and subsampling are now implemented using API +parameters rather than stateless function arguments (C) or dedicated set/get +methods (Java.) + - `tj3DecompressHeader()` now stores all relevant information about the +JPEG image, including the width, height, subsampling type, entropy coding +algorithm, etc., in API parameters rather than returning that information +through pointer arguments. + - `TJFLAG_LIMITSCANS`/`TJ.FLAG_LIMITSCANS` has been reimplemented as an +API parameter (`TJPARAM_SCANLIMIT`/`TJ.PARAM_SCANLIMIT`) that allows the number +of scans to be specified. + - Optimized baseline entropy coding (the computation of optimal Huffman +tables, as opposed to using the default Huffman tables) can now be specified, +using a new API parameter (`TJPARAM_OPTIMIZE`/`TJ.PARAM_OPTIMIZE`), a new +transform option (`TJXOPT_OPTIMIZE`/`TJTransform.OPT_OPTIMIZE`), and a new +TJBench option (`-optimize`.) + - Arithmetic entropy coding can now be specified or queried, using a new +API parameter (`TJPARAM_ARITHMETIC`/`TJ.PARAM_ARITHMETIC`), a new transform +option (`TJXOPT_ARITHMETIC`/`TJTransform.OPT_ARITHMETIC`), and a new TJBench +option (`-arithmetic`.) + - The restart marker interval can now be specified, using new API +parameters (`TJPARAM_RESTARTROWS`/`TJ.PARAM_RESTARTROWS` and +`TJPARAM_RESTARTBLOCKS`/`TJ.PARAM_RESTARTBLOCKS`) and a new TJBench option +(`-restart`.) + - Pixel density can now be specified or queried, using new API parameters +(`TJPARAM_XDENSITY`/`TJ.PARAM_XDENSITY`, +`TJPARAM_YDENSITY`/`TJ.PARAM_YDENSITY`, and +`TJPARAM_DENSITYUNITS`/`TJ.PARAM_DENSITYUNITS`.) + - The accurate DCT/IDCT algorithms are now the default for both +compression and decompression, since the "fast" algorithms are considered to be +a legacy feature. (The "fast" algorithms do not pass the ISO compliance tests, +and those algorithms are not any faster than the accurate algorithms on modern +x86 CPUs.) + - All C initialization functions have been combined into a single function +(`tj3Init()`) that accepts an integer argument specifying the subsystems to +initialize. + - All C functions now use the `const` keyword for pointer arguments that +point to unmodified buffers (and for both dimensions of pointer arguments that +point to sets of unmodified buffers.) + - All C functions now use `size_t` rather than `unsigned long` to +represent buffer sizes, for compatibility with `malloc()` and to avoid +disparities in the size of `unsigned long` between LP64 (Un*x) and LLP64 +(Windows) operating systems. + - All C buffer size functions now return 0 if an error occurs, rather than +trying to awkwardly return -1 in an unsigned data type (which could easily be +misinterpreted as a very large value.) + - Decompression scaling is now enabled explicitly, using a new +function/method (`tj3SetScalingFactor()`/`TJDecompressor.setScalingFactor()`), +rather than implicitly using awkward "desired width"/"desired height" +arguments. + - Partial image decompression has been implemented, using a new +function/method (`tj3SetCroppingRegion()`/`TJDecompressor.setCroppingRegion()`) +and a new TJBench option (`-crop`.) + - The JPEG colorspace can now be specified explicitly when compressing, +using a new API parameter (`TJPARAM_COLORSPACE`/`TJ.PARAM_COLORSPACE`.) This +allows JPEG images with the RGB and CMYK colorspaces to be created. + - TJBench no longer generates error/difference images, since identical +functionality is already available in ImageMagick. + - JPEG images with unknown subsampling configurations can now be +fully decompressed into packed-pixel images or losslessly transformed (with the +exception of lossless cropping.) They cannot currently be partially +decompressed or decompressed into planar YUV images. + - `tj3Destroy()` now silently accepts a NULL handle. + - `tj3Alloc()` and `tj3Free()` now return/accept void pointers, as +`malloc()` and `free()` do. + - The C image I/O functions now accept a TurboJPEG instance handle, which +is used to transmit/receive API parameter values and to receive error +information. + +5. Added support for 8-bit-per-component, 12-bit-per-component, and +16-bit-per-component lossless JPEG images. A new libjpeg API function +(`jpeg_enable_lossless()`), TurboJPEG API parameters +(`TJPARAM_LOSSLESS`/`TJ.PARAM_LOSSLESS`, +`TJPARAM_LOSSLESSPSV`/`TJ.PARAM_LOSSLESSPSV`, and +`TJPARAM_LOSSLESSPT`/`TJ.PARAM_LOSSLESSPT`), and a cjpeg/TJBench option +(`-lossless`) can be used to create a lossless JPEG image. (Decompression of +lossless JPEG images is handled automatically.) Refer to +[libjpeg.txt](libjpeg.txt), [usage.txt](usage.txt), and the TurboJPEG API +documentation for more details. + +6. Added support for 12-bit-per-component (lossy and lossless) and +16-bit-per-component (lossless) JPEG images to the libjpeg and TurboJPEG APIs: + + - The existing `data_precision` field in `jpeg_compress_struct` and +`jpeg_decompress_struct` has been repurposed to enable the creation of +12-bit-per-component and 16-bit-per-component JPEG images or to detect whether +a 12-bit-per-component or 16-bit-per-component JPEG image is being +decompressed. + - New 12-bit-per-component and 16-bit-per-component versions of +`jpeg_write_scanlines()` and `jpeg_read_scanlines()`, as well as new +12-bit-per-component versions of `jpeg_write_raw_data()`, +`jpeg_skip_scanlines()`, `jpeg_crop_scanline()`, and `jpeg_read_raw_data()`, +provide interfaces for compressing from/decompressing to 12-bit-per-component +and 16-bit-per-component packed-pixel and planar YUV image buffers. + - New 12-bit-per-component and 16-bit-per-component compression, +decompression, and image I/O functions/methods have been added to the TurboJPEG +API, and a new API parameter (`TJPARAM_PRECISION`/`TJ.PARAM_PRECISION`) can be +used to query the data precision of a JPEG image. (YUV functions are currently +limited to 8-bit data precision but can be expanded to accommodate 12-bit data +precision in the future, if such is deemed beneficial.) + - A new cjpeg and TJBench command-line argument (`-precision`) can be used +to create a 12-bit-per-component or 16-bit-per-component JPEG image. +(Decompression and transformation of 12-bit-per-component and +16-bit-per-component JPEG images is handled automatically.) + + Refer to [libjpeg.txt](libjpeg.txt), [usage.txt](usage.txt), and the +TurboJPEG API documentation for more details. + + +2.1.5.1 +======= + +### Significant changes relative to 2.1.5: + +1. The SIMD dispatchers in libjpeg-turbo 2.1.4 and prior stored the list of +supported SIMD instruction sets in a global variable, which caused an innocuous +race condition whereby the variable could have been initialized multiple times +if `jpeg_start_*compress()` was called simultaneously in multiple threads. +libjpeg-turbo 2.1.5 included an undocumented attempt to fix this race condition +by making the SIMD support variable thread-local. However, that caused another +issue whereby, if `jpeg_start_*compress()` was called in one thread and +`jpeg_read_*()` or `jpeg_write_*()` was called in a second thread, the SIMD +support variable was never initialized in the second thread. On x86 systems, +this led the second thread to incorrectly assume that AVX2 instructions were +always available, and when it attempted to use those instructions on older x86 +CPUs that do not support them, an illegal instruction error occurred. The SIMD +dispatchers now ensure that the SIMD support variable is initialized before +dispatching based on its value. + + 2.1.5 ===== @@ -178,9 +454,9 @@ transform a specially-crafted malformed JPEG image. ### Significant changes relative to 2.1 beta1: -1. 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. +1. Fixed a regression (CVE-2021-29390) 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. 2. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to decompress a specially-crafted malformed progressive JPEG image caused the @@ -1419,7 +1695,7 @@ 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 +and IDCT algorithms (both are used during JPEG decompression.) For reasons (probably related to clang), this code cannot currently be compiled for iOS. @@ -1905,7 +2181,7 @@ and unit tests now work on those architectures. 0.0.93 ====== -### Significant changes since 0.0.91: +### Significant changes relative to 0.0.91: 1. 2982659: Fixed x86-64 build on FreeBSD systems |