12.1.2 2===== 3 41. Fixed a regression introduced by 2.1 beta1[13] that caused the remaining 5GAS implementations of AArch64 (Arm 64-bit) Neon SIMD functions (which are used 6by default with GCC for performance reasons) to be placed in the `.rodata` 7section rather than in the `.text` section. This caused the GNU linker to 8automatically place the `.rodata` section in an executable segment, which 9prevented libjpeg-turbo from working properly with other linkers and also 10represented a potential security risk. 11 124. libjpeg-turbo now performs run-time detection of AltiVec instructions on 13FreeBSD/PowerPC systems if AltiVec instructions are not enabled at compile 14time. This allows both AltiVec-equipped and non-AltiVec-equipped CPUs to be 15supported using the same build of libjpeg-turbo. 16 17 182.1.1 19===== 20 21### Significant changes relative to 2.1.0 22 231. Fixed a regression introduced in 2.1.0 that caused build failures with 24non-GCC-compatible compilers for Un*x/Arm platforms. 25 262. Fixed a regression introduced by 2.1 beta1[13] that prevented the Arm 32-bit 27(AArch32) Neon SIMD extensions from building unless the C compiler flags 28included `-mfloat-abi=softfp` or `-mfloat-abi=hard`. 29 303. Fixed an issue in the AArch32 Neon SIMD Huffman encoder whereby reliance on 31undefined C compiler behavior led to crashes ("SIGBUS: illegal alignment") on 32Android systems when running AArch32/Thumb builds of libjpeg-turbo built with 33recent versions of Clang. 34 354. Added a command-line argument (`-copy icc`) to jpegtran that causes it to 36copy only the ICC profile markers from the source file and discard any other 37metadata. 38 395. libjpeg-turbo should now build and run on CHERI-enabled architectures, which 40use capability pointers that are larger than the size of `size_t`. 41 426. Fixed a regression introduced by 2.1 beta1[5] that caused a segfault in the 4364-bit SSE2 Huffman encoder when attempting to losslessly transform a 44specially-crafted malformed JPEG image. 45 462. Fixed an issue whereby the `tjTransform()` function incorrectly computed the 47MCU block size for 4:4:4 JPEG images with non-unary sampling factors and thus 48unduly rejected some cropping regions, even though those regions aligned with 498x8 MCU block boundaries. 50 51 522.1.0 53===== 54 55### Significant changes relative to 2.1 beta1 56 571. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to 58decompress certain progressive JPEG images with one or more component planes of 59width 8 or less caused a buffer overrun. 60 612. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to 62decompress a specially-crafted malformed progressive JPEG image caused the 63block smoothing algorithm to read from uninitialized memory. 64 653. Fixed an issue in the Arm Neon SIMD Huffman encoders that caused the 66encoders to generate incorrect results when using the Clang compiler with 67Visual Studio. 68 694. Fixed a floating point exception (CVE-2021-20205) that occurred when 70attempting to compress a specially-crafted malformed GIF image with a specified 71image width of 0 using cjpeg. 72 735. Fixed a regression introduced by 2.0 beta1[15] whereby attempting to 74generate a progressive JPEG image on an SSE2-capable CPU using a scan script 75containing one or more scans with lengths divisible by 32 and non-zero 76successive approximation low bit positions would, under certain circumstances, 77result in an error ("Missing Huffman code table entry") and an invalid JPEG 78image. 79 806. Introduced a new flag (`TJFLAG_LIMITSCANS` in the TurboJPEG C API and 81`TJ.FLAG_LIMIT_SCANS` in the TurboJPEG Java API) and a corresponding TJBench 82command-line argument (`-limitscans`) that causes the TurboJPEG decompression 83and transform functions/operations to return/throw an error if a progressive 84JPEG image contains an unreasonably large number of scans. This allows 85applications that use the TurboJPEG API to guard against an exploit of the 86progressive JPEG format described in the report 87["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf). 88 897. The PPM reader now throws an error, rather than segfaulting (due to a buffer 90overrun) or generating incorrect pixels, if an application attempts to use the 91`tjLoadImage()` function to load a 16-bit binary PPM file (a binary PPM file 92with a maximum value greater than 255) into a grayscale image buffer or to load 93a 16-bit binary PGM file into an RGB image buffer. 94 958. Fixed an issue in the PPM reader that caused incorrect pixels to be 96generated when using the `tjLoadImage()` function to load a 16-bit binary PPM 97file into an extended RGB image buffer. 98 999. Fixed an issue whereby, if a JPEG buffer was automatically re-allocated by 100one of the TurboJPEG compression or transform functions and an error 101subsequently occurred during compression or transformation, the JPEG buffer 102pointer passed by the application was not updated when the function returned. 103 104 1052.0.90 (2.1 beta1) 106================== 107 108### Significant changes relative to 2.0.6: 109 1101. The build system, x86-64 SIMD extensions, and accelerated Huffman codec now 111support the x32 ABI on Linux, which allows for using x86-64 instructions with 11232-bit pointers. The x32 ABI is generally enabled by adding `-mx32` to the 113compiler flags. 114 115 Caveats: 116 - CMake 3.9.0 or later is required in order for the build system to 117automatically detect an x32 build. 118 - Java does not support the x32 ABI, and thus the TurboJPEG Java API will 119automatically be disabled with x32 builds. 120 1212. Added Loongson MMI SIMD implementations of the RGB-to-grayscale, 4:2:2 fancy 122chroma upsampling, 4:2:2 and 4:2:0 merged chroma upsampling/color conversion, 123and fast integer DCT/IDCT algorithms. Relative to libjpeg-turbo 2.0.x, this 124speeds up: 125 126 - the compression of RGB source images into grayscale JPEG images by 127approximately 20% 128 - the decompression of 4:2:2 JPEG images by approximately 40-60% when 129using fancy upsampling 130 - the decompression of 4:2:2 and 4:2:0 JPEG images by approximately 13115-20% when using merged upsampling 132 - the compression of RGB source images by approximately 30-45% when using 133the fast integer DCT 134 - the decompression of JPEG images into RGB destination images by 135approximately 2x when using the fast integer IDCT 136 137 The overall decompression speedup for RGB images is now approximately 1382.3-3.7x (compared to 2-3.5x with libjpeg-turbo 2.0.x.) 139 1403. 32-bit (Armv7 or Armv7s) iOS builds of libjpeg-turbo are no longer 141supported, and the libjpeg-turbo build system can no longer be used to package 142such builds. 32-bit iOS apps cannot run in iOS 11 and later, and the App Store 143no longer allows them. 144 1454. 32-bit (i386) OS X/macOS builds of libjpeg-turbo are no longer supported, 146and the libjpeg-turbo build system can no longer be used to package such 147builds. 32-bit Mac applications cannot run in macOS 10.15 "Catalina" and 148later, and the App Store no longer allows them. 149 1505. The SSE2 (x86 SIMD) and C Huffman encoding algorithms have been 151significantly optimized, resulting in a measured average overall compression 152speedup of 12-28% for 64-bit code and 22-52% for 32-bit code on various Intel 153and AMD CPUs, as well as a measured average overall compression speedup of 1540-23% on platforms that do not have a SIMD-accelerated Huffman encoding 155implementation. 156 1576. The block smoothing algorithm that is applied by default when decompressing 158progressive Huffman-encoded JPEG images has been improved in the following 159ways: 160 161 - The algorithm is now more fault-tolerant. Previously, if a particular 162scan was incomplete, then the smoothing parameters for the incomplete scan 163would be applied to the entire output image, including the parts of the image 164that were generated by the prior (complete) scan. Visually, this had the 165effect of removing block smoothing from lower-frequency scans if they were 166followed by an incomplete higher-frequency scan. libjpeg-turbo now applies 167block smoothing parameters to each iMCU row based on which scan generated the 168pixels in that row, rather than always using the block smoothing parameters for 169the most recent scan. 170 - When applying block smoothing to DC scans, a Gaussian-like kernel with a 1715x5 window is used to reduce the "blocky" appearance. 172 1737. Added SIMD acceleration for progressive Huffman encoding on Arm platforms. 174This speeds up the compression of full-color progressive JPEGs by about 30-40% 175on average (relative to libjpeg-turbo 2.0.x) when using modern Arm CPUs. 176 1778. Added configure-time and run-time auto-detection of Loongson MMI SIMD 178instructions, so that the Loongson MMI SIMD extensions can be included in any 179MIPS64 libjpeg-turbo build. 180 1819. Added fault tolerance features to djpeg and jpegtran, mainly to demonstrate 182methods by which applications can guard against the exploits of the JPEG format 183described in the report 184["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf). 185 186 - Both programs now accept a `-maxscans` argument, which can be used to 187limit the number of allowable scans in the input file. 188 - Both programs now accept a `-strict` argument, which can be used to 189treat all warnings as fatal. 190 19110. CMake package config files are now included for both the libjpeg and 192TurboJPEG API libraries. This facilitates using libjpeg-turbo with CMake's 193`find_package()` function. For example: 194 195 find_package(libjpeg-turbo CONFIG REQUIRED) 196 197 add_executable(libjpeg_program libjpeg_program.c) 198 target_link_libraries(libjpeg_program PUBLIC libjpeg-turbo::jpeg) 199 200 add_executable(libjpeg_program_static libjpeg_program.c) 201 target_link_libraries(libjpeg_program_static PUBLIC 202 libjpeg-turbo::jpeg-static) 203 204 add_executable(turbojpeg_program turbojpeg_program.c) 205 target_link_libraries(turbojpeg_program PUBLIC 206 libjpeg-turbo::turbojpeg) 207 208 add_executable(turbojpeg_program_static turbojpeg_program.c) 209 target_link_libraries(turbojpeg_program_static PUBLIC 210 libjpeg-turbo::turbojpeg-static) 211 21211. Since the Unisys LZW patent has long expired, cjpeg and djpeg can now 213read/write both LZW-compressed and uncompressed GIF files (feature ported from 214jpeg-6a and jpeg-9d.) 215 21612. jpegtran now includes the `-wipe` and `-drop` options from jpeg-9a and 217jpeg-9d, as well as the ability to expand the image size using the `-crop` 218option. Refer to jpegtran.1 or usage.txt for more details. 219 22013. Added a complete intrinsics implementation of the Arm Neon SIMD extensions, 221thus providing SIMD acceleration on Arm platforms for all of the algorithms 222that are SIMD-accelerated on x86 platforms. This new implementation is 223significantly faster in some cases than the old GAS implementation-- 224depending on the algorithms used, the type of CPU core, and the compiler. GCC, 225as of this writing, does not provide a full or optimal set of Neon intrinsics, 226so for performance reasons, the default when building libjpeg-turbo with GCC is 227to continue using the GAS implementation of the following algorithms: 228 229 - 32-bit RGB-to-YCbCr color conversion 230 - 32-bit fast and accurate inverse DCT 231 - 64-bit RGB-to-YCbCr and YCbCr-to-RGB color conversion 232 - 64-bit accurate forward and inverse DCT 233 - 64-bit Huffman encoding 234 235 A new CMake variable (`NEON_INTRINSICS`) can be used to override this 236default. 237 238 Since the new intrinsics implementation includes SIMD acceleration 239for merged upsampling/color conversion, 1.5.1[5] is no longer necessary and has 240been reverted. 241 24214. The Arm Neon SIMD extensions can now be built using Visual Studio. 243 24415. The build system can now be used to generate a universal x86-64 + Armv8 245libjpeg-turbo SDK package for both iOS and macOS. 246 247 2482.0.6 249===== 250 251### Significant changes relative to 2.0.5: 252 2531. Fixed "using JNI after critical get" errors that occurred on Android 254platforms when using any of the YUV encoding/compression/decompression/decoding 255methods in the TurboJPEG Java API. 256 2572. Fixed or worked around multiple issues with `jpeg_skip_scanlines()`: 258 259 - Fixed segfaults or "Corrupt JPEG data: premature end of data segment" 260errors in `jpeg_skip_scanlines()` that occurred when decompressing 4:2:2 or 2614:2:0 JPEG images using merged (non-fancy) upsampling/color conversion (that 262is, when setting `cinfo.do_fancy_upsampling` to `FALSE`.) 2.0.0[6] was a 263similar fix, but it did not cover all cases. 264 - `jpeg_skip_scanlines()` now throws an error if two-pass color 265quantization is enabled. Two-pass color quantization never worked properly 266with `jpeg_skip_scanlines()`, and the issues could not readily be fixed. 267 - Fixed an issue whereby `jpeg_skip_scanlines()` always returned 0 when 268skipping past the end of an image. 269 2703. The Arm 64-bit (Armv8) Neon SIMD extensions can now be built using MinGW 271toolchains targetting Arm64 (AArch64) Windows binaries. 272 2734. Fixed unexpected visual artifacts that occurred when using 274`jpeg_crop_scanline()` and interblock smoothing while decompressing only the DC 275scan of a progressive JPEG image. 276 2775. Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-component 278JPEG support (`WITH_12BIT`) was enabled along with libjpeg v7 or libjpeg v8 279API/ABI emulation (`WITH_JPEG7` or `WITH_JPEG8`.) 280 281 2822.0.5 283===== 284 285### Significant changes relative to 2.0.4: 286 2871. Worked around issues in the MIPS DSPr2 SIMD extensions that caused failures 288in the libjpeg-turbo regression tests. Specifically, the 289`jsimd_h2v1_downsample_dspr2()` and `jsimd_h2v2_downsample_dspr2()` functions 290in the MIPS DSPr2 SIMD extensions are now disabled until/unless they can be 291fixed, and other functions that are incompatible with big endian MIPS CPUs are 292disabled when building libjpeg-turbo for such CPUs. 293 2942. Fixed an oversight in the `TJCompressor.compress(int)` method in the 295TurboJPEG Java API that caused an error ("java.lang.IllegalStateException: No 296source image is associated with this instance") when attempting to use that 297method to compress a YUV image. 298 2993. Fixed an issue (CVE-2020-13790) in the PPM reader that caused a buffer 300overrun in cjpeg, TJBench, or the `tjLoadImage()` function if one of the values 301in a binary PPM/PGM input file exceeded the maximum value defined in the file's 302header and that maximum value was less than 255. libjpeg-turbo 1.5.0 already 303included a similar fix for binary PPM/PGM files with maximum values greater 304than 255. 305 3064. The TurboJPEG API library's global error handler, which is used in functions 307such as `tjBufSize()` and `tjLoadImage()` that do not require a TurboJPEG 308instance handle, is now thread-safe on platforms that support thread-local 309storage. 310 311 3122.0.4 313===== 314 315### Significant changes relative to 2.0.3: 316 3171. Fixed a regression in the Windows packaging system (introduced by 3182.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo SDK for GCC and the 31964-bit libjpeg-turbo SDK for Visual C++ were installed on the same system, only 320one of them could be uninstalled. 321 3222. Fixed a signed integer overflow and subsequent segfault that occurred when 323attempting to decompress images with more than 715827882 pixels using the 32464-bit C version of TJBench. 325 3263. Fixed out-of-bounds write in `tjDecompressToYUV2()` and 327`tjDecompressToYUVPlanes()` (sometimes manifesting as a double free) that 328occurred when attempting to decompress grayscale JPEG images that were 329compressed with a sampling factor other than 1 (for instance, with 330`cjpeg -grayscale -sample 2x2`). 331 3324. Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to 333incorrectly identify some JPEG images with unusual sampling factors as 4:4:4 334JPEG images. This was known to cause a buffer overflow when attempting to 335decompress some such images using `tjDecompressToYUV2()` or 336`tjDecompressToYUVPlanes()`. 337 3385. Fixed an issue (CVE-2020-17541), detected by ASan, whereby attempting to 339losslessly transform a specially-crafted malformed JPEG image containing an 340extremely-high-frequency coefficient block (junk image data that could never be 341generated by a legitimate JPEG compressor) could cause the Huffman encoder's 342local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) Given that 343the buffer overrun was fully contained within the stack and did not cause a 344segfault or other user-visible errant behavior, and given that the lossless 345transformer (unlike the decompressor) is not generally exposed to arbitrary 346data exploits, this issue did not likely pose a security risk. 347 3486. The Arm 64-bit (Armv8) Neon SIMD assembly code now stores constants in a 349separate read-only data section rather than in the text section, to support 350execute-only memory layouts. 351 352 3532.0.3 354===== 355 356### Significant changes relative to 2.0.2: 357 3581. Fixed "using JNI after critical get" errors that occurred on Android 359platforms when passing invalid arguments to certain methods in the TurboJPEG 360Java API. 361 3622. Fixed a regression in the SIMD feature detection code, introduced by 363the AVX2 SIMD extensions (2.0 beta1[1]), that was known to cause an illegal 364instruction exception, in rare cases, on CPUs that lack support for CPUID leaf 36507H (or on which the maximum CPUID leaf has been limited by way of a BIOS 366setting.) 367 3683. The 4:4:0 (h1v2) fancy (smooth) chroma upsampling algorithm in the 369decompressor now uses a similar bias pattern to that of the 4:2:2 (h2v1) fancy 370chroma upsampling algorithm, rounding up or down the upsampled result for 371alternate pixels rather than always rounding down. This ensures that, 372regardless of whether a 4:2:2 JPEG image is rotated or transposed prior to 373decompression (in the frequency domain) or after decompression (in the spatial 374domain), the final image will be similar. 375 3764. Fixed an integer overflow and subsequent segfault that occurred when 377attempting to compress or decompress images with more than 1 billion pixels 378using the TurboJPEG API. 379 3805. Fixed a regression introduced by 2.0 beta1[15] whereby attempting to 381generate a progressive JPEG image on an SSE2-capable CPU using a scan script 382containing one or more scans with lengths divisible by 16 would result in an 383error ("Missing Huffman code table entry") and an invalid JPEG image. 384 3856. Fixed an issue whereby `tjDecodeYUV()` and `tjDecodeYUVPlanes()` would throw 386an error ("Invalid progressive parameters") or a warning ("Inconsistent 387progression sequence") if passed a TurboJPEG instance that was previously used 388to decompress a progressive JPEG image. 389 390 3912.0.2 392===== 393 394### Significant changes relative to 2.0.1: 395 3961. Fixed a regression introduced by 2.0.1[5] that prevented a runtime search 397path (rpath) from being embedded in the libjpeg-turbo shared libraries and 398executables for macOS and iOS. This caused a fatal error of the form 399"dyld: Library not loaded" when attempting to use one of the executables, 400unless `DYLD_LIBRARY_PATH` was explicitly set to the location of the 401libjpeg-turbo shared libraries. 402 4032. Fixed an integer overflow and subsequent segfault (CVE-2018-20330) that 404occurred when attempting to load a BMP file with more than 1 billion pixels 405using the `tjLoadImage()` function. 406 4073. Fixed a buffer overrun (CVE-2018-19664) that occurred when attempting to 408decompress a specially-crafted malformed JPEG image to a 256-color BMP using 409djpeg. 410 4114. Fixed a floating point exception that occurred when attempting to 412decompress a specially-crafted malformed JPEG image with a specified image 413width or height of 0 using the C version of TJBench. 414 4155. The TurboJPEG API will now decompress 4:4:4 JPEG images with 2x1, 1x2, 3x1, 416or 1x3 luminance and chrominance sampling factors. This is a non-standard way 417of specifying 1x subsampling (normally 4:4:4 JPEGs have 1x1 luminance and 418chrominance sampling factors), but the JPEG format and the libjpeg API both 419allow it. 420 4216. Fixed a regression introduced by 2.0 beta1[7] that caused djpeg to generate 422incorrect PPM images when used with the `-colors` option. 423 4247. Fixed an issue whereby a static build of libjpeg-turbo (a build in which 425`ENABLE_SHARED` is `0`) could not be installed using the Visual Studio IDE. 426 4278. Fixed a severe performance issue in the Loongson MMI SIMD extensions that 428occurred when compressing RGB images whose image rows were not 64-bit-aligned. 429 430 4312.0.1 432===== 433 434### Significant changes relative to 2.0.0: 435 4361. Fixed a regression introduced with the new CMake-based Un*x build system, 437whereby jconfig.h could cause compiler warnings of the form 438`"HAVE_*_H" redefined` if it was included by downstream Autotools-based 439projects that used `AC_CHECK_HEADERS()` to check for the existence of locale.h, 440stddef.h, or stdlib.h. 441 4422. The `jsimd_quantize_float_dspr2()` and `jsimd_convsamp_float_dspr2()` 443functions in the MIPS DSPr2 SIMD extensions are now disabled at compile time 444if the soft float ABI is enabled. Those functions use instructions that are 445incompatible with the soft float ABI. 446 4473. Fixed a regression in the SIMD feature detection code, introduced by 448the AVX2 SIMD extensions (2.0 beta1[1]), that caused libjpeg-turbo to crash on 449Windows 7 if Service Pack 1 was not installed. 450 4514. Fixed out-of-bounds read in cjpeg that occurred when attempting to compress 452a specially-crafted malformed color-index (8-bit-per-sample) Targa file in 453which some of the samples (color indices) exceeded the bounds of the Targa 454file's color table. 455 4565. Fixed an issue whereby installing a fully static build of libjpeg-turbo 457(a build in which `CFLAGS` contains `-static` and `ENABLE_SHARED` is `0`) would 458fail with "No valid ELF RPATH or RUNPATH entry exists in the file." 459 460 4612.0.0 462===== 463 464### Significant changes relative to 2.0 beta1: 465 4661. The TurboJPEG API can now decompress CMYK JPEG images that have subsampled M 467and Y components (not to be confused with YCCK JPEG images, in which the C/M/Y 468components have been transformed into luma and chroma.) Previously, an error 469was generated ("Could not determine subsampling type for JPEG image") when such 470an image was passed to `tjDecompressHeader3()`, `tjTransform()`, 471`tjDecompressToYUVPlanes()`, `tjDecompressToYUV2()`, or the equivalent Java 472methods. 473 4742. Fixed an issue (CVE-2018-11813) whereby a specially-crafted malformed input 475file (specifically, a file with a valid Targa header but incomplete pixel data) 476would cause cjpeg to generate a JPEG file that was potentially thousands of 477times larger than the input file. The Targa reader in cjpeg was not properly 478detecting that the end of the input file had been reached prematurely, so after 479all valid pixels had been read from the input, the reader injected dummy pixels 480with values of 255 into the JPEG compressor until the number of pixels 481specified in the Targa header had been compressed. The Targa reader in cjpeg 482now behaves like the PPM reader and aborts compression if the end of the input 483file is reached prematurely. Because this issue only affected cjpeg and not 484the underlying library, and because it did not involve any out-of-bounds reads 485or other exploitable behaviors, it was not believed to represent a security 486threat. 487 4883. Fixed an issue whereby the `tjLoadImage()` and `tjSaveImage()` functions 489would produce a "Bogus message code" error message if the underlying bitmap and 490PPM readers/writers threw an error that was specific to the readers/writers 491(as opposed to a general libjpeg API error.) 492 4934. Fixed an issue (CVE-2018-1152) whereby a specially-crafted malformed BMP 494file, one in which the header specified an image width of 1073741824 pixels, 495would trigger a floating point exception (division by zero) in the 496`tjLoadImage()` function when attempting to load the BMP file into a 4974-component image buffer. 498 4995. Fixed an issue whereby certain combinations of calls to 500`jpeg_skip_scanlines()` and `jpeg_read_scanlines()` could trigger an infinite 501loop when decompressing progressive JPEG images that use vertical chroma 502subsampling (for instance, 4:2:0 or 4:4:0.) 503 5046. Fixed a segfault in `jpeg_skip_scanlines()` that occurred when decompressing 505a 4:2:2 or 4:2:0 JPEG image using the merged (non-fancy) upsampling algorithms 506(that is, when setting `cinfo.do_fancy_upsampling` to `FALSE`.) 507 5087. The new CMake-based build system will now disable the MIPS DSPr2 SIMD 509extensions if it detects that the compiler does not support DSPr2 instructions. 510 5118. Fixed out-of-bounds read in cjpeg (CVE-2018-14498) that occurred when 512attempting to compress a specially-crafted malformed color-index 513(8-bit-per-sample) BMP file in which some of the samples (color indices) 514exceeded the bounds of the BMP file's color table. 515 5169. Fixed a signed integer overflow in the progressive Huffman decoder, detected 517by the Clang and GCC undefined behavior sanitizers, that could be triggered by 518attempting to decompress a specially-crafted malformed JPEG image. This issue 519did not pose a security threat, but removing the warning made it easier to 520detect actual security issues, should they arise in the future. 521 522 5231.5.90 (2.0 beta1) 524================== 525 526### Significant changes relative to 1.5.3: 527 5281. Added AVX2 SIMD implementations of the colorspace conversion, chroma 529downsampling and upsampling, integer quantization and sample conversion, and 530accurate integer DCT/IDCT algorithms. When using the accurate integer DCT/IDCT 531algorithms on AVX2-equipped CPUs, the compression of RGB images is 532approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x) with 53364-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the 534decompression of RGB images is approximately 9-35% (avg. 17%) faster with 53564-bit code and 7-17% (avg. 12%) faster with 32-bit code. (As tested on a 5363 GHz Intel Core i7. Actual mileage may vary.) 537 5382. Overhauled the build system to use CMake on all platforms, and removed the 539autotools-based build system. This decision resulted from extensive 540discussions within the libjpeg-turbo community. libjpeg-turbo traditionally 541used CMake only for Windows builds, but there was an increasing amount of 542demand to extend CMake support to other platforms. However, because of the 543unique nature of our code base (the need to support different assemblers on 544each platform, the need for Java support, etc.), providing dual build systems 545as other OSS imaging libraries do (including libpng and libtiff) would have 546created a maintenance burden. The use of CMake greatly simplifies some aspects 547of our build system, owing to CMake's built-in support for various assemblers, 548Java, and unit testing, as well as generally fewer quirks that have to be 549worked around in order to implement our packaging system. Eliminating 550autotools puts our project slightly at odds with the traditional practices of 551the OSS community, since most "system libraries" tend to be built with 552autotools, but it is believed that the benefits of this move outweigh the 553risks. In addition to providing a unified build environment, switching to 554CMake allows for the use of various build tools and IDEs that aren't supported 555under autotools, including XCode, Ninja, and Eclipse. It also eliminates the 556need to install autotools via MacPorts/Homebrew on OS X and allows 557libjpeg-turbo to be configured without the use of a terminal/command prompt. 558Extensive testing was conducted to ensure that all features provided by the 559autotools-based build system are provided by the new build system. 560 5613. The libjpeg API in this version of libjpeg-turbo now includes two additional 562functions, `jpeg_read_icc_profile()` and `jpeg_write_icc_profile()`, that can 563be used to extract ICC profile data from a JPEG file while decompressing or to 564embed ICC profile data in a JPEG file while compressing or transforming. This 565eliminates the need for downstream projects, such as color management libraries 566and browsers, to include their own glueware for accomplishing this. 567 5684. Improved error handling in the TurboJPEG API library: 569 570 - Introduced a new function (`tjGetErrorStr2()`) in the TurboJPEG C API 571that allows compression/decompression/transform error messages to be retrieved 572in a thread-safe manner. Retrieving error messages from global functions, such 573as `tjInitCompress()` or `tjBufSize()`, is still thread-unsafe, but since those 574functions will only throw errors if passed an invalid argument or if a memory 575allocation failure occurs, thread safety is not as much of a concern. 576 - Introduced a new function (`tjGetErrorCode()`) in the TurboJPEG C API 577and a new method (`TJException.getErrorCode()`) in the TurboJPEG Java API that 578can be used to determine the severity of the last 579compression/decompression/transform error. This allows applications to 580choose whether to ignore warnings (non-fatal errors) from the underlying 581libjpeg API or to treat them as fatal. 582 - Introduced a new flag (`TJFLAG_STOPONWARNING` in the TurboJPEG C API and 583`TJ.FLAG_STOPONWARNING` in the TurboJPEG Java API) that causes the library to 584immediately halt a compression/decompression/transform operation if it 585encounters a warning from the underlying libjpeg API (the default behavior is 586to allow the operation to complete unless a fatal error is encountered.) 587 5885. Introduced a new flag in the TurboJPEG C and Java APIs (`TJFLAG_PROGRESSIVE` 589and `TJ.FLAG_PROGRESSIVE`, respectively) that causes the library to use 590progressive entropy coding in JPEG images generated by compression and 591transform operations. Additionally, a new transform option 592(`TJXOPT_PROGRESSIVE` in the C API and `TJTransform.OPT_PROGRESSIVE` in the 593Java API) has been introduced, allowing progressive entropy coding to be 594enabled for selected transforms in a multi-transform operation. 595 5966. Introduced a new transform option in the TurboJPEG API (`TJXOPT_COPYNONE` in 597the C API and `TJTransform.OPT_COPYNONE` in the Java API) that allows the 598copying of markers (including EXIF and ICC profile data) to be disabled for a 599particular transform. 600 6017. Added two functions to the TurboJPEG C API (`tjLoadImage()` and 602`tjSaveImage()`) that can be used to load/save a BMP or PPM/PGM image to/from a 603memory buffer with a specified pixel format and layout. These functions 604replace the project-private (and slow) bmp API, which was previously used by 605TJBench, and they also provide a convenient way for first-time users of 606libjpeg-turbo to quickly develop a complete JPEG compression/decompression 607program. 608 6098. The TurboJPEG C API now includes a new convenience array (`tjAlphaOffset[]`) 610that contains the alpha component index for each pixel format (or -1 if the 611pixel format lacks an alpha component.) The TurboJPEG Java API now includes a 612new method (`TJ.getAlphaOffset()`) that returns the same value. In addition, 613the `tjRedOffset[]`, `tjGreenOffset[]`, and `tjBlueOffset[]` arrays-- and the 614corresponding `TJ.getRedOffset()`, `TJ.getGreenOffset()`, and 615`TJ.getBlueOffset()` methods-- now return -1 for `TJPF_GRAY`/`TJ.PF_GRAY` 616rather than 0. This allows programs to easily determine whether a pixel format 617has red, green, blue, and alpha components. 618 6199. Added a new example (tjexample.c) that demonstrates the basic usage of the 620TurboJPEG C API. This example mirrors the functionality of TJExample.java. 621Both files are now included in the libjpeg-turbo documentation. 622 62310. Fixed two signed integer overflows in the arithmetic decoder, detected by 624the Clang undefined behavior sanitizer, that could be triggered by attempting 625to decompress a specially-crafted malformed JPEG image. These issues did not 626pose a security threat, but removing the warnings makes it easier to detect 627actual security issues, should they arise in the future. 628 62911. Fixed a bug in the merged 4:2:0 upsampling/dithered RGB565 color conversion 630algorithm that caused incorrect dithering in the output image. This algorithm 631now produces bitwise-identical results to the unmerged algorithms. 632 63312. The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64] (if 634libjpeg-turbo is built with YASM), and iOS/Arm[64] builds are now private. 635This prevents those symbols from being exposed in applications or shared 636libraries that link statically with libjpeg-turbo. 637 63813. Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and 639YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy 640chroma upsampling, integer quantization, and accurate integer DCT/IDCT 641algorithms. When using the accurate integer DCT/IDCT, this speeds up the 642compression of RGB images by approximately 70-100% and the decompression of RGB 643images by approximately 2-3.5x. 644 64514. Fixed a build error when building with older MinGW releases (regression 646caused by 1.5.1[7].) 647 64815. Added SIMD acceleration for progressive Huffman encoding on SSE2-capable 649x86 and x86-64 platforms. This speeds up the compression of full-color 650progressive JPEGs by about 85-90% on average (relative to libjpeg-turbo 1.5.x) 651when using modern Intel and AMD CPUs. 652 653 6541.5.3 655===== 656 657### Significant changes relative to 1.5.2: 658 6591. Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred 660when using the YUVImage constructor that creates an instance backed by separate 661image planes and allocates memory for the image planes. 662 6632. Fixed an issue whereby the Java version of TJUnitTest would fail when 664testing BufferedImage encoding/decoding on big endian systems. 665 6663. Fixed a segfault in djpeg that would occur if an output format other than 667PPM/PGM was selected along with the `-crop` option. The `-crop` option now 668works with the GIF and Targa formats as well (unfortunately, it cannot be made 669to work with the BMP and RLE formats due to the fact that those output engines 670write scanlines in bottom-up order.) djpeg will now exit gracefully if an 671output format other than PPM/PGM, GIF, or Targa is selected along with the 672`-crop` option. 673 6744. Fixed an issue (CVE-2017-15232) whereby `jpeg_skip_scanlines()` would 675segfault if color quantization was enabled. 676 6775. TJBench (both C and Java versions) will now display usage information if any 678command-line argument is unrecognized. This prevents the program from silently 679ignoring typos. 680 6816. Fixed an access violation in tjbench.exe (Windows) that occurred when the 682program was used to decompress an existing JPEG image. 683 6847. Fixed an ArrayIndexOutOfBoundsException in the TJExample Java program that 685occurred when attempting to decompress a JPEG image that had been compressed 686with 4:1:1 chrominance subsampling. 687 6888. Fixed an issue whereby, when using `jpeg_skip_scanlines()` to skip to the 689end of a single-scan (non-progressive) image, subsequent calls to 690`jpeg_consume_input()` would return `JPEG_SUSPENDED` rather than 691`JPEG_REACHED_EOI`. 692 6939. `jpeg_crop_scanline()` now works correctly when decompressing grayscale JPEG 694images that were compressed with a sampling factor other than 1 (for instance, 695with `cjpeg -grayscale -sample 2x2`). 696 697 6981.5.2 699===== 700 701### Significant changes relative to 1.5.1: 702 7031. Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from 704building with Android NDK platforms prior to android-21 (5.0). 705 7062. Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD 707code in libjpeg-turbo from building. 708 7093. Fixed a regression introduced by 1.5 beta1[11] that prevented the Java 710version of TJBench from outputting any reference images (the `-nowrite` switch 711was accidentally enabled by default.) 712 7134. libjpeg-turbo should now build and run with full AltiVec SIMD acceleration 714on PowerPC-based AmigaOS 4 and OpenBSD systems. 715 7165. Fixed build and runtime errors on Windows that occurred when building 717libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory 718source/destination managers. Due to an oversight, the `jpeg_skip_scanlines()` 719and `jpeg_crop_scanline()` functions were not being included in jpeg7.dll when 720libjpeg-turbo was built with `-DWITH_JPEG7=1` and `-DWITH_MEMSRCDST=1`. 721 7226. Fixed "Bogus virtual array access" error that occurred when using the 723lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was 724built with libjpeg v7 API/ABI emulation. This was apparently a long-standing 725bug that has existed since the introduction of libjpeg v7/v8 API/ABI emulation 726in libjpeg-turbo v1.1. 727 7287. The lossless transform features in jpegtran and the TurboJPEG API will now 729always attempt to adjust the EXIF image width and height tags if the image size 730changed as a result of the transform. This behavior has always existed when 731using libjpeg v8 API/ABI emulation. It was supposed to be available with 732libjpeg v7 API/ABI emulation as well but did not work properly due to a bug. 733Furthermore, there was never any good reason not to enable it with libjpeg v6b 734API/ABI emulation, since the behavior is entirely internal. Note that 735`-copy all` must be passed to jpegtran in order to transfer the EXIF tags from 736the source image to the destination image. 737 7388. Fixed several memory leaks in the TurboJPEG API library that could occur 739if the library was built with certain compilers and optimization levels 740(known to occur with GCC 4.x and clang with `-O1` and higher but not with 741GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error 742after a TurboJPEG API function allocated a local buffer. 743 7449. The libjpeg-turbo memory manager will now honor the `max_memory_to_use` 745structure member in jpeg\_memory\_mgr, which can be set to the maximum amount 746of memory (in bytes) that libjpeg-turbo should use during decompression or 747multi-pass (including progressive) compression. This limit can also be set 748using the `JPEGMEM` environment variable or using the `-maxmemory` switch in 749cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.) 750This has been a documented feature of libjpeg since v5, but the 751`malloc()`/`free()` implementation of the memory manager (jmemnobs.c) never 752implemented the feature. Restricting libjpeg-turbo's memory usage is useful 753for two reasons: it allows testers to more easily work around the 2 GB limit 754in libFuzzer, and it allows developers of security-sensitive applications to 755more easily defend against one of the progressive JPEG exploits (LJT-01-004) 756identified in 757[this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf). 758 75910. TJBench will now run each benchmark for 1 second prior to starting the 760timer, in order to improve the consistency of the results. Furthermore, the 761`-warmup` option is now used to specify the amount of warmup time rather than 762the number of warmup iterations. 763 76411. Fixed an error (`short jump is out of range`) that occurred when assembling 765the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a 766regression introduced by 1.5 beta1[12]. 767 768 7691.5.1 770===== 771 772### Significant changes relative to 1.5.0: 773 7741. Previously, the undocumented `JSIMD_FORCE*` environment variables could be 775used to force-enable a particular SIMD instruction set if multiple instruction 776sets were available on a particular platform. On x86 platforms, where CPU 777feature detection is bulletproof and multiple SIMD instruction sets are 778available, it makes sense for those environment variables to allow forcing the 779use of an instruction set only if that instruction set is available. However, 780since the ARM implementations of libjpeg-turbo can only use one SIMD 781instruction set, and since their feature detection code is less bulletproof 782(parsing /proc/cpuinfo), it makes sense for the `JSIMD_FORCENEON` environment 783variable to bypass the feature detection code and really force the use of NEON 784instructions. A new environment variable (`JSIMD_FORCEDSPR2`) was introduced 785in the MIPS implementation for the same reasons, and the existing 786`JSIMD_FORCENONE` environment variable was extended to that implementation. 787These environment variables provide a workaround for those attempting to test 788ARM and MIPS builds of libjpeg-turbo in QEMU, which passes through 789/proc/cpuinfo from the host system. 790 7912. libjpeg-turbo previously assumed that AltiVec instructions were always 792available on PowerPC platforms, which led to "illegal instruction" errors when 793running on PowerPC chips that lack AltiVec support (such as the older 7xx/G3 794and newer e5500 series.) libjpeg-turbo now examines /proc/cpuinfo on 795Linux/Android systems and enables AltiVec instructions only if the CPU supports 796them. It also now provides two environment variables, `JSIMD_FORCEALTIVEC` and 797`JSIMD_FORCENONE`, to force-enable and force-disable AltiVec instructions in 798environments where /proc/cpuinfo is an unreliable means of CPU feature 799detection (such as when running in QEMU.) On OS X, libjpeg-turbo continues to 800assume that AltiVec support is always available, which means that libjpeg-turbo 801cannot be used with G3 Macs unless you set the environment variable 802`JSIMD_FORCENONE` to `1`. 803 8043. Fixed an issue whereby 64-bit ARM (AArch64) builds of libjpeg-turbo would 805crash when built with recent releases of the Clang/LLVM compiler. This was 806caused by an ABI conformance issue in some of libjpeg-turbo's 64-bit NEON SIMD 807routines. Those routines were incorrectly using 64-bit instructions to 808transfer a 32-bit JDIMENSION argument, whereas the ABI allows the upper 809(unused) 32 bits of a 32-bit argument's register to be undefined. The new 810Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit 811structure members into a single 64-bit register, and this exposed the ABI 812conformance issue. 813 8144. Fancy upsampling is now supported when decompressing JPEG images that use 8154:4:0 (h1v2) chroma subsampling. These images are generated when losslessly 816rotating or transposing JPEG images that use 4:2:2 (h2v1) chroma subsampling. 817The h1v2 fancy upsampling algorithm is not currently SIMD-accelerated. 818 8195. If merged upsampling isn't SIMD-accelerated but YCbCr-to-RGB conversion is, 820then libjpeg-turbo will now disable merged upsampling when decompressing YCbCr 821JPEG images into RGB or extended RGB output images. This significantly speeds 822up the decompression of 4:2:0 and 4:2:2 JPEGs on ARM platforms if fancy 823upsampling is not used (for example, if the `-nosmooth` option to djpeg is 824specified.) 825 8266. The TurboJPEG API will now decompress 4:2:2 and 4:4:0 JPEG images with 8272x2 luminance sampling factors and 2x1 or 1x2 chrominance sampling factors. 828This is a non-standard way of specifying 2x subsampling (normally 4:2:2 JPEGs 829have 2x1 luminance and 1x1 chrominance sampling factors, and 4:4:0 JPEGs have 8301x2 luminance and 1x1 chrominance sampling factors), but the JPEG format and 831the libjpeg API both allow it. 832 8337. Fixed an unsigned integer overflow in the libjpeg memory manager, detected 834by the Clang undefined behavior sanitizer, that could be triggered by 835attempting to decompress a specially-crafted malformed JPEG image. This issue 836affected only 32-bit code and did not pose a security threat, but removing the 837warning makes it easier to detect actual security issues, should they arise in 838the future. 839 8408. Fixed additional negative left shifts and other issues reported by the GCC 841and Clang undefined behavior sanitizers when attempting to decompress 842specially-crafted malformed JPEG images. None of these issues posed a security 843threat, but removing the warnings makes it easier to detect actual security 844issues, should they arise in the future. 845 8469. Fixed an out-of-bounds array reference, introduced by 1.4.90[2] (partial 847image decompression) and detected by the Clang undefined behavior sanitizer, 848that could be triggered by a specially-crafted malformed JPEG image with more 849than four components. Because the out-of-bounds reference was still within the 850same structure, it was not known to pose a security threat, but removing the 851warning makes it easier to detect actual security issues, should they arise in 852the future. 853 85410. Fixed another ABI conformance issue in the 64-bit ARM (AArch64) NEON SIMD 855code. Some of the routines were incorrectly reading and storing data below the 856stack pointer, which caused segfaults in certain applications under specific 857circumstances. 858 859 8601.5.0 861===== 862 863### Significant changes relative to 1.5 beta1: 864 8651. Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast 866path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory. 867 8682. Added libjpeg-turbo version and build information to the global string table 869of the libjpeg and TurboJPEG API libraries. This is a common practice in other 870infrastructure libraries, such as OpenSSL and libpng, because it makes it easy 871to examine an application binary and determine which version of the library the 872application was linked against. 873 8743. Fixed a couple of issues in the PPM reader that would cause buffer overruns 875in cjpeg if one of the values in a binary PPM/PGM input file exceeded the 876maximum value defined in the file's header and that maximum value was greater 877than 255. libjpeg-turbo 1.4.2 already included a similar fix for ASCII PPM/PGM 878files. Note that these issues were not security bugs, since they were confined 879to the cjpeg program and did not affect any of the libjpeg-turbo libraries. 880 8814. Fixed an issue whereby attempting to decompress a JPEG file with a corrupt 882header using the `tjDecompressToYUV2()` function would cause the function to 883abort without returning an error and, under certain circumstances, corrupt the 884stack. This only occurred if `tjDecompressToYUV2()` was called prior to 885calling `tjDecompressHeader3()`, or if the return value from 886`tjDecompressHeader3()` was ignored (both cases represent incorrect usage of 887the TurboJPEG API.) 888 8895. Fixed an issue in the ARM 32-bit SIMD-accelerated Huffman encoder that 890prevented the code from assembling properly with clang. 891 8926. The `jpeg_stdio_src()`, `jpeg_mem_src()`, `jpeg_stdio_dest()`, and 893`jpeg_mem_dest()` functions in the libjpeg API will now throw an error if a 894source/destination manager has already been assigned to the compress or 895decompress object by a different function or by the calling program. This 896prevents these functions from attempting to reuse a source/destination manager 897structure that was allocated elsewhere, because there is no way to ensure that 898it would be big enough to accommodate the new source/destination manager. 899 900 9011.4.90 (1.5 beta1) 902================== 903 904### Significant changes relative to 1.4.2: 905 9061. Added full SIMD acceleration for PowerPC platforms using AltiVec VMX 907(128-bit SIMD) instructions. Although the performance of libjpeg-turbo on 908PowerPC was already good, due to the increased number of registers available 909to the compiler vs. x86, it was still possible to speed up compression by about 9103-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the 911use of AltiVec instructions. 912 9132. Added two new libjpeg API functions (`jpeg_skip_scanlines()` and 914`jpeg_crop_scanline()`) that can be used to partially decode a JPEG image. See 915[libjpeg.txt](libjpeg.txt) for more details. 916 9173. The TJCompressor and TJDecompressor classes in the TurboJPEG Java API now 918implement the Closeable interface, so those classes can be used with a 919try-with-resources statement. 920 9214. The TurboJPEG Java classes now throw unchecked idiomatic exceptions 922(IllegalArgumentException, IllegalStateException) for unrecoverable errors 923caused by incorrect API usage, and those classes throw a new checked exception 924type (TJException) for errors that are passed through from the C library. 925 9265. Source buffers for the TurboJPEG C API functions, as well as the 927`jpeg_mem_src()` function in the libjpeg API, are now declared as const 928pointers. This facilitates passing read-only buffers to those functions and 929ensures the caller that the source buffer will not be modified. This should 930not create any backward API or ABI incompatibilities with prior libjpeg-turbo 931releases. 932 9336. The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1 934FPUs. 935 9367. Fixed additional negative left shifts and other issues reported by the GCC 937and Clang undefined behavior sanitizers. Most of these issues affected only 93832-bit code, and none of them was known to pose a security threat, but removing 939the warnings makes it easier to detect actual security issues, should they 940arise in the future. 941 9428. Removed the unnecessary `.arch` directive from the ARM64 NEON SIMD code. 943This directive was preventing the code from assembling using the clang 944integrated assembler. 945 9469. Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit 947libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora 948distributions. This was due to the addition of a macro in jconfig.h that 949allows the Huffman codec to determine the word size at compile time. Since 950that macro differs between 32-bit and 64-bit builds, this caused a conflict 951between the i386 and x86_64 RPMs (any differing files, other than executables, 952are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.) 953Since the macro is used only internally, it has been moved into jconfigint.h. 954 95510. The x86-64 SIMD code can now be disabled at run time by setting the 956`JSIMD_FORCENONE` environment variable to `1` (the other SIMD implementations 957already had this capability.) 958 95911. Added a new command-line argument to TJBench (`-nowrite`) that prevents the 960benchmark from outputting any images. This removes any potential operating 961system overhead that might be caused by lazy writes to disk and thus improves 962the consistency of the performance measurements. 963 96412. Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and x86-64 965platforms. This speeds up the compression of full-color JPEGs by about 10-15% 966on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and AMD 967CPUs. Additionally, this works around an issue in the clang optimizer that 968prevents it (as of this writing) from achieving the same performance as GCC 969when compiling the C version of the Huffman encoder 970(<https://llvm.org/bugs/show_bug.cgi?id=16035>). For the purposes of 971benchmarking or regression testing, SIMD-accelerated Huffman encoding can be 972disabled by setting the `JSIMD_NOHUFFENC` environment variable to `1`. 973 97413. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used 975compression algorithms (including the accurate integer forward DCT and h2v2 & 976h2v1 downsampling algorithms, which are not accelerated in the 32-bit NEON 977implementation.) This speeds up the compression of full-color JPEGs by about 97875% on average on a Cavium ThunderX processor and by about 2-2.5x on average on 979Cortex-A53 and Cortex-A57 cores. 980 98114. Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit 982and 64-bit platforms. 983 984 For 32-bit code, this speeds up the compression of full-color JPEGs by 985about 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by 986about 6-7% on average on a typical Android device (Nexus 5X, Cortex-A53 and 987Cortex-A57), relative to libjpeg-turbo 1.4.x. Note that the larger speedup 988under iOS is due to the fact that iOS builds use LLVM, which does not optimize 989the C Huffman encoder as well as GCC does. 990 991 For 64-bit code, NEON-accelerated Huffman encoding speeds up the 992compression of full-color JPEGs by about 40% on average on a typical iOS device 993(iPhone 5S, Apple A7) and by about 7-8% on average on a typical Android device 994(Nexus 5X, Cortex-A53 and Cortex-A57), in addition to the speedup described in 995[13] above. 996 997 For the purposes of benchmarking or regression testing, SIMD-accelerated 998Huffman encoding can be disabled by setting the `JSIMD_NOHUFFENC` environment 999variable to `1`. 1000 100115. pkg-config (.pc) scripts are now included for both the libjpeg and 1002TurboJPEG API libraries on Un*x systems. Note that if a project's build system 1003relies on these scripts, then it will not be possible to build that project 1004with libjpeg or with a prior version of libjpeg-turbo. 1005 100616. Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to 1007improve performance on CPUs with in-order pipelines. This speeds up the 1008decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX 1009processor and by about 15% on average on a Cortex-A53 core. 1010 101117. Fixed an issue in the accelerated Huffman decoder that could have caused 1012the decoder to read past the end of the input buffer when a malformed, 1013specially-crafted JPEG image was being decompressed. In prior versions of 1014libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only 1015if there were > 128 bytes of data in the input buffer. However, it is possible 1016to construct a JPEG image in which a single Huffman block is over 430 bytes 1017long, so this version of libjpeg-turbo activates the accelerated Huffman 1018decoder only if there are > 512 bytes of data in the input buffer. 1019 102018. Fixed a memory leak in tjunittest encountered when running the program 1021with the `-yuv` option. 1022 1023 10241.4.2 1025===== 1026 1027### Significant changes relative to 1.4.1: 1028 10291. Fixed an issue whereby cjpeg would segfault if a Windows bitmap with a 1030negative width or height was used as an input image (Windows bitmaps can have 1031a negative height if they are stored in top-down order, but such files are 1032rare and not supported by libjpeg-turbo.) 1033 10342. Fixed an issue whereby, under certain circumstances, libjpeg-turbo would 1035incorrectly encode certain JPEG images when quality=100 and the fast integer 1036forward DCT were used. This was known to cause `make test` to fail when the 1037library was built with `-march=haswell` on x86 systems. 1038 10393. Fixed an issue whereby libjpeg-turbo would crash when built with the latest 1040& greatest development version of the Clang/LLVM compiler. This was caused by 1041an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD 1042routines. Those routines were incorrectly using a 64-bit `mov` instruction to 1043transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper 1044(unused) 32 bits of a 32-bit argument's register to be undefined. The new 1045Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit 1046structure members into a single 64-bit register, and this exposed the ABI 1047conformance issue. 1048 10494. Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged) 1050upsampling routine that caused a buffer overflow (and subsequent segfault) when 1051decompressing a 4:2:0 JPEG image whose scaled output width was less than 16 1052pixels. The "plain" upsampling routines are normally only used when 1053decompressing a non-YCbCr JPEG image, but they are also used when decompressing 1054a JPEG image whose scaled output height is 1. 1055 10565. Fixed various negative left shifts and other issues reported by the GCC and 1057Clang undefined behavior sanitizers. None of these was known to pose a 1058security threat, but removing the warnings makes it easier to detect actual 1059security issues, should they arise in the future. 1060 1061 10621.4.1 1063===== 1064 1065### Significant changes relative to 1.4.0: 1066 10671. tjbench now properly handles CMYK/YCCK JPEG files. Passing an argument of 1068`-cmyk` (instead of, for instance, `-rgb`) will cause tjbench to internally 1069convert the source bitmap to CMYK prior to compression, to generate YCCK JPEG 1070files, and to internally convert the decompressed CMYK pixels back to RGB after 1071decompression (the latter is done automatically if a CMYK or YCCK JPEG is 1072passed to tjbench as a source image.) The CMYK<->RGB conversion operation is 1073not benchmarked. NOTE: The quick & dirty CMYK<->RGB conversions that tjbench 1074uses are suitable for testing only. Proper conversion between CMYK and RGB 1075requires a color management system. 1076 10772. `make test` now performs additional bitwise regression tests using tjbench, 1078mainly for the purpose of testing compression from/decompression to a subregion 1079of a larger image buffer. 1080 10813. `make test` no longer tests the regression of the floating point DCT/IDCT 1082by default, since the results of those tests can vary if the algorithms in 1083question are not implemented using SIMD instructions on a particular platform. 1084See the comments in [Makefile.am](Makefile.am) for information on how to 1085re-enable the tests and to specify an expected result for them based on the 1086particulars of your platform. 1087 10884. The NULL color conversion routines have been significantly optimized, 1089which speeds up the compression of RGB and CMYK JPEGs by 5-20% when using 109064-bit code and 0-3% when using 32-bit code, and the decompression of those 1091images by 10-30% when using 64-bit code and 3-12% when using 32-bit code. 1092 10935. Fixed an "illegal instruction" error that occurred when djpeg from a 1094SIMD-enabled libjpeg-turbo MIPS build was executed with the `-nosmooth` option 1095on a MIPS machine that lacked DSPr2 support. The MIPS SIMD routines for h2v1 1096and h2v2 merged upsampling were not properly checking for the existence of 1097DSPr2. 1098 10996. Performance has been improved significantly on 64-bit non-Linux and 1100non-Windows platforms (generally 10-20% faster compression and 5-10% faster 1101decompression.) Due to an oversight, the 64-bit version of the accelerated 1102Huffman codec was not being compiled in when libjpeg-turbo was built on 1103platforms other than Windows or Linux. Oops. 1104 11057. Fixed an extremely rare bug in the Huffman encoder that caused 64-bit 1106builds of libjpeg-turbo to incorrectly encode a few specific test images when 1107quality=98, an optimized Huffman table, and the accurate integer forward DCT 1108were used. 1109 11108. The Windows (CMake) build system now supports building only static or only 1111shared libraries. This is accomplished by adding either `-DENABLE_STATIC=0` or 1112`-DENABLE_SHARED=0` to the CMake command line. 1113 11149. TurboJPEG API functions will now return an error code if a warning is 1115triggered in the underlying libjpeg API. For instance, if a JPEG file is 1116corrupt, the TurboJPEG decompression functions will attempt to decompress 1117as much of the image as possible, but those functions will now return -1 to 1118indicate that the decompression was not entirely successful. 1119 112010. Fixed a bug in the MIPS DSPr2 4:2:2 fancy upsampling routine that caused a 1121buffer overflow (and subsequent segfault) when decompressing a 4:2:2 JPEG image 1122in which the right-most MCU was 5 or 6 pixels wide. 1123 1124 11251.4.0 1126===== 1127 1128### Significant changes relative to 1.4 beta1: 1129 11301. Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build 1131because OS X does not provide the `le32toh()` and `htole32()` functions.) 1132 11332. The non-SIMD RGB565 color conversion code did not work correctly on big 1134endian machines. This has been fixed. 1135 11363. Fixed an issue in `tjPlaneSizeYUV()` whereby it would erroneously return 1 1137instead of -1 if `componentID` was > 0 and `subsamp` was `TJSAMP_GRAY`. 1138 11393. Fixed an issue in `tjBufSizeYUV2()` whereby it would erroneously return 0 1140instead of -1 if `width` was < 1. 1141 11425. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting 1143on ARM64 platforms (see 1.4 beta1[5].) 1144 11456. The `close()` method in the TJCompressor and TJDecompressor Java classes is 1146now idempotent. Previously, that method would call the native `tjDestroy()` 1147function even if the TurboJPEG instance had already been destroyed. This 1148caused an exception to be thrown during finalization, if the `close()` method 1149had already been called. The exception was caught, but it was still an 1150expensive operation. 1151 11527. The TurboJPEG API previously generated an error (`Could not determine 1153subsampling type for JPEG image`) when attempting to decompress grayscale JPEG 1154images that were compressed with a sampling factor other than 1 (for instance, 1155with `cjpeg -grayscale -sample 2x2`). Subsampling technically has no meaning 1156with grayscale JPEGs, and thus the horizontal and vertical sampling factors 1157for such images are ignored by the decompressor. However, the TurboJPEG API 1158was being too rigid and was expecting the sampling factors to be equal to 1 1159before it treated the image as a grayscale JPEG. 1160 11618. cjpeg, djpeg, and jpegtran now accept an argument of `-version`, which will 1162print the library version and exit. 1163 11649. Referring to 1.4 beta1[15], another extremely rare circumstance was 1165discovered under which the Huffman encoder's local buffer can be overrun 1166when a buffered destination manager is being used and an 1167extremely-high-frequency block (basically junk image data) is being encoded. 1168Even though the Huffman local buffer was increased from 128 bytes to 136 bytes 1169to address the previous issue, the new issue caused even the larger buffer to 1170be overrun. Further analysis reveals that, in the absolute worst case (such as 1171setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning 1172order), the Huffman encoder can produce encoded blocks that approach double the 1173size of the unencoded blocks. Thus, the Huffman local buffer was increased to 1174256 bytes, which should prevent any such issue from re-occurring in the future. 1175 117610. The new `tjPlaneSizeYUV()`, `tjPlaneWidth()`, and `tjPlaneHeight()` 1177functions were not actually usable on any platform except OS X and Windows, 1178because those functions were not included in the libturbojpeg mapfile. This 1179has been fixed. 1180 118111. Restored the `JPP()`, `JMETHOD()`, and `FAR` macros in the libjpeg-turbo 1182header files. The `JPP()` and `JMETHOD()` macros were originally implemented 1183in libjpeg as a way of supporting non-ANSI compilers that lacked support for 1184prototype parameters. libjpeg-turbo has never supported such compilers, but 1185some software packages still use the macros to define their own prototypes. 1186Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that 1187have far symbols, but some software packages still use the `FAR` macro. A 1188pretty good argument can be made that this is a bad practice on the part of the 1189software in question, but since this affects more than one package, it's just 1190easier to fix it here. 1191 119212. Fixed issues that were preventing the ARM 64-bit SIMD code from compiling 1193for iOS, and included an ARMv8 architecture in all of the binaries installed by 1194the "official" libjpeg-turbo SDK for OS X. 1195 1196 11971.3.90 (1.4 beta1) 1198================== 1199 1200### Significant changes relative to 1.3.1: 1201 12021. New features in the TurboJPEG API: 1203 1204 - YUV planar images can now be generated with an arbitrary line padding 1205(previously only 4-byte padding, which was compatible with X Video, was 1206supported.) 1207 - The decompress-to-YUV function has been extended to support image 1208scaling. 1209 - JPEG images can now be compressed from YUV planar source images. 1210 - YUV planar images can now be decoded into RGB or grayscale images. 1211 - 4:1:1 subsampling is now supported. This is mainly included for 1212compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no 1213significant advantages relative to 4:2:0. 1214 - CMYK images are now supported. This feature allows CMYK source images 1215to be compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to 1216CMYK destination images. Conversion between CMYK/YCCK and RGB or YUV images is 1217not supported. Such conversion requires a color management system and is thus 1218out of scope for a codec library. 1219 - The handling of YUV images in the Java API has been significantly 1220refactored and should now be much more intuitive. 1221 - The Java API now supports encoding a YUV image from an arbitrary 1222position in a large image buffer. 1223 - All of the YUV functions now have a corresponding function that operates 1224on separate image planes instead of a unified image buffer. This allows for 1225compressing/decoding from or decompressing/encoding to a subregion of a larger 1226YUV image. It also allows for handling YUV formats that swap the order of the 1227U and V planes. 1228 12292. Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up 1230the compression of full-color JPEGs by 70-80% on such platforms and 1231decompression by 25-35%. 1232 12333. If an application attempts to decompress a Huffman-coded JPEG image whose 1234header does not contain Huffman tables, libjpeg-turbo will now insert the 1235default Huffman tables. In order to save space, many motion JPEG video frames 1236are encoded without the default Huffman tables, so these frames can now be 1237successfully decompressed by libjpeg-turbo without additional work on the part 1238of the application. An application can still override the Huffman tables, for 1239instance to re-use tables from a previous frame of the same video. 1240 12414. The Mac packaging system now uses pkgbuild and productbuild rather than 1242PackageMaker (which is obsolete and no longer supported.) This means that 1243OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo, 1244although the packages produced can be installed on OS X 10.5 "Leopard" or 1245later. OS X 10.4 "Tiger" is no longer supported. 1246 12475. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting 1248on ARM platforms rather than a lookup table. This reduces the memory footprint 1249by 64k, which may be important for some mobile applications. Out of four 1250Android devices that were tested, two demonstrated a small overall performance 1251loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with 1252ARMv7 code when enabling this new feature, but the other two devices 1253demonstrated a significant overall performance gain with both ARMv6 and ARMv7 1254code (~10-20%) when enabling the feature. Actual mileage may vary. 1255 12566. Worked around an issue with Visual C++ 2010 and later that caused incorrect 1257pixels to be generated when decompressing a JPEG image to a 256-color bitmap, 1258if compiler optimization was enabled when libjpeg-turbo was built. This caused 1259the regression tests to fail when doing a release build under Visual C++ 2010 1260and later. 1261 12627. Improved the accuracy and performance of the non-SIMD implementation of the 1263floating point inverse DCT (using code borrowed from libjpeg v8a and later.) 1264The accuracy of this implementation now matches the accuracy of the SSE/SSE2 1265implementation. Note, however, that the floating point DCT/IDCT algorithms are 1266mainly a legacy feature. They generally do not produce significantly better 1267accuracy than the accurate integer DCT/IDCT algorithms, and they are quite a 1268bit slower. 1269 12708. Added a new output colorspace (`JCS_RGB565`) to the libjpeg API that allows 1271for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not 1272used, then this code path is SIMD-accelerated on ARM platforms. 1273 12749. Numerous obsolete features, such as support for non-ANSI compilers and 1275support for the MS-DOS memory model, were removed from the libjpeg code, 1276greatly improving its readability and making it easier to maintain and extend. 1277 127810. Fixed a segfault that occurred when calling `output_message()` with 1279`msg_code` set to `JMSG_COPYRIGHT`. 1280 128111. Fixed an issue whereby wrjpgcom was allowing comments longer than 65k 1282characters to be passed on the command line, which was causing it to generate 1283incorrect JPEG files. 1284 128512. Fixed a bug in the build system that was causing the Windows version of 1286wrjpgcom to be built using the rdjpgcom source code. 1287 128813. Restored 12-bit-per-component JPEG support. A 12-bit version of 1289libjpeg-turbo can now be built by passing an argument of `--with-12bit` to 1290configure (Unix) or `-DWITH_12BIT=1` to cmake (Windows.) 12-bit JPEG support 1291is included only for convenience. Enabling this feature disables all of the 1292performance features in libjpeg-turbo, as well as arithmetic coding and the 1293TurboJPEG API. The resulting library still contains the other libjpeg-turbo 1294features (such as the colorspace extensions), but in general, it performs no 1295faster than libjpeg v6b. 1296 129714. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion 1298and IDCT algorithms (both are used during JPEG decompression.) For unknown 1299reasons (probably related to clang), this code cannot currently be compiled for 1300iOS. 1301 130215. Fixed an extremely rare bug (CVE-2014-9092) that could cause the Huffman 1303encoder's local buffer to overrun when a very high-frequency MCU is compressed 1304using quality 100 and no subsampling, and when the JPEG output buffer is being 1305dynamically resized by the destination manager. This issue was so rare that, 1306even with a test program specifically designed to make the bug occur (by 1307injecting random high-frequency YUV data into the compressor), it was 1308reproducible only once in about every 25 million iterations. 1309 131016. Fixed an oversight in the TurboJPEG C wrapper: if any of the JPEG 1311compression functions was called repeatedly with the same 1312automatically-allocated destination buffer, then TurboJPEG would erroneously 1313assume that the `jpegSize` parameter was equal to the size of the buffer, when 1314in fact that parameter was probably equal to the size of the most recently 1315compressed JPEG image. If the size of the previous JPEG image was not as large 1316as the current JPEG image, then TurboJPEG would unnecessarily reallocate the 1317destination buffer. 1318 1319 13201.3.1 1321===== 1322 1323### Significant changes relative to 1.3.0: 1324 13251. On Un*x systems, `make install` now installs the libjpeg-turbo libraries 1326into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86, 1327and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just 1328x86-64. You can override this by overriding either the `prefix` or `libdir` 1329configure variables. 1330 13312. The Windows installer now places a copy of the TurboJPEG DLLs in the same 1332directory as the rest of the libjpeg-turbo binaries. This was mainly done 1333to support TurboVNC 1.3, which bundles the DLLs in its Windows installation. 1334When using a 32-bit version of CMake on 64-bit Windows, it is impossible to 1335access the c:\WINDOWS\system32 directory, which made it impossible for the 1336TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL. 1337 13383. Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic 1339entropy coding (by passing arguments of `-progressive -arithmetic` to cjpeg or 1340jpegtran, for instance) would result in an error, `Requested feature was 1341omitted at compile time`. 1342 13434. Fixed a couple of issues (CVE-2013-6629 and CVE-2013-6630) whereby malformed 1344JPEG images would cause libjpeg-turbo to use uninitialized memory during 1345decompression. 1346 13475. Fixed an error (`Buffer passed to JPEG library is too small`) that occurred 1348when calling the TurboJPEG YUV encoding function with a very small (< 5x5) 1349source image, and added a unit test to check for this error. 1350 13516. The Java classes should now build properly under Visual Studio 2010 and 1352later. 1353 13547. Fixed an issue that prevented SRPMs generated using the in-tree packaging 1355tools from being rebuilt on certain newer Linux distributions. 1356 13578. Numerous minor fixes to eliminate compilation and build/packaging system 1358warnings, fix cosmetic issues, improve documentation clarity, and other general 1359source cleanup. 1360 1361 13621.3.0 1363===== 1364 1365### Significant changes relative to 1.3 beta1: 1366 13671. `make test` now works properly on FreeBSD, and it no longer requires the 1368md5sum executable to be present on other Un*x platforms. 1369 13702. Overhauled the packaging system: 1371 1372 - To avoid conflict with vendor-supplied libjpeg-turbo packages, the 1373official RPMs and DEBs for libjpeg-turbo have been renamed to 1374"libjpeg-turbo-official". 1375 - The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the 1376official Linux and Mac packages, to avoid conflict with vendor-supplied 1377packages and also to streamline the packaging system. 1378 - Release packages are now created with the directory structure defined 1379by the configure variables `prefix`, `bindir`, `libdir`, etc. (Un\*x) or by the 1380`CMAKE_INSTALL_PREFIX` variable (Windows.) The exception is that the docs are 1381always located under the system default documentation directory on Un\*x and 1382Mac systems, and on Windows, the TurboJPEG DLL is always located in the Windows 1383system directory. 1384 - To avoid confusion, official libjpeg-turbo packages on Linux/Unix 1385platforms (except for Mac) will always install the 32-bit libraries in 1386/opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64. 1387 - Fixed an issue whereby, in some cases, the libjpeg-turbo executables on 1388Un*x systems were not properly linking with the shared libraries installed by 1389the same package. 1390 - Fixed an issue whereby building the "installer" target on Windows when 1391`WITH_JAVA=1` would fail if the TurboJPEG JAR had not been previously built. 1392 - Building the "install" target on Windows now installs files into the 1393same places that the installer does. 1394 13953. Fixed a Huffman encoder bug that prevented I/O suspension from working 1396properly. 1397 1398 13991.2.90 (1.3 beta1) 1400================== 1401 1402### Significant changes relative to 1.2.1: 1403 14041. Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4, 140511/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing. Note that the IDCT will 1406not be SIMD-accelerated when using any of these new scaling factors. 1407 14082. The TurboJPEG dynamic library is now versioned. It was not strictly 1409necessary to do so, because TurboJPEG uses versioned symbols, and if a function 1410changes in an ABI-incompatible way, that function is renamed and a legacy 1411function is provided to maintain backward compatibility. However, certain 1412Linux distro maintainers have a policy against accepting any library that isn't 1413versioned. 1414 14153. Extended the TurboJPEG Java API so that it can be used to compress a JPEG 1416image from and decompress a JPEG image to an arbitrary position in a large 1417image buffer. 1418 14194. The `tjDecompressToYUV()` function now supports the `TJFLAG_FASTDCT` flag. 1420 14215. The 32-bit supplementary package for amd64 Debian systems now provides 1422symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32. 1423This allows those libraries to be used on MultiArch-compatible systems (such as 1424Ubuntu 11 and later) without setting the linker path. 1425 14266. The TurboJPEG Java wrapper should now find the JNI library on Mac systems 1427without having to pass `-Djava.library.path=/usr/lib` to java. 1428 14297. TJBench has been ported to Java to provide a convenient way of validating 1430the performance of the TurboJPEG Java API. It can be run with 1431`java -cp turbojpeg.jar TJBench`. 1432 14338. cjpeg can now be used to generate JPEG files with the RGB colorspace 1434(feature ported from jpeg-8d.) 1435 14369. The width and height in the `-crop` argument passed to jpegtran can now be 1437suffixed with `f` to indicate that, when the upper left corner of the cropping 1438region is automatically moved to the nearest iMCU boundary, the bottom right 1439corner should be moved by the same amount. In other words, this feature causes 1440jpegtran to strictly honor the specified width/height rather than the specified 1441bottom right corner (feature ported from jpeg-8d.) 1442 144310. JPEG files using the RGB colorspace can now be decompressed into grayscale 1444images (feature ported from jpeg-8d.) 1445 144611. Fixed a regression caused by 1.2.1[7] whereby the build would fail with 1447multiple "Mismatch in operand sizes" errors when attempting to build the x86 1448SIMD code with NASM 0.98. 1449 145012. The in-memory source/destination managers (`jpeg_mem_src()` and 1451`jpeg_mem_dest()`) are now included by default when building libjpeg-turbo with 1452libjpeg v6b or v7 emulation, so that programs can take advantage of these 1453functions without requiring the use of the backward-incompatible libjpeg v8 1454ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been 1455incremented by 1 to reflect this. You can disable this feature with a 1456configure/CMake switch in order to retain strict API/ABI compatibility with the 1457libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See 1458[README.md](README.md) for more details. 1459 146013. Added ARMv7s architecture to libjpeg.a and libturbojpeg.a in the official 1461libjpeg-turbo binary package for OS X, so that those libraries can be used to 1462build applications that leverage the faster CPUs in the iPhone 5 and iPad 4. 1463 1464 14651.2.1 1466===== 1467 1468### Significant changes relative to 1.2.0: 1469 14701. Creating or decoding a JPEG file that uses the RGB colorspace should now 1471properly work when the input or output colorspace is one of the libjpeg-turbo 1472colorspace extensions. 1473 14742. When libjpeg-turbo was built without SIMD support and merged (non-fancy) 1475upsampling was used along with an alpha-enabled colorspace during 1476decompression, the unused byte of the decompressed pixels was not being set to 14770xFF. This has been fixed. TJUnitTest has also been extended to test for the 1478correct behavior of the colorspace extensions when merged upsampling is used. 1479 14803. Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the 1481upper 64 bits of xmm6 and xmm7 on Win64 platforms, which violated the Win64 1482calling conventions. 1483 14844. Fixed a regression (CVE-2012-2806) caused by 1.2.0[6] whereby decompressing 1485corrupt JPEG images (specifically, images in which the component count was 1486erroneously set to a large value) would cause libjpeg-turbo to segfault. 1487 14885. Worked around a severe performance issue with "Bobcat" (AMD Embedded APU) 1489processors. The `MASKMOVDQU` instruction, which was used by the libjpeg-turbo 1490SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and 1491it is painfully slow on Bobcat processors in particular. Eliminating the use 1492of this instruction improved performance by an order of magnitude on Bobcat 1493processors and by a small amount (typically 5%) on AMD desktop processors. 1494 14956. Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM 1496platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such 1497platforms. 1498 14997. Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms 1500running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or 15014:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy 1502upsampling would produce several incorrect columns of pixels at the right-hand 1503side of the output image if each row in the output image was not evenly 1504divisible by 16 bytes. 1505 15068. Fixed an issue whereby attempting to build the SIMD extensions with Xcode 15074.3 on OS X platforms would cause NASM to return numerous errors of the form 1508"'%define' expects a macro identifier". 1509 15109. Added flags to the TurboJPEG API that allow the caller to force the use of 1511either the fast or the accurate DCT/IDCT algorithms in the underlying codec. 1512 1513 15141.2.0 1515===== 1516 1517### Significant changes relative to 1.2 beta1: 1518 15191. Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system 1520was not adding the current directory to the assembler include path, so YASM 1521was not able to find jsimdcfg.inc.) 1522 15232. Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing 1524a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes. 1525This was more of an annoyance than an actual bug, since it did not cause any 1526actual run-time problems, but the issue showed up when running libjpeg-turbo in 1527valgrind. See <http://crbug.com/72399> for more information. 1528 15293. Added a compile-time macro (`LIBJPEG_TURBO_VERSION`) that can be used to 1530check the version of libjpeg-turbo against which an application was compiled. 1531 15324. Added new RGBA/BGRA/ABGR/ARGB colorspace extension constants (libjpeg API) 1533and pixel formats (TurboJPEG API), which allow applications to specify that, 1534when decompressing to a 4-component RGB buffer, the unused byte should be set 1535to 0xFF so that it can be interpreted as an opaque alpha channel. 1536 15375. Fixed regression issue whereby DevIL failed to build against libjpeg-turbo 1538because libjpeg-turbo's distributed version of jconfig.h contained an `INLINE` 1539macro, which conflicted with a similar macro in DevIL. This macro is used only 1540internally when building libjpeg-turbo, so it was moved into config.h. 1541 15426. libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose 1543K component is assigned a component ID of 1 instead of 4. Although these files 1544are in violation of the spec, other JPEG implementations handle them 1545correctly. 1546 15477. Added ARMv6 and ARMv7 architectures to libjpeg.a and libturbojpeg.a in 1548the official libjpeg-turbo binary package for OS X, so that those libraries can 1549be used to build both OS X and iOS applications. 1550 1551 15521.1.90 (1.2 beta1) 1553================== 1554 1555### Significant changes relative to 1.1.1: 1556 15571. Added a Java wrapper for the TurboJPEG API. See [java/README](java/README) 1558for more details. 1559 15602. The TurboJPEG API can now be used to scale down images during 1561decompression. 1562 15633. Added SIMD routines for RGB-to-grayscale color conversion, which 1564significantly improves the performance of grayscale JPEG compression from an 1565RGB source image. 1566 15674. Improved the performance of the C color conversion routines, which are used 1568on platforms for which SIMD acceleration is not available. 1569 15705. Added a function to the TurboJPEG API that performs lossless transforms. 1571This function is implemented using the same back end as jpegtran, but it 1572performs transcoding entirely in memory and allows multiple transforms and/or 1573crop operations to be batched together, so the source coefficients only need to 1574be read once. This is useful when generating image tiles from a single source 1575JPEG. 1576 15776. Added tests for the new TurboJPEG scaled decompression and lossless 1578transform features to tjbench (the TurboJPEG benchmark, formerly called 1579"jpgtest".) 1580 15817. Added support for 4:4:0 (transposed 4:2:2) subsampling in TurboJPEG, which 1582was necessary in order for it to read 4:2:2 JPEG files that had been losslessly 1583transposed or rotated 90 degrees. 1584 15858. All legacy VirtualGL code has been re-factored, and this has allowed 1586libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license. 1587 15889. libjpeg-turbo can now be built with YASM. 1589 159010. Added SIMD acceleration for ARM Linux and iOS platforms that support 1591NEON instructions. 1592 159311. Refactored the TurboJPEG C API and documented it using Doxygen. The 1594TurboJPEG 1.2 API uses pixel formats to define the size and component order of 1595the uncompressed source/destination images, and it includes a more efficient 1596version of `TJBUFSIZE()` that computes a worst-case JPEG size based on the 1597level of chrominance subsampling. The refactored implementation of the 1598TurboJPEG API now uses the libjpeg memory source and destination managers, 1599which allows the TurboJPEG compressor to grow the JPEG buffer as necessary. 1600 160112. Eliminated errors in the output of jpegtran on Windows that occurred when 1602the application was invoked using I/O redirection 1603(`jpegtran <input.jpg >output.jpg`.) 1604 160513. The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding 1606support in libjpeg-turbo v1.1.0 introduced several new error constants in 1607jerror.h, and these were mistakenly enabled for all emulation modes, causing 1608the error enum in libjpeg-turbo to sometimes have different values than the 1609same enum in libjpeg. This represents an ABI incompatibility, and it caused 1610problems with rare applications that took specific action based on a particular 1611error value. The fix was to include the new error constants conditionally 1612based on whether libjpeg v7 or v8 emulation was enabled. 1613 161414. Fixed an issue whereby Windows applications that used libjpeg-turbo would 1615fail to compile if the Windows system headers were included before jpeglib.h. 1616This issue was caused by a conflict in the definition of the INT32 type. 1617 161815. Fixed 32-bit supplementary package for amd64 Debian systems, which was 1619broken by enhancements to the packaging system in 1.1. 1620 162116. When decompressing a JPEG image using an output colorspace of 1622`JCS_EXT_RGBX`, `JCS_EXT_BGRX`, `JCS_EXT_XBGR`, or `JCS_EXT_XRGB`, 1623libjpeg-turbo will now set the unused byte to 0xFF, which allows applications 1624to interpret that byte as an alpha channel (0xFF = opaque). 1625 1626 16271.1.1 1628===== 1629 1630### Significant changes relative to 1.1.0: 1631 16321. Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated 1633by `tjEncodeYUV()`. 1634 16352. libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected 1636markers found in the middle of the JPEG data stream during decompression. It 1637will now hand off decoding of a particular block to the unaccelerated Huffman 1638decoder if an unexpected marker is found, so that the unaccelerated Huffman 1639decoder can generate an appropriate warning. 1640 16413. Older versions of MinGW64 prefixed symbol names with underscores by 1642default, which differed from the behavior of 64-bit Visual C++. MinGW64 1.0 1643has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate 1644this, the libjpeg-turbo SIMD function names are no longer prefixed with an 1645underscore when building with MinGW64. This means that, when building 1646libjpeg-turbo with older versions of MinGW64, you will now have to add 1647`-fno-leading-underscore` to the `CFLAGS`. 1648 16494. Fixed a regression bug in the NSIS script that caused the Windows installer 1650build to fail when using the Visual Studio IDE. 1651 16525. Fixed a bug in `jpeg_read_coefficients()` whereby it would not initialize 1653`cinfo->image_width` and `cinfo->image_height` if libjpeg v7 or v8 emulation 1654was enabled. This specifically caused the jpegoptim program to fail if it was 1655linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8 1656emulation. 1657 16586. Eliminated excessive I/O overhead that occurred when reading BMP files in 1659cjpeg. 1660 16617. Eliminated errors in the output of cjpeg on Windows that occurred when the 1662application was invoked using I/O redirection (`cjpeg <inputfile >output.jpg`.) 1663 1664 16651.1.0 1666===== 1667 1668### Significant changes relative to 1.1 beta1: 1669 16701. The algorithm used by the SIMD quantization function cannot produce correct 1671results when the JPEG quality is >= 98 and the fast integer forward DCT is 1672used. Thus, the non-SIMD quantization function is now used for those cases, 1673and libjpeg-turbo should now produce identical output to libjpeg v6b in all 1674cases. 1675 16762. Despite the above, the fast integer forward DCT still degrades somewhat for 1677JPEG qualities greater than 95, so the TurboJPEG wrapper will now automatically 1678use the accurate integer forward DCT when generating JPEG images of quality 96 1679or greater. This reduces compression performance by as much as 15% for these 1680high-quality images but is necessary to ensure that the images are perceptually 1681lossless. It also ensures that the library can avoid the performance pitfall 1682created by [1]. 1683 16843. Ported jpgtest.cxx to pure C to avoid the need for a C++ compiler. 1685 16864. Fixed visual artifacts in grayscale JPEG compression caused by a typo in 1687the RGB-to-luminance lookup tables. 1688 16895. The Windows distribution packages now include the libjpeg run-time programs 1690(cjpeg, etc.) 1691 16926. All packages now include jpgtest. 1693 16947. The TurboJPEG dynamic library now uses versioned symbols. 1695 16968. Added two new TurboJPEG API functions, `tjEncodeYUV()` and 1697`tjDecompressToYUV()`, to replace the somewhat hackish `TJ_YUV` flag. 1698 1699 17001.0.90 (1.1 beta1) 1701================== 1702 1703### Significant changes relative to 1.0.1: 1704 17051. Added emulation of the libjpeg v7 and v8 APIs and ABIs. See 1706[README.md](README.md) for more details. This feature was sponsored by 1707CamTrace SAS. 1708 17092. Created a new CMake-based build system for the Visual C++ and MinGW builds. 1710 17113. Grayscale bitmaps can now be compressed from/decompressed to using the 1712TurboJPEG API. 1713 17144. jpgtest can now be used to test decompression performance with existing 1715JPEG images. 1716 17175. If the default install prefix (/opt/libjpeg-turbo) is used, then 1718`make install` now creates /opt/libjpeg-turbo/lib32 and 1719/opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary 1720packages. 1721 17226. All symbols in the libjpeg-turbo dynamic library are now versioned, even 1723when the library is built with libjpeg v6b emulation. 1724 17257. Added arithmetic encoding and decoding support (can be disabled with 1726configure or CMake options) 1727 17288. Added a `TJ_YUV` flag to the TurboJPEG API, which causes both the compressor 1729and decompressor to output planar YUV images. 1730 17319. Added an extended version of `tjDecompressHeader()` to the TurboJPEG API, 1732which allows the caller to determine the type of subsampling used in a JPEG 1733image. 1734 173510. Added further protections against invalid Huffman codes. 1736 1737 17381.0.1 1739===== 1740 1741### Significant changes relative to 1.0.0: 1742 17431. The Huffman decoder will now handle erroneous Huffman codes (for instance, 1744from a corrupt JPEG image.) Previously, these would cause libjpeg-turbo to 1745crash under certain circumstances. 1746 17472. Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to 1748be used instead of 4:2:0 when decompressing JPEG images using SSE2 code. 1749 17503. The configure script will now automatically determine whether the 1751`INCOMPLETE_TYPES_BROKEN` macro should be defined. 1752 1753 17541.0.0 1755===== 1756 1757### Significant changes relative to 0.0.93: 1758 17591. 2983700: Further FreeBSD build tweaks (no longer necessary to specify 1760`--host` when configuring on a 64-bit system) 1761 17622. Created symlinks in the Unix/Linux packages so that the TurboJPEG 1763include file can always be found in /opt/libjpeg-turbo/include, the 32-bit 1764static libraries can always be found in /opt/libjpeg-turbo/lib32, and the 176564-bit static libraries can always be found in /opt/libjpeg-turbo/lib64. 1766 17673. The Unix/Linux distribution packages now include the libjpeg run-time 1768programs (cjpeg, etc.) and man pages. 1769 17704. Created a 32-bit supplementary package for amd64 Debian systems, which 1771contains just the 32-bit libjpeg-turbo libraries. 1772 17735. Moved the libraries from */lib32 to */lib in the i386 Debian package. 1774 17756. Include distribution package for Cygwin 1776 17777. No longer necessary to specify `--without-simd` on non-x86 architectures, 1778and unit tests now work on those architectures. 1779 1780 17810.0.93 1782====== 1783 1784### Significant changes since 0.0.91: 1785 17861. 2982659: Fixed x86-64 build on FreeBSD systems 1787 17882. 2988188: Added support for Windows 64-bit systems 1789 1790 17910.0.91 1792====== 1793 1794### Significant changes relative to 0.0.90: 1795 17961. Added documentation to .deb packages 1797 17982. 2968313: Fixed data corruption issues when decompressing large JPEG images 1799and/or using buffered I/O with the libjpeg-turbo decompressor 1800 1801 18020.0.90 1803====== 1804 1805Initial release 1806