12.1.0 2===== 3 4### Significant changes relative to 2.1 beta1 5 61. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to 7decompress certain progressive JPEG images with one or more component planes of 8width 8 or less caused a buffer overrun. 9 102. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to 11decompress a specially-crafted malformed progressive JPEG image caused the 12block smoothing algorithm to read from uninitialized memory. 13 143. Fixed an issue in the Arm Neon SIMD Huffman encoders that caused the 15encoders to generate incorrect results when using the Clang compiler with 16Visual Studio. 17 184. Fixed a floating point exception (CVE-2021-20205) that occurred when 19attempting to compress a specially-crafted malformed GIF image with a specified 20image width of 0 using cjpeg. 21 225. Fixed a regression introduced by 2.0 beta1[15] whereby attempting to 23generate a progressive JPEG image on an SSE2-capable CPU using a scan script 24containing one or more scans with lengths divisible by 32 and non-zero 25successive approximation low bit positions would, under certain circumstances, 26result in an error ("Missing Huffman code table entry") and an invalid JPEG 27image. 28 296. Introduced a new flag (`TJFLAG_LIMITSCANS` in the TurboJPEG C API and 30`TJ.FLAG_LIMIT_SCANS` in the TurboJPEG Java API) and a corresponding TJBench 31command-line argument (`-limitscans`) that causes the TurboJPEG decompression 32and transform functions/operations to return/throw an error if a progressive 33JPEG image contains an unreasonably large number of scans. This allows 34applications that use the TurboJPEG API to guard against an exploit of the 35progressive JPEG format described in the report 36["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf). 37 387. The PPM reader now throws an error, rather than segfaulting (due to a buffer 39overrun) or generating incorrect pixels, if an application attempts to use the 40`tjLoadImage()` function to load a 16-bit binary PPM file (a binary PPM file 41with a maximum value greater than 255) into a grayscale image buffer or to load 42a 16-bit binary PGM file into an RGB image buffer. 43 448. Fixed an issue in the PPM reader that caused incorrect pixels to be 45generated when using the `tjLoadImage()` function to load a 16-bit binary PPM 46file into an extended RGB image buffer. 47 489. Fixed an issue whereby, if a JPEG buffer was automatically re-allocated by 49one of the TurboJPEG compression or transform functions and an error 50subsequently occurred during compression or transformation, the JPEG buffer 51pointer passed by the application was not updated when the function returned. 52 53 542.0.90 (2.1 beta1) 55================== 56 57### Significant changes relative to 2.0.6: 58 591. The build system, x86-64 SIMD extensions, and accelerated Huffman codec now 60support the x32 ABI on Linux, which allows for using x86-64 instructions with 6132-bit pointers. The x32 ABI is generally enabled by adding `-mx32` to the 62compiler flags. 63 64 Caveats: 65 - CMake 3.9.0 or later is required in order for the build system to 66automatically detect an x32 build. 67 - Java does not support the x32 ABI, and thus the TurboJPEG Java API will 68automatically be disabled with x32 builds. 69 702. Added Loongson MMI SIMD implementations of the RGB-to-grayscale, 4:2:2 fancy 71chroma upsampling, 4:2:2 and 4:2:0 merged chroma upsampling/color conversion, 72and fast integer DCT/IDCT algorithms. Relative to libjpeg-turbo 2.0.x, this 73speeds up: 74 75 - the compression of RGB source images into grayscale JPEG images by 76approximately 20% 77 - the decompression of 4:2:2 JPEG images by approximately 40-60% when 78using fancy upsampling 79 - the decompression of 4:2:2 and 4:2:0 JPEG images by approximately 8015-20% when using merged upsampling 81 - the compression of RGB source images by approximately 30-45% when using 82the fast integer DCT 83 - the decompression of JPEG images into RGB destination images by 84approximately 2x when using the fast integer IDCT 85 86 The overall decompression speedup for RGB images is now approximately 872.3-3.7x (compared to 2-3.5x with libjpeg-turbo 2.0.x.) 88 893. 32-bit (Armv7 or Armv7s) iOS builds of libjpeg-turbo are no longer 90supported, and the libjpeg-turbo build system can no longer be used to package 91such builds. 32-bit iOS apps cannot run in iOS 11 and later, and the App Store 92no longer allows them. 93 944. 32-bit (i386) OS X/macOS builds of libjpeg-turbo are no longer supported, 95and the libjpeg-turbo build system can no longer be used to package such 96builds. 32-bit Mac applications cannot run in macOS 10.15 "Catalina" and 97later, and the App Store no longer allows them. 98 995. The SSE2 (x86 SIMD) and C Huffman encoding algorithms have been 100significantly optimized, resulting in a measured average overall compression 101speedup of 12-28% for 64-bit code and 22-52% for 32-bit code on various Intel 102and AMD CPUs, as well as a measured average overall compression speedup of 1030-23% on platforms that do not have a SIMD-accelerated Huffman encoding 104implementation. 105 1066. The block smoothing algorithm that is applied by default when decompressing 107progressive Huffman-encoded JPEG images has been improved in the following 108ways: 109 110 - The algorithm is now more fault-tolerant. Previously, if a particular 111scan was incomplete, then the smoothing parameters for the incomplete scan 112would be applied to the entire output image, including the parts of the image 113that were generated by the prior (complete) scan. Visually, this had the 114effect of removing block smoothing from lower-frequency scans if they were 115followed by an incomplete higher-frequency scan. libjpeg-turbo now applies 116block smoothing parameters to each iMCU row based on which scan generated the 117pixels in that row, rather than always using the block smoothing parameters for 118the most recent scan. 119 - When applying block smoothing to DC scans, a Gaussian-like kernel with a 1205x5 window is used to reduce the "blocky" appearance. 121 1227. Added SIMD acceleration for progressive Huffman encoding on Arm platforms. 123This speeds up the compression of full-color progressive JPEGs by about 30-40% 124on average (relative to libjpeg-turbo 2.0.x) when using modern Arm CPUs. 125 1268. Added configure-time and run-time auto-detection of Loongson MMI SIMD 127instructions, so that the Loongson MMI SIMD extensions can be included in any 128MIPS64 libjpeg-turbo build. 129 1309. Added fault tolerance features to djpeg and jpegtran, mainly to demonstrate 131methods by which applications can guard against the exploits of the JPEG format 132described in the report 133["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf). 134 135 - Both programs now accept a `-maxscans` argument, which can be used to 136limit the number of allowable scans in the input file. 137 - Both programs now accept a `-strict` argument, which can be used to 138treat all warnings as fatal. 139 14010. CMake package config files are now included for both the libjpeg and 141TurboJPEG API libraries. This facilitates using libjpeg-turbo with CMake's 142`find_package()` function. For example: 143 144 find_package(libjpeg-turbo CONFIG REQUIRED) 145 146 add_executable(libjpeg_program libjpeg_program.c) 147 target_link_libraries(libjpeg_program PUBLIC libjpeg-turbo::jpeg) 148 149 add_executable(libjpeg_program_static libjpeg_program.c) 150 target_link_libraries(libjpeg_program_static PUBLIC 151 libjpeg-turbo::jpeg-static) 152 153 add_executable(turbojpeg_program turbojpeg_program.c) 154 target_link_libraries(turbojpeg_program PUBLIC 155 libjpeg-turbo::turbojpeg) 156 157 add_executable(turbojpeg_program_static turbojpeg_program.c) 158 target_link_libraries(turbojpeg_program_static PUBLIC 159 libjpeg-turbo::turbojpeg-static) 160 16111. Since the Unisys LZW patent has long expired, cjpeg and djpeg can now 162read/write both LZW-compressed and uncompressed GIF files (feature ported from 163jpeg-6a and jpeg-9d.) 164 16512. jpegtran now includes the `-wipe` and `-drop` options from jpeg-9a and 166jpeg-9d, as well as the ability to expand the image size using the `-crop` 167option. Refer to jpegtran.1 or usage.txt for more details. 168 16913. Added a complete intrinsics implementation of the Arm Neon SIMD extensions, 170thus providing SIMD acceleration on Arm platforms for all of the algorithms 171that are SIMD-accelerated on x86 platforms. This new implementation is 172significantly faster in some cases than the old GAS implementation-- 173depending on the algorithms used, the type of CPU core, and the compiler. GCC, 174as of this writing, does not provide a full or optimal set of Neon intrinsics, 175so for performance reasons, the default when building libjpeg-turbo with GCC is 176to continue using the GAS implementation of the following algorithms: 177 178 - 32-bit RGB-to-YCbCr color conversion 179 - 32-bit fast and accurate inverse DCT 180 - 64-bit RGB-to-YCbCr and YCbCr-to-RGB color conversion 181 - 64-bit accurate forward and inverse DCT 182 - 64-bit Huffman encoding 183 184 A new CMake variable (`NEON_INTRINSICS`) can be used to override this 185default. 186 187 Since the new intrinsics implementation includes SIMD acceleration 188for merged upsampling/color conversion, 1.5.1[5] is no longer necessary and has 189been reverted. 190 19114. The Arm Neon SIMD extensions can now be built using Visual Studio. 192 19315. The build system can now be used to generate a universal x86-64 + Armv8 194libjpeg-turbo SDK package for both iOS and macOS. 195 196 1972.0.6 198===== 199 200### Significant changes relative to 2.0.5: 201 2021. Fixed "using JNI after critical get" errors that occurred on Android 203platforms when using any of the YUV encoding/compression/decompression/decoding 204methods in the TurboJPEG Java API. 205 2062. Fixed or worked around multiple issues with `jpeg_skip_scanlines()`: 207 208 - Fixed segfaults or "Corrupt JPEG data: premature end of data segment" 209errors in `jpeg_skip_scanlines()` that occurred when decompressing 4:2:2 or 2104:2:0 JPEG images using merged (non-fancy) upsampling/color conversion (that 211is, when setting `cinfo.do_fancy_upsampling` to `FALSE`.) 2.0.0[6] was a 212similar fix, but it did not cover all cases. 213 - `jpeg_skip_scanlines()` now throws an error if two-pass color 214quantization is enabled. Two-pass color quantization never worked properly 215with `jpeg_skip_scanlines()`, and the issues could not readily be fixed. 216 - Fixed an issue whereby `jpeg_skip_scanlines()` always returned 0 when 217skipping past the end of an image. 218 2193. The Arm 64-bit (Armv8) Neon SIMD extensions can now be built using MinGW 220toolchains targetting Arm64 (AArch64) Windows binaries. 221 2224. Fixed unexpected visual artifacts that occurred when using 223`jpeg_crop_scanline()` and interblock smoothing while decompressing only the DC 224scan of a progressive JPEG image. 225 2265. Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-component 227JPEG support (`WITH_12BIT`) was enabled along with libjpeg v7 or libjpeg v8 228API/ABI emulation (`WITH_JPEG7` or `WITH_JPEG8`.) 229 230 2312.0.5 232===== 233 234### Significant changes relative to 2.0.4: 235 2361. Worked around issues in the MIPS DSPr2 SIMD extensions that caused failures 237in the libjpeg-turbo regression tests. Specifically, the 238`jsimd_h2v1_downsample_dspr2()` and `jsimd_h2v2_downsample_dspr2()` functions 239in the MIPS DSPr2 SIMD extensions are now disabled until/unless they can be 240fixed, and other functions that are incompatible with big endian MIPS CPUs are 241disabled when building libjpeg-turbo for such CPUs. 242 2432. Fixed an oversight in the `TJCompressor.compress(int)` method in the 244TurboJPEG Java API that caused an error ("java.lang.IllegalStateException: No 245source image is associated with this instance") when attempting to use that 246method to compress a YUV image. 247 2483. Fixed an issue (CVE-2020-13790) in the PPM reader that caused a buffer 249overrun in cjpeg, TJBench, or the `tjLoadImage()` function if one of the values 250in a binary PPM/PGM input file exceeded the maximum value defined in the file's 251header and that maximum value was less than 255. libjpeg-turbo 1.5.0 already 252included a similar fix for binary PPM/PGM files with maximum values greater 253than 255. 254 2554. The TurboJPEG API library's global error handler, which is used in functions 256such as `tjBufSize()` and `tjLoadImage()` that do not require a TurboJPEG 257instance handle, is now thread-safe on platforms that support thread-local 258storage. 259 260 2612.0.4 262===== 263 264### Significant changes relative to 2.0.3: 265 2661. Fixed a regression in the Windows packaging system (introduced by 2672.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo SDK for GCC and the 26864-bit libjpeg-turbo SDK for Visual C++ were installed on the same system, only 269one of them could be uninstalled. 270 2712. Fixed a signed integer overflow and subsequent segfault that occurred when 272attempting to decompress images with more than 715827882 pixels using the 27364-bit C version of TJBench. 274 2753. Fixed out-of-bounds write in `tjDecompressToYUV2()` and 276`tjDecompressToYUVPlanes()` (sometimes manifesting as a double free) that 277occurred when attempting to decompress grayscale JPEG images that were 278compressed with a sampling factor other than 1 (for instance, with 279`cjpeg -grayscale -sample 2x2`). 280 2814. Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to 282incorrectly identify some JPEG images with unusual sampling factors as 4:4:4 283JPEG images. This was known to cause a buffer overflow when attempting to 284decompress some such images using `tjDecompressToYUV2()` or 285`tjDecompressToYUVPlanes()`. 286 2875. Fixed an issue, detected by ASan, whereby attempting to losslessly transform 288a specially-crafted malformed JPEG image containing an extremely-high-frequency 289coefficient block (junk image data that could never be generated by a 290legitimate JPEG compressor) could cause the Huffman encoder's local buffer to 291be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) Given that the buffer 292overrun was fully contained within the stack and did not cause a segfault or 293other user-visible errant behavior, and given that the lossless transformer 294(unlike the decompressor) is not generally exposed to arbitrary data exploits, 295this issue did not likely pose a security risk. 296 2976. The Arm 64-bit (Armv8) Neon SIMD assembly code now stores constants in a 298separate read-only data section rather than in the text section, to support 299execute-only memory layouts. 300 301 3022.0.3 303===== 304 305### Significant changes relative to 2.0.2: 306 3071. Fixed "using JNI after critical get" errors that occurred on Android 308platforms when passing invalid arguments to certain methods in the TurboJPEG 309Java API. 310 3112. Fixed a regression in the SIMD feature detection code, introduced by 312the AVX2 SIMD extensions (2.0 beta1[1]), that was known to cause an illegal 313instruction exception, in rare cases, on CPUs that lack support for CPUID leaf 31407H (or on which the maximum CPUID leaf has been limited by way of a BIOS 315setting.) 316 3173. The 4:4:0 (h1v2) fancy (smooth) chroma upsampling algorithm in the 318decompressor now uses a similar bias pattern to that of the 4:2:2 (h2v1) fancy 319chroma upsampling algorithm, rounding up or down the upsampled result for 320alternate pixels rather than always rounding down. This ensures that, 321regardless of whether a 4:2:2 JPEG image is rotated or transposed prior to 322decompression (in the frequency domain) or after decompression (in the spatial 323domain), the final image will be similar. 324 3254. Fixed an integer overflow and subsequent segfault that occurred when 326attempting to compress or decompress images with more than 1 billion pixels 327using the TurboJPEG API. 328 3295. Fixed a regression introduced by 2.0 beta1[15] whereby attempting to 330generate a progressive JPEG image on an SSE2-capable CPU using a scan script 331containing one or more scans with lengths divisible by 16 would result in an 332error ("Missing Huffman code table entry") and an invalid JPEG image. 333 3346. Fixed an issue whereby `tjDecodeYUV()` and `tjDecodeYUVPlanes()` would throw 335an error ("Invalid progressive parameters") or a warning ("Inconsistent 336progression sequence") if passed a TurboJPEG instance that was previously used 337to decompress a progressive JPEG image. 338 339 3402.0.2 341===== 342 343### Significant changes relative to 2.0.1: 344 3451. Fixed a regression introduced by 2.0.1[5] that prevented a runtime search 346path (rpath) from being embedded in the libjpeg-turbo shared libraries and 347executables for macOS and iOS. This caused a fatal error of the form 348"dyld: Library not loaded" when attempting to use one of the executables, 349unless `DYLD_LIBRARY_PATH` was explicitly set to the location of the 350libjpeg-turbo shared libraries. 351 3522. Fixed an integer overflow and subsequent segfault (CVE-2018-20330) that 353occurred when attempting to load a BMP file with more than 1 billion pixels 354using the `tjLoadImage()` function. 355 3563. Fixed a buffer overrun (CVE-2018-19664) that occurred when attempting to 357decompress a specially-crafted malformed JPEG image to a 256-color BMP using 358djpeg. 359 3604. Fixed a floating point exception that occurred when attempting to 361decompress a specially-crafted malformed JPEG image with a specified image 362width or height of 0 using the C version of TJBench. 363 3645. The TurboJPEG API will now decompress 4:4:4 JPEG images with 2x1, 1x2, 3x1, 365or 1x3 luminance and chrominance sampling factors. This is a non-standard way 366of specifying 1x subsampling (normally 4:4:4 JPEGs have 1x1 luminance and 367chrominance sampling factors), but the JPEG format and the libjpeg API both 368allow it. 369 3706. Fixed a regression introduced by 2.0 beta1[7] that caused djpeg to generate 371incorrect PPM images when used with the `-colors` option. 372 3737. Fixed an issue whereby a static build of libjpeg-turbo (a build in which 374`ENABLE_SHARED` is `0`) could not be installed using the Visual Studio IDE. 375 3768. Fixed a severe performance issue in the Loongson MMI SIMD extensions that 377occurred when compressing RGB images whose image rows were not 64-bit-aligned. 378 379 3802.0.1 381===== 382 383### Significant changes relative to 2.0.0: 384 3851. Fixed a regression introduced with the new CMake-based Un*x build system, 386whereby jconfig.h could cause compiler warnings of the form 387`"HAVE_*_H" redefined` if it was included by downstream Autotools-based 388projects that used `AC_CHECK_HEADERS()` to check for the existence of locale.h, 389stddef.h, or stdlib.h. 390 3912. The `jsimd_quantize_float_dspr2()` and `jsimd_convsamp_float_dspr2()` 392functions in the MIPS DSPr2 SIMD extensions are now disabled at compile time 393if the soft float ABI is enabled. Those functions use instructions that are 394incompatible with the soft float ABI. 395 3963. Fixed a regression in the SIMD feature detection code, introduced by 397the AVX2 SIMD extensions (2.0 beta1[1]), that caused libjpeg-turbo to crash on 398Windows 7 if Service Pack 1 was not installed. 399 4004. Fixed out-of-bounds read in cjpeg that occurred when attempting to compress 401a specially-crafted malformed color-index (8-bit-per-sample) Targa file in 402which some of the samples (color indices) exceeded the bounds of the Targa 403file's color table. 404 4055. Fixed an issue whereby installing a fully static build of libjpeg-turbo 406(a build in which `CFLAGS` contains `-static` and `ENABLE_SHARED` is `0`) would 407fail with "No valid ELF RPATH or RUNPATH entry exists in the file." 408 409 4102.0.0 411===== 412 413### Significant changes relative to 2.0 beta1: 414 4151. The TurboJPEG API can now decompress CMYK JPEG images that have subsampled M 416and Y components (not to be confused with YCCK JPEG images, in which the C/M/Y 417components have been transformed into luma and chroma.) Previously, an error 418was generated ("Could not determine subsampling type for JPEG image") when such 419an image was passed to `tjDecompressHeader3()`, `tjTransform()`, 420`tjDecompressToYUVPlanes()`, `tjDecompressToYUV2()`, or the equivalent Java 421methods. 422 4232. Fixed an issue (CVE-2018-11813) whereby a specially-crafted malformed input 424file (specifically, a file with a valid Targa header but incomplete pixel data) 425would cause cjpeg to generate a JPEG file that was potentially thousands of 426times larger than the input file. The Targa reader in cjpeg was not properly 427detecting that the end of the input file had been reached prematurely, so after 428all valid pixels had been read from the input, the reader injected dummy pixels 429with values of 255 into the JPEG compressor until the number of pixels 430specified in the Targa header had been compressed. The Targa reader in cjpeg 431now behaves like the PPM reader and aborts compression if the end of the input 432file is reached prematurely. Because this issue only affected cjpeg and not 433the underlying library, and because it did not involve any out-of-bounds reads 434or other exploitable behaviors, it was not believed to represent a security 435threat. 436 4373. Fixed an issue whereby the `tjLoadImage()` and `tjSaveImage()` functions 438would produce a "Bogus message code" error message if the underlying bitmap and 439PPM readers/writers threw an error that was specific to the readers/writers 440(as opposed to a general libjpeg API error.) 441 4424. Fixed an issue (CVE-2018-1152) whereby a specially-crafted malformed BMP 443file, one in which the header specified an image width of 1073741824 pixels, 444would trigger a floating point exception (division by zero) in the 445`tjLoadImage()` function when attempting to load the BMP file into a 4464-component image buffer. 447 4485. Fixed an issue whereby certain combinations of calls to 449`jpeg_skip_scanlines()` and `jpeg_read_scanlines()` could trigger an infinite 450loop when decompressing progressive JPEG images that use vertical chroma 451subsampling (for instance, 4:2:0 or 4:4:0.) 452 4536. Fixed a segfault in `jpeg_skip_scanlines()` that occurred when decompressing 454a 4:2:2 or 4:2:0 JPEG image using the merged (non-fancy) upsampling algorithms 455(that is, when setting `cinfo.do_fancy_upsampling` to `FALSE`.) 456 4577. The new CMake-based build system will now disable the MIPS DSPr2 SIMD 458extensions if it detects that the compiler does not support DSPr2 instructions. 459 4608. Fixed out-of-bounds read in cjpeg (CVE-2018-14498) that occurred when 461attempting to compress a specially-crafted malformed color-index 462(8-bit-per-sample) BMP file in which some of the samples (color indices) 463exceeded the bounds of the BMP file's color table. 464 4659. Fixed a signed integer overflow in the progressive Huffman decoder, detected 466by the Clang and GCC undefined behavior sanitizers, that could be triggered by 467attempting to decompress a specially-crafted malformed JPEG image. This issue 468did not pose a security threat, but removing the warning made it easier to 469detect actual security issues, should they arise in the future. 470 471 4721.5.90 (2.0 beta1) 473================== 474 475### Significant changes relative to 1.5.3: 476 4771. Added AVX2 SIMD implementations of the colorspace conversion, chroma 478downsampling and upsampling, integer quantization and sample conversion, and 479accurate integer DCT/IDCT algorithms. When using the accurate integer DCT/IDCT 480algorithms on AVX2-equipped CPUs, the compression of RGB images is 481approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x) with 48264-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the 483decompression of RGB images is approximately 9-35% (avg. 17%) faster with 48464-bit code and 7-17% (avg. 12%) faster with 32-bit code. (As tested on a 4853 GHz Intel Core i7. Actual mileage may vary.) 486 4872. Overhauled the build system to use CMake on all platforms, and removed the 488autotools-based build system. This decision resulted from extensive 489discussions within the libjpeg-turbo community. libjpeg-turbo traditionally 490used CMake only for Windows builds, but there was an increasing amount of 491demand to extend CMake support to other platforms. However, because of the 492unique nature of our code base (the need to support different assemblers on 493each platform, the need for Java support, etc.), providing dual build systems 494as other OSS imaging libraries do (including libpng and libtiff) would have 495created a maintenance burden. The use of CMake greatly simplifies some aspects 496of our build system, owing to CMake's built-in support for various assemblers, 497Java, and unit testing, as well as generally fewer quirks that have to be 498worked around in order to implement our packaging system. Eliminating 499autotools puts our project slightly at odds with the traditional practices of 500the OSS community, since most "system libraries" tend to be built with 501autotools, but it is believed that the benefits of this move outweigh the 502risks. In addition to providing a unified build environment, switching to 503CMake allows for the use of various build tools and IDEs that aren't supported 504under autotools, including XCode, Ninja, and Eclipse. It also eliminates the 505need to install autotools via MacPorts/Homebrew on OS X and allows 506libjpeg-turbo to be configured without the use of a terminal/command prompt. 507Extensive testing was conducted to ensure that all features provided by the 508autotools-based build system are provided by the new build system. 509 5103. The libjpeg API in this version of libjpeg-turbo now includes two additional 511functions, `jpeg_read_icc_profile()` and `jpeg_write_icc_profile()`, that can 512be used to extract ICC profile data from a JPEG file while decompressing or to 513embed ICC profile data in a JPEG file while compressing or transforming. This 514eliminates the need for downstream projects, such as color management libraries 515and browsers, to include their own glueware for accomplishing this. 516 5174. Improved error handling in the TurboJPEG API library: 518 519 - Introduced a new function (`tjGetErrorStr2()`) in the TurboJPEG C API 520that allows compression/decompression/transform error messages to be retrieved 521in a thread-safe manner. Retrieving error messages from global functions, such 522as `tjInitCompress()` or `tjBufSize()`, is still thread-unsafe, but since those 523functions will only throw errors if passed an invalid argument or if a memory 524allocation failure occurs, thread safety is not as much of a concern. 525 - Introduced a new function (`tjGetErrorCode()`) in the TurboJPEG C API 526and a new method (`TJException.getErrorCode()`) in the TurboJPEG Java API that 527can be used to determine the severity of the last 528compression/decompression/transform error. This allows applications to 529choose whether to ignore warnings (non-fatal errors) from the underlying 530libjpeg API or to treat them as fatal. 531 - Introduced a new flag (`TJFLAG_STOPONWARNING` in the TurboJPEG C API and 532`TJ.FLAG_STOPONWARNING` in the TurboJPEG Java API) that causes the library to 533immediately halt a compression/decompression/transform operation if it 534encounters a warning from the underlying libjpeg API (the default behavior is 535to allow the operation to complete unless a fatal error is encountered.) 536 5375. Introduced a new flag in the TurboJPEG C and Java APIs (`TJFLAG_PROGRESSIVE` 538and `TJ.FLAG_PROGRESSIVE`, respectively) that causes the library to use 539progressive entropy coding in JPEG images generated by compression and 540transform operations. Additionally, a new transform option 541(`TJXOPT_PROGRESSIVE` in the C API and `TJTransform.OPT_PROGRESSIVE` in the 542Java API) has been introduced, allowing progressive entropy coding to be 543enabled for selected transforms in a multi-transform operation. 544 5456. Introduced a new transform option in the TurboJPEG API (`TJXOPT_COPYNONE` in 546the C API and `TJTransform.OPT_COPYNONE` in the Java API) that allows the 547copying of markers (including EXIF and ICC profile data) to be disabled for a 548particular transform. 549 5507. Added two functions to the TurboJPEG C API (`tjLoadImage()` and 551`tjSaveImage()`) that can be used to load/save a BMP or PPM/PGM image to/from a 552memory buffer with a specified pixel format and layout. These functions 553replace the project-private (and slow) bmp API, which was previously used by 554TJBench, and they also provide a convenient way for first-time users of 555libjpeg-turbo to quickly develop a complete JPEG compression/decompression 556program. 557 5588. The TurboJPEG C API now includes a new convenience array (`tjAlphaOffset[]`) 559that contains the alpha component index for each pixel format (or -1 if the 560pixel format lacks an alpha component.) The TurboJPEG Java API now includes a 561new method (`TJ.getAlphaOffset()`) that returns the same value. In addition, 562the `tjRedOffset[]`, `tjGreenOffset[]`, and `tjBlueOffset[]` arrays-- and the 563corresponding `TJ.getRedOffset()`, `TJ.getGreenOffset()`, and 564`TJ.getBlueOffset()` methods-- now return -1 for `TJPF_GRAY`/`TJ.PF_GRAY` 565rather than 0. This allows programs to easily determine whether a pixel format 566has red, green, blue, and alpha components. 567 5689. Added a new example (tjexample.c) that demonstrates the basic usage of the 569TurboJPEG C API. This example mirrors the functionality of TJExample.java. 570Both files are now included in the libjpeg-turbo documentation. 571 57210. Fixed two signed integer overflows in the arithmetic decoder, detected by 573the Clang undefined behavior sanitizer, that could be triggered by attempting 574to decompress a specially-crafted malformed JPEG image. These issues did not 575pose a security threat, but removing the warnings makes it easier to detect 576actual security issues, should they arise in the future. 577 57811. Fixed a bug in the merged 4:2:0 upsampling/dithered RGB565 color conversion 579algorithm that caused incorrect dithering in the output image. This algorithm 580now produces bitwise-identical results to the unmerged algorithms. 581 58212. The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64] (if 583libjpeg-turbo is built with YASM), and iOS/Arm[64] builds are now private. 584This prevents those symbols from being exposed in applications or shared 585libraries that link statically with libjpeg-turbo. 586 58713. Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and 588YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy 589chroma upsampling, integer quantization, and accurate integer DCT/IDCT 590algorithms. When using the accurate integer DCT/IDCT, this speeds up the 591compression of RGB images by approximately 70-100% and the decompression of RGB 592images by approximately 2-3.5x. 593 59414. Fixed a build error when building with older MinGW releases (regression 595caused by 1.5.1[7].) 596 59715. Added SIMD acceleration for progressive Huffman encoding on SSE2-capable 598x86 and x86-64 platforms. This speeds up the compression of full-color 599progressive JPEGs by about 85-90% on average (relative to libjpeg-turbo 1.5.x) 600when using modern Intel and AMD CPUs. 601 602 6031.5.3 604===== 605 606### Significant changes relative to 1.5.2: 607 6081. Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred 609when using the YUVImage constructor that creates an instance backed by separate 610image planes and allocates memory for the image planes. 611 6122. Fixed an issue whereby the Java version of TJUnitTest would fail when 613testing BufferedImage encoding/decoding on big endian systems. 614 6153. Fixed a segfault in djpeg that would occur if an output format other than 616PPM/PGM was selected along with the `-crop` option. The `-crop` option now 617works with the GIF and Targa formats as well (unfortunately, it cannot be made 618to work with the BMP and RLE formats due to the fact that those output engines 619write scanlines in bottom-up order.) djpeg will now exit gracefully if an 620output format other than PPM/PGM, GIF, or Targa is selected along with the 621`-crop` option. 622 6234. Fixed an issue (CVE-2017-15232) whereby `jpeg_skip_scanlines()` would 624segfault if color quantization was enabled. 625 6265. TJBench (both C and Java versions) will now display usage information if any 627command-line argument is unrecognized. This prevents the program from silently 628ignoring typos. 629 6306. Fixed an access violation in tjbench.exe (Windows) that occurred when the 631program was used to decompress an existing JPEG image. 632 6337. Fixed an ArrayIndexOutOfBoundsException in the TJExample Java program that 634occurred when attempting to decompress a JPEG image that had been compressed 635with 4:1:1 chrominance subsampling. 636 6378. Fixed an issue whereby, when using `jpeg_skip_scanlines()` to skip to the 638end of a single-scan (non-progressive) image, subsequent calls to 639`jpeg_consume_input()` would return `JPEG_SUSPENDED` rather than 640`JPEG_REACHED_EOI`. 641 6429. `jpeg_crop_scanline()` now works correctly when decompressing grayscale JPEG 643images that were compressed with a sampling factor other than 1 (for instance, 644with `cjpeg -grayscale -sample 2x2`). 645 646 6471.5.2 648===== 649 650### Significant changes relative to 1.5.1: 651 6521. Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from 653building with Android NDK platforms prior to android-21 (5.0). 654 6552. Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD 656code in libjpeg-turbo from building. 657 6583. Fixed a regression introduced by 1.5 beta1[11] that prevented the Java 659version of TJBench from outputting any reference images (the `-nowrite` switch 660was accidentally enabled by default.) 661 6624. libjpeg-turbo should now build and run with full AltiVec SIMD acceleration 663on PowerPC-based AmigaOS 4 and OpenBSD systems. 664 6655. Fixed build and runtime errors on Windows that occurred when building 666libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory 667source/destination managers. Due to an oversight, the `jpeg_skip_scanlines()` 668and `jpeg_crop_scanline()` functions were not being included in jpeg7.dll when 669libjpeg-turbo was built with `-DWITH_JPEG7=1` and `-DWITH_MEMSRCDST=1`. 670 6716. Fixed "Bogus virtual array access" error that occurred when using the 672lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was 673built with libjpeg v7 API/ABI emulation. This was apparently a long-standing 674bug that has existed since the introduction of libjpeg v7/v8 API/ABI emulation 675in libjpeg-turbo v1.1. 676 6777. The lossless transform features in jpegtran and the TurboJPEG API will now 678always attempt to adjust the EXIF image width and height tags if the image size 679changed as a result of the transform. This behavior has always existed when 680using libjpeg v8 API/ABI emulation. It was supposed to be available with 681libjpeg v7 API/ABI emulation as well but did not work properly due to a bug. 682Furthermore, there was never any good reason not to enable it with libjpeg v6b 683API/ABI emulation, since the behavior is entirely internal. Note that 684`-copy all` must be passed to jpegtran in order to transfer the EXIF tags from 685the source image to the destination image. 686 6878. Fixed several memory leaks in the TurboJPEG API library that could occur 688if the library was built with certain compilers and optimization levels 689(known to occur with GCC 4.x and clang with `-O1` and higher but not with 690GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error 691after a TurboJPEG API function allocated a local buffer. 692 6939. The libjpeg-turbo memory manager will now honor the `max_memory_to_use` 694structure member in jpeg\_memory\_mgr, which can be set to the maximum amount 695of memory (in bytes) that libjpeg-turbo should use during decompression or 696multi-pass (including progressive) compression. This limit can also be set 697using the `JPEGMEM` environment variable or using the `-maxmemory` switch in 698cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.) 699This has been a documented feature of libjpeg since v5, but the 700`malloc()`/`free()` implementation of the memory manager (jmemnobs.c) never 701implemented the feature. Restricting libjpeg-turbo's memory usage is useful 702for two reasons: it allows testers to more easily work around the 2 GB limit 703in libFuzzer, and it allows developers of security-sensitive applications to 704more easily defend against one of the progressive JPEG exploits (LJT-01-004) 705identified in 706[this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf). 707 70810. TJBench will now run each benchmark for 1 second prior to starting the 709timer, in order to improve the consistency of the results. Furthermore, the 710`-warmup` option is now used to specify the amount of warmup time rather than 711the number of warmup iterations. 712 71311. Fixed an error (`short jump is out of range`) that occurred when assembling 714the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a 715regression introduced by 1.5 beta1[12]. 716 717 7181.5.1 719===== 720 721### Significant changes relative to 1.5.0: 722 7231. Previously, the undocumented `JSIMD_FORCE*` environment variables could be 724used to force-enable a particular SIMD instruction set if multiple instruction 725sets were available on a particular platform. On x86 platforms, where CPU 726feature detection is bulletproof and multiple SIMD instruction sets are 727available, it makes sense for those environment variables to allow forcing the 728use of an instruction set only if that instruction set is available. However, 729since the ARM implementations of libjpeg-turbo can only use one SIMD 730instruction set, and since their feature detection code is less bulletproof 731(parsing /proc/cpuinfo), it makes sense for the `JSIMD_FORCENEON` environment 732variable to bypass the feature detection code and really force the use of NEON 733instructions. A new environment variable (`JSIMD_FORCEDSPR2`) was introduced 734in the MIPS implementation for the same reasons, and the existing 735`JSIMD_FORCENONE` environment variable was extended to that implementation. 736These environment variables provide a workaround for those attempting to test 737ARM and MIPS builds of libjpeg-turbo in QEMU, which passes through 738/proc/cpuinfo from the host system. 739 7402. libjpeg-turbo previously assumed that AltiVec instructions were always 741available on PowerPC platforms, which led to "illegal instruction" errors when 742running on PowerPC chips that lack AltiVec support (such as the older 7xx/G3 743and newer e5500 series.) libjpeg-turbo now examines /proc/cpuinfo on 744Linux/Android systems and enables AltiVec instructions only if the CPU supports 745them. It also now provides two environment variables, `JSIMD_FORCEALTIVEC` and 746`JSIMD_FORCENONE`, to force-enable and force-disable AltiVec instructions in 747environments where /proc/cpuinfo is an unreliable means of CPU feature 748detection (such as when running in QEMU.) On OS X, libjpeg-turbo continues to 749assume that AltiVec support is always available, which means that libjpeg-turbo 750cannot be used with G3 Macs unless you set the environment variable 751`JSIMD_FORCENONE` to `1`. 752 7533. Fixed an issue whereby 64-bit ARM (AArch64) builds of libjpeg-turbo would 754crash when built with recent releases of the Clang/LLVM compiler. This was 755caused by an ABI conformance issue in some of libjpeg-turbo's 64-bit NEON SIMD 756routines. Those routines were incorrectly using 64-bit instructions to 757transfer a 32-bit JDIMENSION argument, whereas the ABI allows the upper 758(unused) 32 bits of a 32-bit argument's register to be undefined. The new 759Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit 760structure members into a single 64-bit register, and this exposed the ABI 761conformance issue. 762 7634. Fancy upsampling is now supported when decompressing JPEG images that use 7644:4:0 (h1v2) chroma subsampling. These images are generated when losslessly 765rotating or transposing JPEG images that use 4:2:2 (h2v1) chroma subsampling. 766The h1v2 fancy upsampling algorithm is not currently SIMD-accelerated. 767 7685. If merged upsampling isn't SIMD-accelerated but YCbCr-to-RGB conversion is, 769then libjpeg-turbo will now disable merged upsampling when decompressing YCbCr 770JPEG images into RGB or extended RGB output images. This significantly speeds 771up the decompression of 4:2:0 and 4:2:2 JPEGs on ARM platforms if fancy 772upsampling is not used (for example, if the `-nosmooth` option to djpeg is 773specified.) 774 7756. The TurboJPEG API will now decompress 4:2:2 and 4:4:0 JPEG images with 7762x2 luminance sampling factors and 2x1 or 1x2 chrominance sampling factors. 777This is a non-standard way of specifying 2x subsampling (normally 4:2:2 JPEGs 778have 2x1 luminance and 1x1 chrominance sampling factors, and 4:4:0 JPEGs have 7791x2 luminance and 1x1 chrominance sampling factors), but the JPEG format and 780the libjpeg API both allow it. 781 7827. Fixed an unsigned integer overflow in the libjpeg memory manager, detected 783by the Clang undefined behavior sanitizer, that could be triggered by 784attempting to decompress a specially-crafted malformed JPEG image. This issue 785affected only 32-bit code and did not pose a security threat, but removing the 786warning makes it easier to detect actual security issues, should they arise in 787the future. 788 7898. Fixed additional negative left shifts and other issues reported by the GCC 790and Clang undefined behavior sanitizers when attempting to decompress 791specially-crafted malformed JPEG images. None of these issues posed a security 792threat, but removing the warnings makes it easier to detect actual security 793issues, should they arise in the future. 794 7959. Fixed an out-of-bounds array reference, introduced by 1.4.90[2] (partial 796image decompression) and detected by the Clang undefined behavior sanitizer, 797that could be triggered by a specially-crafted malformed JPEG image with more 798than four components. Because the out-of-bounds reference was still within the 799same structure, it was not known to pose a security threat, but removing the 800warning makes it easier to detect actual security issues, should they arise in 801the future. 802 80310. Fixed another ABI conformance issue in the 64-bit ARM (AArch64) NEON SIMD 804code. Some of the routines were incorrectly reading and storing data below the 805stack pointer, which caused segfaults in certain applications under specific 806circumstances. 807 808 8091.5.0 810===== 811 812### Significant changes relative to 1.5 beta1: 813 8141. Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast 815path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory. 816 8172. Added libjpeg-turbo version and build information to the global string table 818of the libjpeg and TurboJPEG API libraries. This is a common practice in other 819infrastructure libraries, such as OpenSSL and libpng, because it makes it easy 820to examine an application binary and determine which version of the library the 821application was linked against. 822 8233. Fixed a couple of issues in the PPM reader that would cause buffer overruns 824in cjpeg if one of the values in a binary PPM/PGM input file exceeded the 825maximum value defined in the file's header and that maximum value was greater 826than 255. libjpeg-turbo 1.4.2 already included a similar fix for ASCII PPM/PGM 827files. Note that these issues were not security bugs, since they were confined 828to the cjpeg program and did not affect any of the libjpeg-turbo libraries. 829 8304. Fixed an issue whereby attempting to decompress a JPEG file with a corrupt 831header using the `tjDecompressToYUV2()` function would cause the function to 832abort without returning an error and, under certain circumstances, corrupt the 833stack. This only occurred if `tjDecompressToYUV2()` was called prior to 834calling `tjDecompressHeader3()`, or if the return value from 835`tjDecompressHeader3()` was ignored (both cases represent incorrect usage of 836the TurboJPEG API.) 837 8385. Fixed an issue in the ARM 32-bit SIMD-accelerated Huffman encoder that 839prevented the code from assembling properly with clang. 840 8416. The `jpeg_stdio_src()`, `jpeg_mem_src()`, `jpeg_stdio_dest()`, and 842`jpeg_mem_dest()` functions in the libjpeg API will now throw an error if a 843source/destination manager has already been assigned to the compress or 844decompress object by a different function or by the calling program. This 845prevents these functions from attempting to reuse a source/destination manager 846structure that was allocated elsewhere, because there is no way to ensure that 847it would be big enough to accommodate the new source/destination manager. 848 849 8501.4.90 (1.5 beta1) 851================== 852 853### Significant changes relative to 1.4.2: 854 8551. Added full SIMD acceleration for PowerPC platforms using AltiVec VMX 856(128-bit SIMD) instructions. Although the performance of libjpeg-turbo on 857PowerPC was already good, due to the increased number of registers available 858to the compiler vs. x86, it was still possible to speed up compression by about 8593-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the 860use of AltiVec instructions. 861 8622. Added two new libjpeg API functions (`jpeg_skip_scanlines()` and 863`jpeg_crop_scanline()`) that can be used to partially decode a JPEG image. See 864[libjpeg.txt](libjpeg.txt) for more details. 865 8663. The TJCompressor and TJDecompressor classes in the TurboJPEG Java API now 867implement the Closeable interface, so those classes can be used with a 868try-with-resources statement. 869 8704. The TurboJPEG Java classes now throw unchecked idiomatic exceptions 871(IllegalArgumentException, IllegalStateException) for unrecoverable errors 872caused by incorrect API usage, and those classes throw a new checked exception 873type (TJException) for errors that are passed through from the C library. 874 8755. Source buffers for the TurboJPEG C API functions, as well as the 876`jpeg_mem_src()` function in the libjpeg API, are now declared as const 877pointers. This facilitates passing read-only buffers to those functions and 878ensures the caller that the source buffer will not be modified. This should 879not create any backward API or ABI incompatibilities with prior libjpeg-turbo 880releases. 881 8826. The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1 883FPUs. 884 8857. Fixed additional negative left shifts and other issues reported by the GCC 886and Clang undefined behavior sanitizers. Most of these issues affected only 88732-bit code, and none of them was known to pose a security threat, but removing 888the warnings makes it easier to detect actual security issues, should they 889arise in the future. 890 8918. Removed the unnecessary `.arch` directive from the ARM64 NEON SIMD code. 892This directive was preventing the code from assembling using the clang 893integrated assembler. 894 8959. Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit 896libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora 897distributions. This was due to the addition of a macro in jconfig.h that 898allows the Huffman codec to determine the word size at compile time. Since 899that macro differs between 32-bit and 64-bit builds, this caused a conflict 900between the i386 and x86_64 RPMs (any differing files, other than executables, 901are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.) 902Since the macro is used only internally, it has been moved into jconfigint.h. 903 90410. The x86-64 SIMD code can now be disabled at run time by setting the 905`JSIMD_FORCENONE` environment variable to `1` (the other SIMD implementations 906already had this capability.) 907 90811. Added a new command-line argument to TJBench (`-nowrite`) that prevents the 909benchmark from outputting any images. This removes any potential operating 910system overhead that might be caused by lazy writes to disk and thus improves 911the consistency of the performance measurements. 912 91312. Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and x86-64 914platforms. This speeds up the compression of full-color JPEGs by about 10-15% 915on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and AMD 916CPUs. Additionally, this works around an issue in the clang optimizer that 917prevents it (as of this writing) from achieving the same performance as GCC 918when compiling the C version of the Huffman encoder 919(<https://llvm.org/bugs/show_bug.cgi?id=16035>). For the purposes of 920benchmarking or regression testing, SIMD-accelerated Huffman encoding can be 921disabled by setting the `JSIMD_NOHUFFENC` environment variable to `1`. 922 92313. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used 924compression algorithms (including the accurate integer forward DCT and h2v2 & 925h2v1 downsampling algorithms, which are not accelerated in the 32-bit NEON 926implementation.) This speeds up the compression of full-color JPEGs by about 92775% on average on a Cavium ThunderX processor and by about 2-2.5x on average on 928Cortex-A53 and Cortex-A57 cores. 929 93014. Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit 931and 64-bit platforms. 932 933 For 32-bit code, this speeds up the compression of full-color JPEGs by 934about 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by 935about 6-7% on average on a typical Android device (Nexus 5X, Cortex-A53 and 936Cortex-A57), relative to libjpeg-turbo 1.4.x. Note that the larger speedup 937under iOS is due to the fact that iOS builds use LLVM, which does not optimize 938the C Huffman encoder as well as GCC does. 939 940 For 64-bit code, NEON-accelerated Huffman encoding speeds up the 941compression of full-color JPEGs by about 40% on average on a typical iOS device 942(iPhone 5S, Apple A7) and by about 7-8% on average on a typical Android device 943(Nexus 5X, Cortex-A53 and Cortex-A57), in addition to the speedup described in 944[13] above. 945 946 For the purposes of benchmarking or regression testing, SIMD-accelerated 947Huffman encoding can be disabled by setting the `JSIMD_NOHUFFENC` environment 948variable to `1`. 949 95015. pkg-config (.pc) scripts are now included for both the libjpeg and 951TurboJPEG API libraries on Un*x systems. Note that if a project's build system 952relies on these scripts, then it will not be possible to build that project 953with libjpeg or with a prior version of libjpeg-turbo. 954 95516. Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to 956improve performance on CPUs with in-order pipelines. This speeds up the 957decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX 958processor and by about 15% on average on a Cortex-A53 core. 959 96017. Fixed an issue in the accelerated Huffman decoder that could have caused 961the decoder to read past the end of the input buffer when a malformed, 962specially-crafted JPEG image was being decompressed. In prior versions of 963libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only 964if there were > 128 bytes of data in the input buffer. However, it is possible 965to construct a JPEG image in which a single Huffman block is over 430 bytes 966long, so this version of libjpeg-turbo activates the accelerated Huffman 967decoder only if there are > 512 bytes of data in the input buffer. 968 96918. Fixed a memory leak in tjunittest encountered when running the program 970with the `-yuv` option. 971 972 9731.4.2 974===== 975 976### Significant changes relative to 1.4.1: 977 9781. Fixed an issue whereby cjpeg would segfault if a Windows bitmap with a 979negative width or height was used as an input image (Windows bitmaps can have 980a negative height if they are stored in top-down order, but such files are 981rare and not supported by libjpeg-turbo.) 982 9832. Fixed an issue whereby, under certain circumstances, libjpeg-turbo would 984incorrectly encode certain JPEG images when quality=100 and the fast integer 985forward DCT were used. This was known to cause `make test` to fail when the 986library was built with `-march=haswell` on x86 systems. 987 9883. Fixed an issue whereby libjpeg-turbo would crash when built with the latest 989& greatest development version of the Clang/LLVM compiler. This was caused by 990an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD 991routines. Those routines were incorrectly using a 64-bit `mov` instruction to 992transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper 993(unused) 32 bits of a 32-bit argument's register to be undefined. The new 994Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit 995structure members into a single 64-bit register, and this exposed the ABI 996conformance issue. 997 9984. Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged) 999upsampling routine that caused a buffer overflow (and subsequent segfault) when 1000decompressing a 4:2:0 JPEG image whose scaled output width was less than 16 1001pixels. The "plain" upsampling routines are normally only used when 1002decompressing a non-YCbCr JPEG image, but they are also used when decompressing 1003a JPEG image whose scaled output height is 1. 1004 10055. Fixed various negative left shifts and other issues reported by the GCC and 1006Clang undefined behavior sanitizers. None of these was known to pose a 1007security threat, but removing the warnings makes it easier to detect actual 1008security issues, should they arise in the future. 1009 1010 10111.4.1 1012===== 1013 1014### Significant changes relative to 1.4.0: 1015 10161. tjbench now properly handles CMYK/YCCK JPEG files. Passing an argument of 1017`-cmyk` (instead of, for instance, `-rgb`) will cause tjbench to internally 1018convert the source bitmap to CMYK prior to compression, to generate YCCK JPEG 1019files, and to internally convert the decompressed CMYK pixels back to RGB after 1020decompression (the latter is done automatically if a CMYK or YCCK JPEG is 1021passed to tjbench as a source image.) The CMYK<->RGB conversion operation is 1022not benchmarked. NOTE: The quick & dirty CMYK<->RGB conversions that tjbench 1023uses are suitable for testing only. Proper conversion between CMYK and RGB 1024requires a color management system. 1025 10262. `make test` now performs additional bitwise regression tests using tjbench, 1027mainly for the purpose of testing compression from/decompression to a subregion 1028of a larger image buffer. 1029 10303. `make test` no longer tests the regression of the floating point DCT/IDCT 1031by default, since the results of those tests can vary if the algorithms in 1032question are not implemented using SIMD instructions on a particular platform. 1033See the comments in [Makefile.am](Makefile.am) for information on how to 1034re-enable the tests and to specify an expected result for them based on the 1035particulars of your platform. 1036 10374. The NULL color conversion routines have been significantly optimized, 1038which speeds up the compression of RGB and CMYK JPEGs by 5-20% when using 103964-bit code and 0-3% when using 32-bit code, and the decompression of those 1040images by 10-30% when using 64-bit code and 3-12% when using 32-bit code. 1041 10425. Fixed an "illegal instruction" error that occurred when djpeg from a 1043SIMD-enabled libjpeg-turbo MIPS build was executed with the `-nosmooth` option 1044on a MIPS machine that lacked DSPr2 support. The MIPS SIMD routines for h2v1 1045and h2v2 merged upsampling were not properly checking for the existence of 1046DSPr2. 1047 10486. Performance has been improved significantly on 64-bit non-Linux and 1049non-Windows platforms (generally 10-20% faster compression and 5-10% faster 1050decompression.) Due to an oversight, the 64-bit version of the accelerated 1051Huffman codec was not being compiled in when libjpeg-turbo was built on 1052platforms other than Windows or Linux. Oops. 1053 10547. Fixed an extremely rare bug in the Huffman encoder that caused 64-bit 1055builds of libjpeg-turbo to incorrectly encode a few specific test images when 1056quality=98, an optimized Huffman table, and the accurate integer forward DCT 1057were used. 1058 10598. The Windows (CMake) build system now supports building only static or only 1060shared libraries. This is accomplished by adding either `-DENABLE_STATIC=0` or 1061`-DENABLE_SHARED=0` to the CMake command line. 1062 10639. TurboJPEG API functions will now return an error code if a warning is 1064triggered in the underlying libjpeg API. For instance, if a JPEG file is 1065corrupt, the TurboJPEG decompression functions will attempt to decompress 1066as much of the image as possible, but those functions will now return -1 to 1067indicate that the decompression was not entirely successful. 1068 106910. Fixed a bug in the MIPS DSPr2 4:2:2 fancy upsampling routine that caused a 1070buffer overflow (and subsequent segfault) when decompressing a 4:2:2 JPEG image 1071in which the right-most MCU was 5 or 6 pixels wide. 1072 1073 10741.4.0 1075===== 1076 1077### Significant changes relative to 1.4 beta1: 1078 10791. Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build 1080because OS X does not provide the `le32toh()` and `htole32()` functions.) 1081 10822. The non-SIMD RGB565 color conversion code did not work correctly on big 1083endian machines. This has been fixed. 1084 10853. Fixed an issue in `tjPlaneSizeYUV()` whereby it would erroneously return 1 1086instead of -1 if `componentID` was > 0 and `subsamp` was `TJSAMP_GRAY`. 1087 10883. Fixed an issue in `tjBufSizeYUV2()` whereby it would erroneously return 0 1089instead of -1 if `width` was < 1. 1090 10915. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting 1092on ARM64 platforms (see 1.4 beta1[5].) 1093 10946. The `close()` method in the TJCompressor and TJDecompressor Java classes is 1095now idempotent. Previously, that method would call the native `tjDestroy()` 1096function even if the TurboJPEG instance had already been destroyed. This 1097caused an exception to be thrown during finalization, if the `close()` method 1098had already been called. The exception was caught, but it was still an 1099expensive operation. 1100 11017. The TurboJPEG API previously generated an error (`Could not determine 1102subsampling type for JPEG image`) when attempting to decompress grayscale JPEG 1103images that were compressed with a sampling factor other than 1 (for instance, 1104with `cjpeg -grayscale -sample 2x2`). Subsampling technically has no meaning 1105with grayscale JPEGs, and thus the horizontal and vertical sampling factors 1106for such images are ignored by the decompressor. However, the TurboJPEG API 1107was being too rigid and was expecting the sampling factors to be equal to 1 1108before it treated the image as a grayscale JPEG. 1109 11108. cjpeg, djpeg, and jpegtran now accept an argument of `-version`, which will 1111print the library version and exit. 1112 11139. Referring to 1.4 beta1[15], another extremely rare circumstance was 1114discovered under which the Huffman encoder's local buffer can be overrun 1115when a buffered destination manager is being used and an 1116extremely-high-frequency block (basically junk image data) is being encoded. 1117Even though the Huffman local buffer was increased from 128 bytes to 136 bytes 1118to address the previous issue, the new issue caused even the larger buffer to 1119be overrun. Further analysis reveals that, in the absolute worst case (such as 1120setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning 1121order), the Huffman encoder can produce encoded blocks that approach double the 1122size of the unencoded blocks. Thus, the Huffman local buffer was increased to 1123256 bytes, which should prevent any such issue from re-occurring in the future. 1124 112510. The new `tjPlaneSizeYUV()`, `tjPlaneWidth()`, and `tjPlaneHeight()` 1126functions were not actually usable on any platform except OS X and Windows, 1127because those functions were not included in the libturbojpeg mapfile. This 1128has been fixed. 1129 113011. Restored the `JPP()`, `JMETHOD()`, and `FAR` macros in the libjpeg-turbo 1131header files. The `JPP()` and `JMETHOD()` macros were originally implemented 1132in libjpeg as a way of supporting non-ANSI compilers that lacked support for 1133prototype parameters. libjpeg-turbo has never supported such compilers, but 1134some software packages still use the macros to define their own prototypes. 1135Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that 1136have far symbols, but some software packages still use the `FAR` macro. A 1137pretty good argument can be made that this is a bad practice on the part of the 1138software in question, but since this affects more than one package, it's just 1139easier to fix it here. 1140 114112. Fixed issues that were preventing the ARM 64-bit SIMD code from compiling 1142for iOS, and included an ARMv8 architecture in all of the binaries installed by 1143the "official" libjpeg-turbo SDK for OS X. 1144 1145 11461.3.90 (1.4 beta1) 1147================== 1148 1149### Significant changes relative to 1.3.1: 1150 11511. New features in the TurboJPEG API: 1152 1153 - YUV planar images can now be generated with an arbitrary line padding 1154(previously only 4-byte padding, which was compatible with X Video, was 1155supported.) 1156 - The decompress-to-YUV function has been extended to support image 1157scaling. 1158 - JPEG images can now be compressed from YUV planar source images. 1159 - YUV planar images can now be decoded into RGB or grayscale images. 1160 - 4:1:1 subsampling is now supported. This is mainly included for 1161compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no 1162significant advantages relative to 4:2:0. 1163 - CMYK images are now supported. This feature allows CMYK source images 1164to be compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to 1165CMYK destination images. Conversion between CMYK/YCCK and RGB or YUV images is 1166not supported. Such conversion requires a color management system and is thus 1167out of scope for a codec library. 1168 - The handling of YUV images in the Java API has been significantly 1169refactored and should now be much more intuitive. 1170 - The Java API now supports encoding a YUV image from an arbitrary 1171position in a large image buffer. 1172 - All of the YUV functions now have a corresponding function that operates 1173on separate image planes instead of a unified image buffer. This allows for 1174compressing/decoding from or decompressing/encoding to a subregion of a larger 1175YUV image. It also allows for handling YUV formats that swap the order of the 1176U and V planes. 1177 11782. Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up 1179the compression of full-color JPEGs by 70-80% on such platforms and 1180decompression by 25-35%. 1181 11823. If an application attempts to decompress a Huffman-coded JPEG image whose 1183header does not contain Huffman tables, libjpeg-turbo will now insert the 1184default Huffman tables. In order to save space, many motion JPEG video frames 1185are encoded without the default Huffman tables, so these frames can now be 1186successfully decompressed by libjpeg-turbo without additional work on the part 1187of the application. An application can still override the Huffman tables, for 1188instance to re-use tables from a previous frame of the same video. 1189 11904. The Mac packaging system now uses pkgbuild and productbuild rather than 1191PackageMaker (which is obsolete and no longer supported.) This means that 1192OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo, 1193although the packages produced can be installed on OS X 10.5 "Leopard" or 1194later. OS X 10.4 "Tiger" is no longer supported. 1195 11965. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting 1197on ARM platforms rather than a lookup table. This reduces the memory footprint 1198by 64k, which may be important for some mobile applications. Out of four 1199Android devices that were tested, two demonstrated a small overall performance 1200loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with 1201ARMv7 code when enabling this new feature, but the other two devices 1202demonstrated a significant overall performance gain with both ARMv6 and ARMv7 1203code (~10-20%) when enabling the feature. Actual mileage may vary. 1204 12056. Worked around an issue with Visual C++ 2010 and later that caused incorrect 1206pixels to be generated when decompressing a JPEG image to a 256-color bitmap, 1207if compiler optimization was enabled when libjpeg-turbo was built. This caused 1208the regression tests to fail when doing a release build under Visual C++ 2010 1209and later. 1210 12117. Improved the accuracy and performance of the non-SIMD implementation of the 1212floating point inverse DCT (using code borrowed from libjpeg v8a and later.) 1213The accuracy of this implementation now matches the accuracy of the SSE/SSE2 1214implementation. Note, however, that the floating point DCT/IDCT algorithms are 1215mainly a legacy feature. They generally do not produce significantly better 1216accuracy than the accurate integer DCT/IDCT algorithms, and they are quite a 1217bit slower. 1218 12198. Added a new output colorspace (`JCS_RGB565`) to the libjpeg API that allows 1220for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not 1221used, then this code path is SIMD-accelerated on ARM platforms. 1222 12239. Numerous obsolete features, such as support for non-ANSI compilers and 1224support for the MS-DOS memory model, were removed from the libjpeg code, 1225greatly improving its readability and making it easier to maintain and extend. 1226 122710. Fixed a segfault that occurred when calling `output_message()` with 1228`msg_code` set to `JMSG_COPYRIGHT`. 1229 123011. Fixed an issue whereby wrjpgcom was allowing comments longer than 65k 1231characters to be passed on the command line, which was causing it to generate 1232incorrect JPEG files. 1233 123412. Fixed a bug in the build system that was causing the Windows version of 1235wrjpgcom to be built using the rdjpgcom source code. 1236 123713. Restored 12-bit-per-component JPEG support. A 12-bit version of 1238libjpeg-turbo can now be built by passing an argument of `--with-12bit` to 1239configure (Unix) or `-DWITH_12BIT=1` to cmake (Windows.) 12-bit JPEG support 1240is included only for convenience. Enabling this feature disables all of the 1241performance features in libjpeg-turbo, as well as arithmetic coding and the 1242TurboJPEG API. The resulting library still contains the other libjpeg-turbo 1243features (such as the colorspace extensions), but in general, it performs no 1244faster than libjpeg v6b. 1245 124614. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion 1247and IDCT algorithms (both are used during JPEG decompression.) For unknown 1248reasons (probably related to clang), this code cannot currently be compiled for 1249iOS. 1250 125115. Fixed an extremely rare bug (CVE-2014-9092) that could cause the Huffman 1252encoder's local buffer to overrun when a very high-frequency MCU is compressed 1253using quality 100 and no subsampling, and when the JPEG output buffer is being 1254dynamically resized by the destination manager. This issue was so rare that, 1255even with a test program specifically designed to make the bug occur (by 1256injecting random high-frequency YUV data into the compressor), it was 1257reproducible only once in about every 25 million iterations. 1258 125916. Fixed an oversight in the TurboJPEG C wrapper: if any of the JPEG 1260compression functions was called repeatedly with the same 1261automatically-allocated destination buffer, then TurboJPEG would erroneously 1262assume that the `jpegSize` parameter was equal to the size of the buffer, when 1263in fact that parameter was probably equal to the size of the most recently 1264compressed JPEG image. If the size of the previous JPEG image was not as large 1265as the current JPEG image, then TurboJPEG would unnecessarily reallocate the 1266destination buffer. 1267 1268 12691.3.1 1270===== 1271 1272### Significant changes relative to 1.3.0: 1273 12741. On Un*x systems, `make install` now installs the libjpeg-turbo libraries 1275into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86, 1276and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just 1277x86-64. You can override this by overriding either the `prefix` or `libdir` 1278configure variables. 1279 12802. The Windows installer now places a copy of the TurboJPEG DLLs in the same 1281directory as the rest of the libjpeg-turbo binaries. This was mainly done 1282to support TurboVNC 1.3, which bundles the DLLs in its Windows installation. 1283When using a 32-bit version of CMake on 64-bit Windows, it is impossible to 1284access the c:\WINDOWS\system32 directory, which made it impossible for the 1285TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL. 1286 12873. Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic 1288entropy coding (by passing arguments of `-progressive -arithmetic` to cjpeg or 1289jpegtran, for instance) would result in an error, `Requested feature was 1290omitted at compile time`. 1291 12924. Fixed a couple of issues (CVE-2013-6629 and CVE-2013-6630) whereby malformed 1293JPEG images would cause libjpeg-turbo to use uninitialized memory during 1294decompression. 1295 12965. Fixed an error (`Buffer passed to JPEG library is too small`) that occurred 1297when calling the TurboJPEG YUV encoding function with a very small (< 5x5) 1298source image, and added a unit test to check for this error. 1299 13006. The Java classes should now build properly under Visual Studio 2010 and 1301later. 1302 13037. Fixed an issue that prevented SRPMs generated using the in-tree packaging 1304tools from being rebuilt on certain newer Linux distributions. 1305 13068. Numerous minor fixes to eliminate compilation and build/packaging system 1307warnings, fix cosmetic issues, improve documentation clarity, and other general 1308source cleanup. 1309 1310 13111.3.0 1312===== 1313 1314### Significant changes relative to 1.3 beta1: 1315 13161. `make test` now works properly on FreeBSD, and it no longer requires the 1317md5sum executable to be present on other Un*x platforms. 1318 13192. Overhauled the packaging system: 1320 1321 - To avoid conflict with vendor-supplied libjpeg-turbo packages, the 1322official RPMs and DEBs for libjpeg-turbo have been renamed to 1323"libjpeg-turbo-official". 1324 - The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the 1325official Linux and Mac packages, to avoid conflict with vendor-supplied 1326packages and also to streamline the packaging system. 1327 - Release packages are now created with the directory structure defined 1328by the configure variables `prefix`, `bindir`, `libdir`, etc. (Un\*x) or by the 1329`CMAKE_INSTALL_PREFIX` variable (Windows.) The exception is that the docs are 1330always located under the system default documentation directory on Un\*x and 1331Mac systems, and on Windows, the TurboJPEG DLL is always located in the Windows 1332system directory. 1333 - To avoid confusion, official libjpeg-turbo packages on Linux/Unix 1334platforms (except for Mac) will always install the 32-bit libraries in 1335/opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64. 1336 - Fixed an issue whereby, in some cases, the libjpeg-turbo executables on 1337Un*x systems were not properly linking with the shared libraries installed by 1338the same package. 1339 - Fixed an issue whereby building the "installer" target on Windows when 1340`WITH_JAVA=1` would fail if the TurboJPEG JAR had not been previously built. 1341 - Building the "install" target on Windows now installs files into the 1342same places that the installer does. 1343 13443. Fixed a Huffman encoder bug that prevented I/O suspension from working 1345properly. 1346 1347 13481.2.90 (1.3 beta1) 1349================== 1350 1351### Significant changes relative to 1.2.1: 1352 13531. Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4, 135411/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing. Note that the IDCT will 1355not be SIMD-accelerated when using any of these new scaling factors. 1356 13572. The TurboJPEG dynamic library is now versioned. It was not strictly 1358necessary to do so, because TurboJPEG uses versioned symbols, and if a function 1359changes in an ABI-incompatible way, that function is renamed and a legacy 1360function is provided to maintain backward compatibility. However, certain 1361Linux distro maintainers have a policy against accepting any library that isn't 1362versioned. 1363 13643. Extended the TurboJPEG Java API so that it can be used to compress a JPEG 1365image from and decompress a JPEG image to an arbitrary position in a large 1366image buffer. 1367 13684. The `tjDecompressToYUV()` function now supports the `TJFLAG_FASTDCT` flag. 1369 13705. The 32-bit supplementary package for amd64 Debian systems now provides 1371symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32. 1372This allows those libraries to be used on MultiArch-compatible systems (such as 1373Ubuntu 11 and later) without setting the linker path. 1374 13756. The TurboJPEG Java wrapper should now find the JNI library on Mac systems 1376without having to pass `-Djava.library.path=/usr/lib` to java. 1377 13787. TJBench has been ported to Java to provide a convenient way of validating 1379the performance of the TurboJPEG Java API. It can be run with 1380`java -cp turbojpeg.jar TJBench`. 1381 13828. cjpeg can now be used to generate JPEG files with the RGB colorspace 1383(feature ported from jpeg-8d.) 1384 13859. The width and height in the `-crop` argument passed to jpegtran can now be 1386suffixed with `f` to indicate that, when the upper left corner of the cropping 1387region is automatically moved to the nearest iMCU boundary, the bottom right 1388corner should be moved by the same amount. In other words, this feature causes 1389jpegtran to strictly honor the specified width/height rather than the specified 1390bottom right corner (feature ported from jpeg-8d.) 1391 139210. JPEG files using the RGB colorspace can now be decompressed into grayscale 1393images (feature ported from jpeg-8d.) 1394 139511. Fixed a regression caused by 1.2.1[7] whereby the build would fail with 1396multiple "Mismatch in operand sizes" errors when attempting to build the x86 1397SIMD code with NASM 0.98. 1398 139912. The in-memory source/destination managers (`jpeg_mem_src()` and 1400`jpeg_mem_dest()`) are now included by default when building libjpeg-turbo with 1401libjpeg v6b or v7 emulation, so that programs can take advantage of these 1402functions without requiring the use of the backward-incompatible libjpeg v8 1403ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been 1404incremented by 1 to reflect this. You can disable this feature with a 1405configure/CMake switch in order to retain strict API/ABI compatibility with the 1406libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See 1407[README.md](README.md) for more details. 1408 140913. Added ARMv7s architecture to libjpeg.a and libturbojpeg.a in the official 1410libjpeg-turbo binary package for OS X, so that those libraries can be used to 1411build applications that leverage the faster CPUs in the iPhone 5 and iPad 4. 1412 1413 14141.2.1 1415===== 1416 1417### Significant changes relative to 1.2.0: 1418 14191. Creating or decoding a JPEG file that uses the RGB colorspace should now 1420properly work when the input or output colorspace is one of the libjpeg-turbo 1421colorspace extensions. 1422 14232. When libjpeg-turbo was built without SIMD support and merged (non-fancy) 1424upsampling was used along with an alpha-enabled colorspace during 1425decompression, the unused byte of the decompressed pixels was not being set to 14260xFF. This has been fixed. TJUnitTest has also been extended to test for the 1427correct behavior of the colorspace extensions when merged upsampling is used. 1428 14293. Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the 1430upper 64 bits of xmm6 and xmm7 on Win64 platforms, which violated the Win64 1431calling conventions. 1432 14334. Fixed a regression (CVE-2012-2806) caused by 1.2.0[6] whereby decompressing 1434corrupt JPEG images (specifically, images in which the component count was 1435erroneously set to a large value) would cause libjpeg-turbo to segfault. 1436 14375. Worked around a severe performance issue with "Bobcat" (AMD Embedded APU) 1438processors. The `MASKMOVDQU` instruction, which was used by the libjpeg-turbo 1439SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and 1440it is painfully slow on Bobcat processors in particular. Eliminating the use 1441of this instruction improved performance by an order of magnitude on Bobcat 1442processors and by a small amount (typically 5%) on AMD desktop processors. 1443 14446. Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM 1445platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such 1446platforms. 1447 14487. Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms 1449running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or 14504:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy 1451upsampling would produce several incorrect columns of pixels at the right-hand 1452side of the output image if each row in the output image was not evenly 1453divisible by 16 bytes. 1454 14558. Fixed an issue whereby attempting to build the SIMD extensions with Xcode 14564.3 on OS X platforms would cause NASM to return numerous errors of the form 1457"'%define' expects a macro identifier". 1458 14599. Added flags to the TurboJPEG API that allow the caller to force the use of 1460either the fast or the accurate DCT/IDCT algorithms in the underlying codec. 1461 1462 14631.2.0 1464===== 1465 1466### Significant changes relative to 1.2 beta1: 1467 14681. Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system 1469was not adding the current directory to the assembler include path, so YASM 1470was not able to find jsimdcfg.inc.) 1471 14722. Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing 1473a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes. 1474This was more of an annoyance than an actual bug, since it did not cause any 1475actual run-time problems, but the issue showed up when running libjpeg-turbo in 1476valgrind. See <http://crbug.com/72399> for more information. 1477 14783. Added a compile-time macro (`LIBJPEG_TURBO_VERSION`) that can be used to 1479check the version of libjpeg-turbo against which an application was compiled. 1480 14814. Added new RGBA/BGRA/ABGR/ARGB colorspace extension constants (libjpeg API) 1482and pixel formats (TurboJPEG API), which allow applications to specify that, 1483when decompressing to a 4-component RGB buffer, the unused byte should be set 1484to 0xFF so that it can be interpreted as an opaque alpha channel. 1485 14865. Fixed regression issue whereby DevIL failed to build against libjpeg-turbo 1487because libjpeg-turbo's distributed version of jconfig.h contained an `INLINE` 1488macro, which conflicted with a similar macro in DevIL. This macro is used only 1489internally when building libjpeg-turbo, so it was moved into config.h. 1490 14916. libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose 1492K component is assigned a component ID of 1 instead of 4. Although these files 1493are in violation of the spec, other JPEG implementations handle them 1494correctly. 1495 14967. Added ARMv6 and ARMv7 architectures to libjpeg.a and libturbojpeg.a in 1497the official libjpeg-turbo binary package for OS X, so that those libraries can 1498be used to build both OS X and iOS applications. 1499 1500 15011.1.90 (1.2 beta1) 1502================== 1503 1504### Significant changes relative to 1.1.1: 1505 15061. Added a Java wrapper for the TurboJPEG API. See [java/README](java/README) 1507for more details. 1508 15092. The TurboJPEG API can now be used to scale down images during 1510decompression. 1511 15123. Added SIMD routines for RGB-to-grayscale color conversion, which 1513significantly improves the performance of grayscale JPEG compression from an 1514RGB source image. 1515 15164. Improved the performance of the C color conversion routines, which are used 1517on platforms for which SIMD acceleration is not available. 1518 15195. Added a function to the TurboJPEG API that performs lossless transforms. 1520This function is implemented using the same back end as jpegtran, but it 1521performs transcoding entirely in memory and allows multiple transforms and/or 1522crop operations to be batched together, so the source coefficients only need to 1523be read once. This is useful when generating image tiles from a single source 1524JPEG. 1525 15266. Added tests for the new TurboJPEG scaled decompression and lossless 1527transform features to tjbench (the TurboJPEG benchmark, formerly called 1528"jpgtest".) 1529 15307. Added support for 4:4:0 (transposed 4:2:2) subsampling in TurboJPEG, which 1531was necessary in order for it to read 4:2:2 JPEG files that had been losslessly 1532transposed or rotated 90 degrees. 1533 15348. All legacy VirtualGL code has been re-factored, and this has allowed 1535libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license. 1536 15379. libjpeg-turbo can now be built with YASM. 1538 153910. Added SIMD acceleration for ARM Linux and iOS platforms that support 1540NEON instructions. 1541 154211. Refactored the TurboJPEG C API and documented it using Doxygen. The 1543TurboJPEG 1.2 API uses pixel formats to define the size and component order of 1544the uncompressed source/destination images, and it includes a more efficient 1545version of `TJBUFSIZE()` that computes a worst-case JPEG size based on the 1546level of chrominance subsampling. The refactored implementation of the 1547TurboJPEG API now uses the libjpeg memory source and destination managers, 1548which allows the TurboJPEG compressor to grow the JPEG buffer as necessary. 1549 155012. Eliminated errors in the output of jpegtran on Windows that occurred when 1551the application was invoked using I/O redirection 1552(`jpegtran <input.jpg >output.jpg`.) 1553 155413. The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding 1555support in libjpeg-turbo v1.1.0 introduced several new error constants in 1556jerror.h, and these were mistakenly enabled for all emulation modes, causing 1557the error enum in libjpeg-turbo to sometimes have different values than the 1558same enum in libjpeg. This represents an ABI incompatibility, and it caused 1559problems with rare applications that took specific action based on a particular 1560error value. The fix was to include the new error constants conditionally 1561based on whether libjpeg v7 or v8 emulation was enabled. 1562 156314. Fixed an issue whereby Windows applications that used libjpeg-turbo would 1564fail to compile if the Windows system headers were included before jpeglib.h. 1565This issue was caused by a conflict in the definition of the INT32 type. 1566 156715. Fixed 32-bit supplementary package for amd64 Debian systems, which was 1568broken by enhancements to the packaging system in 1.1. 1569 157016. When decompressing a JPEG image using an output colorspace of 1571`JCS_EXT_RGBX`, `JCS_EXT_BGRX`, `JCS_EXT_XBGR`, or `JCS_EXT_XRGB`, 1572libjpeg-turbo will now set the unused byte to 0xFF, which allows applications 1573to interpret that byte as an alpha channel (0xFF = opaque). 1574 1575 15761.1.1 1577===== 1578 1579### Significant changes relative to 1.1.0: 1580 15811. Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated 1582by `tjEncodeYUV()`. 1583 15842. libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected 1585markers found in the middle of the JPEG data stream during decompression. It 1586will now hand off decoding of a particular block to the unaccelerated Huffman 1587decoder if an unexpected marker is found, so that the unaccelerated Huffman 1588decoder can generate an appropriate warning. 1589 15903. Older versions of MinGW64 prefixed symbol names with underscores by 1591default, which differed from the behavior of 64-bit Visual C++. MinGW64 1.0 1592has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate 1593this, the libjpeg-turbo SIMD function names are no longer prefixed with an 1594underscore when building with MinGW64. This means that, when building 1595libjpeg-turbo with older versions of MinGW64, you will now have to add 1596`-fno-leading-underscore` to the `CFLAGS`. 1597 15984. Fixed a regression bug in the NSIS script that caused the Windows installer 1599build to fail when using the Visual Studio IDE. 1600 16015. Fixed a bug in `jpeg_read_coefficients()` whereby it would not initialize 1602`cinfo->image_width` and `cinfo->image_height` if libjpeg v7 or v8 emulation 1603was enabled. This specifically caused the jpegoptim program to fail if it was 1604linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8 1605emulation. 1606 16076. Eliminated excessive I/O overhead that occurred when reading BMP files in 1608cjpeg. 1609 16107. Eliminated errors in the output of cjpeg on Windows that occurred when the 1611application was invoked using I/O redirection (`cjpeg <inputfile >output.jpg`.) 1612 1613 16141.1.0 1615===== 1616 1617### Significant changes relative to 1.1 beta1: 1618 16191. The algorithm used by the SIMD quantization function cannot produce correct 1620results when the JPEG quality is >= 98 and the fast integer forward DCT is 1621used. Thus, the non-SIMD quantization function is now used for those cases, 1622and libjpeg-turbo should now produce identical output to libjpeg v6b in all 1623cases. 1624 16252. Despite the above, the fast integer forward DCT still degrades somewhat for 1626JPEG qualities greater than 95, so the TurboJPEG wrapper will now automatically 1627use the accurate integer forward DCT when generating JPEG images of quality 96 1628or greater. This reduces compression performance by as much as 15% for these 1629high-quality images but is necessary to ensure that the images are perceptually 1630lossless. It also ensures that the library can avoid the performance pitfall 1631created by [1]. 1632 16333. Ported jpgtest.cxx to pure C to avoid the need for a C++ compiler. 1634 16354. Fixed visual artifacts in grayscale JPEG compression caused by a typo in 1636the RGB-to-luminance lookup tables. 1637 16385. The Windows distribution packages now include the libjpeg run-time programs 1639(cjpeg, etc.) 1640 16416. All packages now include jpgtest. 1642 16437. The TurboJPEG dynamic library now uses versioned symbols. 1644 16458. Added two new TurboJPEG API functions, `tjEncodeYUV()` and 1646`tjDecompressToYUV()`, to replace the somewhat hackish `TJ_YUV` flag. 1647 1648 16491.0.90 (1.1 beta1) 1650================== 1651 1652### Significant changes relative to 1.0.1: 1653 16541. Added emulation of the libjpeg v7 and v8 APIs and ABIs. See 1655[README.md](README.md) for more details. This feature was sponsored by 1656CamTrace SAS. 1657 16582. Created a new CMake-based build system for the Visual C++ and MinGW builds. 1659 16603. Grayscale bitmaps can now be compressed from/decompressed to using the 1661TurboJPEG API. 1662 16634. jpgtest can now be used to test decompression performance with existing 1664JPEG images. 1665 16665. If the default install prefix (/opt/libjpeg-turbo) is used, then 1667`make install` now creates /opt/libjpeg-turbo/lib32 and 1668/opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary 1669packages. 1670 16716. All symbols in the libjpeg-turbo dynamic library are now versioned, even 1672when the library is built with libjpeg v6b emulation. 1673 16747. Added arithmetic encoding and decoding support (can be disabled with 1675configure or CMake options) 1676 16778. Added a `TJ_YUV` flag to the TurboJPEG API, which causes both the compressor 1678and decompressor to output planar YUV images. 1679 16809. Added an extended version of `tjDecompressHeader()` to the TurboJPEG API, 1681which allows the caller to determine the type of subsampling used in a JPEG 1682image. 1683 168410. Added further protections against invalid Huffman codes. 1685 1686 16871.0.1 1688===== 1689 1690### Significant changes relative to 1.0.0: 1691 16921. The Huffman decoder will now handle erroneous Huffman codes (for instance, 1693from a corrupt JPEG image.) Previously, these would cause libjpeg-turbo to 1694crash under certain circumstances. 1695 16962. Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to 1697be used instead of 4:2:0 when decompressing JPEG images using SSE2 code. 1698 16993. The configure script will now automatically determine whether the 1700`INCOMPLETE_TYPES_BROKEN` macro should be defined. 1701 1702 17031.0.0 1704===== 1705 1706### Significant changes relative to 0.0.93: 1707 17081. 2983700: Further FreeBSD build tweaks (no longer necessary to specify 1709`--host` when configuring on a 64-bit system) 1710 17112. Created symlinks in the Unix/Linux packages so that the TurboJPEG 1712include file can always be found in /opt/libjpeg-turbo/include, the 32-bit 1713static libraries can always be found in /opt/libjpeg-turbo/lib32, and the 171464-bit static libraries can always be found in /opt/libjpeg-turbo/lib64. 1715 17163. The Unix/Linux distribution packages now include the libjpeg run-time 1717programs (cjpeg, etc.) and man pages. 1718 17194. Created a 32-bit supplementary package for amd64 Debian systems, which 1720contains just the 32-bit libjpeg-turbo libraries. 1721 17225. Moved the libraries from */lib32 to */lib in the i386 Debian package. 1723 17246. Include distribution package for Cygwin 1725 17267. No longer necessary to specify `--without-simd` on non-x86 architectures, 1727and unit tests now work on those architectures. 1728 1729 17300.0.93 1731====== 1732 1733### Significant changes since 0.0.91: 1734 17351. 2982659: Fixed x86-64 build on FreeBSD systems 1736 17372. 2988188: Added support for Windows 64-bit systems 1738 1739 17400.0.91 1741====== 1742 1743### Significant changes relative to 0.0.90: 1744 17451. Added documentation to .deb packages 1746 17472. 2968313: Fixed data corruption issues when decompressing large JPEG images 1748and/or using buffered I/O with the libjpeg-turbo decompressor 1749 1750 17510.0.90 1752====== 1753 1754Initial release 1755
