11.5.3 2===== 3 4### Significant changes relative to 1.5.2: 5 61. Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred 7when using the YUVImage constructor that creates an instance backed by separate 8image planes and allocates memory for the image planes. 9 102. Fixed an issue whereby the Java version of TJUnitTest would fail when 11testing BufferedImage encoding/decoding on big endian systems. 12 133. Fixed a segfault in djpeg that would occur if an output format other than 14PPM/PGM was selected along with the `-crop` option. The `-crop` option now 15works with the GIF and Targa formats as well (unfortunately, it cannot be made 16to work with the BMP and RLE formats due to the fact that those output engines 17write scanlines in bottom-up order.) djpeg will now exit gracefully if an 18output format other than PPM/PGM, GIF, or Targa is selected along with the 19`-crop` option. 20 214. Fixed an issue whereby `jpeg_skip_scanlines()` would segfault if color 22quantization was enabled. 23 245. TJBench (both C and Java versions) will now display usage information if any 25command-line argument is unrecognized. This prevents the program from silently 26ignoring typos. 27 286. Fixed an access violation in tjbench.exe (Windows) that occurred when the 29program was used to decompress an existing JPEG image. 30 317. Fixed an ArrayIndexOutOfBoundsException in the TJExample Java program that 32occurred when attempting to decompress a JPEG image that had been compressed 33with 4:1:1 chrominance subsampling. 34 358. Fixed an issue whereby, when using `jpeg_skip_scanlines()` to skip to the 36end of a single-scan (non-progressive) image, subsequent calls to 37`jpeg_consume_input()` would return `JPEG_SUSPENDED` rather than 38`JPEG_REACHED_EOI`. 39 409. `jpeg_crop_scanlines()` now works correctly when decompressing grayscale 41JPEG images that were compressed with a sampling factor other than 1 (for 42instance, with `cjpeg -grayscale -sample 2x2`). 43 44 451.5.2 46===== 47 48### Significant changes relative to 1.5.1: 49 501. Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from 51building with Android NDK platforms prior to android-21 (5.0). 52 532. Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD 54code in libjpeg-turbo from building. 55 563. Fixed a regression introduced by 1.5 beta1[11] that prevented the Java 57version of TJBench from outputting any reference images (the `-nowrite` switch 58was accidentally enabled by default.) 59 604. libjpeg-turbo should now build and run with full AltiVec SIMD acceleration 61on PowerPC-based AmigaOS 4 and OpenBSD systems. 62 635. Fixed build and runtime errors on Windows that occurred when building 64libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory 65source/destination managers. Due to an oversight, the `jpeg_skip_scanlines()` 66and `jpeg_crop_scanlines()` functions were not being included in jpeg7.dll when 67libjpeg-turbo was built with `-DWITH_JPEG7=1` and `-DWITH_MEMSRCDST=1`. 68 696. Fixed "Bogus virtual array access" error that occurred when using the 70lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was 71built with libjpeg v7 API/ABI emulation. This was apparently a long-standing 72bug that has existed since the introduction of libjpeg v7/v8 API/ABI emulation 73in libjpeg-turbo v1.1. 74 757. The lossless transform features in jpegtran and the TurboJPEG API will now 76always attempt to adjust the EXIF image width and height tags if the image size 77changed as a result of the transform. This behavior has always existed when 78using libjpeg v8 API/ABI emulation. It was supposed to be available with 79libjpeg v7 API/ABI emulation as well but did not work properly due to a bug. 80Furthermore, there was never any good reason not to enable it with libjpeg v6b 81API/ABI emulation, since the behavior is entirely internal. Note that 82`-copy all` must be passed to jpegtran in order to transfer the EXIF tags from 83the source image to the destination image. 84 858. Fixed several memory leaks in the TurboJPEG API library that could occur 86if the library was built with certain compilers and optimization levels 87(known to occur with GCC 4.x and clang with `-O1` and higher but not with 88GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error 89after a TurboJPEG API function allocated a local buffer. 90 919. The libjpeg-turbo memory manager will now honor the `max_memory_to_use` 92structure member in jpeg\_memory\_mgr, which can be set to the maximum amount 93of memory (in bytes) that libjpeg-turbo should use during decompression or 94multi-pass (including progressive) compression. This limit can also be set 95using the `JPEGMEM` environment variable or using the `-maxmemory` switch in 96cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.) 97This has been a documented feature of libjpeg since v5, but the 98`malloc()`/`free()` implementation of the memory manager (jmemnobs.c) never 99implemented the feature. Restricting libjpeg-turbo's memory usage is useful 100for two reasons: it allows testers to more easily work around the 2 GB limit 101in libFuzzer, and it allows developers of security-sensitive applications to 102more easily defend against one of the progressive JPEG exploits (LJT-01-004) 103identified in 104[this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf). 105 10610. TJBench will now run each benchmark for 1 second prior to starting the 107timer, in order to improve the consistency of the results. Furthermore, the 108`-warmup` option is now used to specify the amount of warmup time rather than 109the number of warmup iterations. 110 11111. Fixed an error (`short jump is out of range`) that occurred when assembling 112the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a 113regression introduced by 1.5 beta1[12]. 114 115 1161.5.1 117===== 118 119### Significant changes relative to 1.5.0: 120 1211. Previously, the undocumented `JSIMD_FORCE*` environment variables could be 122used to force-enable a particular SIMD instruction set if multiple instruction 123sets were available on a particular platform. On x86 platforms, where CPU 124feature detection is bulletproof and multiple SIMD instruction sets are 125available, it makes sense for those environment variables to allow forcing the 126use of an instruction set only if that instruction set is available. However, 127since the ARM implementations of libjpeg-turbo can only use one SIMD 128instruction set, and since their feature detection code is less bulletproof 129(parsing /proc/cpuinfo), it makes sense for the `JSIMD_FORCENEON` environment 130variable to bypass the feature detection code and really force the use of NEON 131instructions. A new environment variable (`JSIMD_FORCEDSPR2`) was introduced 132in the MIPS implementation for the same reasons, and the existing 133`JSIMD_FORCENONE` environment variable was extended to that implementation. 134These environment variables provide a workaround for those attempting to test 135ARM and MIPS builds of libjpeg-turbo in QEMU, which passes through 136/proc/cpuinfo from the host system. 137 1382. libjpeg-turbo previously assumed that AltiVec instructions were always 139available on PowerPC platforms, which led to "illegal instruction" errors when 140running on PowerPC chips that lack AltiVec support (such as the older 7xx/G3 141and newer e5500 series.) libjpeg-turbo now examines /proc/cpuinfo on 142Linux/Android systems and enables AltiVec instructions only if the CPU supports 143them. It also now provides two environment variables, `JSIMD_FORCEALTIVEC` and 144`JSIMD_FORCENONE`, to force-enable and force-disable AltiVec instructions in 145environments where /proc/cpuinfo is an unreliable means of CPU feature 146detection (such as when running in QEMU.) On OS X, libjpeg-turbo continues to 147assume that AltiVec support is always available, which means that libjpeg-turbo 148cannot be used with G3 Macs unless you set the environment variable 149`JSIMD_FORCENONE` to `1`. 150 1513. Fixed an issue whereby 64-bit ARM (AArch64) builds of libjpeg-turbo would 152crash when built with recent releases of the Clang/LLVM compiler. This was 153caused by an ABI conformance issue in some of libjpeg-turbo's 64-bit NEON SIMD 154routines. Those routines were incorrectly using 64-bit instructions to 155transfer a 32-bit JDIMENSION argument, whereas the ABI allows the upper 156(unused) 32 bits of a 32-bit argument's register to be undefined. The new 157Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit 158structure members into a single 64-bit register, and this exposed the ABI 159conformance issue. 160 1614. Fancy upsampling is now supported when decompressing JPEG images that use 1624:4:0 (h1v2) chroma subsampling. These images are generated when losslessly 163rotating or transposing JPEG images that use 4:2:2 (h2v1) chroma subsampling. 164The h1v2 fancy upsampling algorithm is not currently SIMD-accelerated. 165 1665. If merged upsampling isn't SIMD-accelerated but YCbCr-to-RGB conversion is, 167then libjpeg-turbo will now disable merged upsampling when decompressing YCbCr 168JPEG images into RGB or extended RGB output images. This significantly speeds 169up the decompression of 4:2:0 and 4:2:2 JPEGs on ARM platforms if fancy 170upsampling is not used (for example, if the `-nosmooth` option to djpeg is 171specified.) 172 1736. The TurboJPEG API will now decompress 4:2:2 and 4:4:0 JPEG images with 1742x2 luminance sampling factors and 2x1 or 1x2 chrominance sampling factors. 175This is a non-standard way of specifying 2x subsampling (normally 4:2:2 JPEGs 176have 2x1 luminance and 1x1 chrominance sampling factors, and 4:4:0 JPEGs have 1771x2 luminance and 1x1 chrominance sampling factors), but the JPEG specification 178and the libjpeg API both allow it. 179 1807. Fixed an unsigned integer overflow in the libjpeg memory manager, detected 181by the Clang undefined behavior sanitizer, that could be triggered by 182attempting to decompress a specially-crafted malformed JPEG image. This issue 183affected only 32-bit code and did not pose a security threat, but removing the 184warning makes it easier to detect actual security issues, should they arise in 185the future. 186 1878. Fixed additional negative left shifts and other issues reported by the GCC 188and Clang undefined behavior sanitizers when attempting to decompress 189specially-crafted malformed JPEG images. None of these issues posed a security 190threat, but removing the warnings makes it easier to detect actual security 191issues, should they arise in the future. 192 1939. Fixed an out-of-bounds array reference, introduced by 1.4.90[2] (partial 194image decompression) and detected by the Clang undefined behavior sanitizer, 195that could be triggered by a specially-crafted malformed JPEG image with more 196than four components. Because the out-of-bounds reference was still within the 197same structure, it was not known to pose a security threat, but removing the 198warning makes it easier to detect actual security issues, should they arise in 199the future. 200 20110. Fixed another ABI conformance issue in the 64-bit ARM (AArch64) NEON SIMD 202code. Some of the routines were incorrectly reading and storing data below the 203stack pointer, which caused segfaults in certain applications under specific 204circumstances. 205 206 2071.5.0 208===== 209 210### Significant changes relative to 1.5 beta1: 211 2121. Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast 213path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory. 214 2152. Added libjpeg-turbo version and build information to the global string table 216of the libjpeg and TurboJPEG API libraries. This is a common practice in other 217infrastructure libraries, such as OpenSSL and libpng, because it makes it easy 218to examine an application binary and determine which version of the library the 219application was linked against. 220 2213. Fixed a couple of issues in the PPM reader that would cause buffer overruns 222in cjpeg if one of the values in a binary PPM/PGM input file exceeded the 223maximum value defined in the file's header. libjpeg-turbo 1.4.2 already 224included a similar fix for ASCII PPM/PGM files. Note that these issues were 225not security bugs, since they were confined to the cjpeg program and did not 226affect any of the libjpeg-turbo libraries. 227 2284. Fixed an issue whereby attempting to decompress a JPEG file with a corrupt 229header using the `tjDecompressToYUV2()` function would cause the function to 230abort without returning an error and, under certain circumstances, corrupt the 231stack. This only occurred if `tjDecompressToYUV2()` was called prior to 232calling `tjDecompressHeader3()`, or if the return value from 233`tjDecompressHeader3()` was ignored (both cases represent incorrect usage of 234the TurboJPEG API.) 235 2365. Fixed an issue in the ARM 32-bit SIMD-accelerated Huffman encoder that 237prevented the code from assembling properly with clang. 238 2396. The `jpeg_stdio_src()`, `jpeg_mem_src()`, `jpeg_stdio_dest()`, and 240`jpeg_mem_dest()` functions in the libjpeg API will now throw an error if a 241source/destination manager has already been assigned to the compress or 242decompress object by a different function or by the calling program. This 243prevents these functions from attempting to reuse a source/destination manager 244structure that was allocated elsewhere, because there is no way to ensure that 245it would be big enough to accommodate the new source/destination manager. 246 247 2481.4.90 (1.5 beta1) 249================== 250 251### Significant changes relative to 1.4.2: 252 2531. Added full SIMD acceleration for PowerPC platforms using AltiVec VMX 254(128-bit SIMD) instructions. Although the performance of libjpeg-turbo on 255PowerPC was already good, due to the increased number of registers available 256to the compiler vs. x86, it was still possible to speed up compression by about 2573-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the 258use of AltiVec instructions. 259 2602. Added two new libjpeg API functions (`jpeg_skip_scanlines()` and 261`jpeg_crop_scanline()`) that can be used to partially decode a JPEG image. See 262[libjpeg.txt](libjpeg.txt) for more details. 263 2643. The TJCompressor and TJDecompressor classes in the TurboJPEG Java API now 265implement the Closeable interface, so those classes can be used with a 266try-with-resources statement. 267 2684. The TurboJPEG Java classes now throw unchecked idiomatic exceptions 269(IllegalArgumentException, IllegalStateException) for unrecoverable errors 270caused by incorrect API usage, and those classes throw a new checked exception 271type (TJException) for errors that are passed through from the C library. 272 2735. Source buffers for the TurboJPEG C API functions, as well as the 274`jpeg_mem_src()` function in the libjpeg API, are now declared as const 275pointers. This facilitates passing read-only buffers to those functions and 276ensures the caller that the source buffer will not be modified. This should 277not create any backward API or ABI incompatibilities with prior libjpeg-turbo 278releases. 279 2806. The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1 281FPUs. 282 2837. Fixed additional negative left shifts and other issues reported by the GCC 284and Clang undefined behavior sanitizers. Most of these issues affected only 28532-bit code, and none of them was known to pose a security threat, but removing 286the warnings makes it easier to detect actual security issues, should they 287arise in the future. 288 2898. Removed the unnecessary `.arch` directive from the ARM64 NEON SIMD code. 290This directive was preventing the code from assembling using the clang 291integrated assembler. 292 2939. Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit 294libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora 295distributions. This was due to the addition of a macro in jconfig.h that 296allows the Huffman codec to determine the word size at compile time. Since 297that macro differs between 32-bit and 64-bit builds, this caused a conflict 298between the i386 and x86_64 RPMs (any differing files, other than executables, 299are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.) 300Since the macro is used only internally, it has been moved into jconfigint.h. 301 30210. The x86-64 SIMD code can now be disabled at run time by setting the 303`JSIMD_FORCENONE` environment variable to `1` (the other SIMD implementations 304already had this capability.) 305 30611. Added a new command-line argument to TJBench (`-nowrite`) that prevents the 307benchmark from outputting any images. This removes any potential operating 308system overhead that might be caused by lazy writes to disk and thus improves 309the consistency of the performance measurements. 310 31112. Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and x86-64 312platforms. This speeds up the compression of full-color JPEGs by about 10-15% 313on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and AMD 314CPUs. Additionally, this works around an issue in the clang optimizer that 315prevents it (as of this writing) from achieving the same performance as GCC 316when compiling the C version of the Huffman encoder 317(<https://llvm.org/bugs/show_bug.cgi?id=16035>). For the purposes of 318benchmarking or regression testing, SIMD-accelerated Huffman encoding can be 319disabled by setting the `JSIMD_NOHUFFENC` environment variable to `1`. 320 32113. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used 322compression algorithms (including the slow integer forward DCT and h2v2 & h2v1 323downsampling algorithms, which are not accelerated in the 32-bit NEON 324implementation.) This speeds up the compression of full-color JPEGs by about 32575% on average on a Cavium ThunderX processor and by about 2-2.5x on average on 326Cortex-A53 and Cortex-A57 cores. 327 32814. Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit 329and 64-bit platforms. 330 331 For 32-bit code, this speeds up the compression of full-color JPEGs by 332about 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by 333about 6-7% on average on a typical Android device (Nexus 5X, Cortex-A53 and 334Cortex-A57), relative to libjpeg-turbo 1.4.x. Note that the larger speedup 335under iOS is due to the fact that iOS builds use LLVM, which does not optimize 336the C Huffman encoder as well as GCC does. 337 338 For 64-bit code, NEON-accelerated Huffman encoding speeds up the 339compression of full-color JPEGs by about 40% on average on a typical iOS device 340(iPhone 5S, Apple A7) and by about 7-8% on average on a typical Android device 341(Nexus 5X, Cortex-A53 and Cortex-A57), in addition to the speedup described in 342[13] above. 343 344 For the purposes of benchmarking or regression testing, SIMD-accelerated 345Huffman encoding can be disabled by setting the `JSIMD_NOHUFFENC` environment 346variable to `1`. 347 34815. pkg-config (.pc) scripts are now included for both the libjpeg and 349TurboJPEG API libraries on Un*x systems. Note that if a project's build system 350relies on these scripts, then it will not be possible to build that project 351with libjpeg or with a prior version of libjpeg-turbo. 352 35316. Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to 354improve performance on CPUs with in-order pipelines. This speeds up the 355decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX 356processor and by about 15% on average on a Cortex-A53 core. 357 35817. Fixed an issue in the accelerated Huffman decoder that could have caused 359the decoder to read past the end of the input buffer when a malformed, 360specially-crafted JPEG image was being decompressed. In prior versions of 361libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only 362if there were > 128 bytes of data in the input buffer. However, it is possible 363to construct a JPEG image in which a single Huffman block is over 430 bytes 364long, so this version of libjpeg-turbo activates the accelerated Huffman 365decoder only if there are > 512 bytes of data in the input buffer. 366 36718. Fixed a memory leak in tjunittest encountered when running the program 368with the `-yuv` option. 369 370 3711.4.2 372===== 373 374### Significant changes relative to 1.4.1: 375 3761. Fixed an issue whereby cjpeg would segfault if a Windows bitmap with a 377negative width or height was used as an input image (Windows bitmaps can have 378a negative height if they are stored in top-down order, but such files are 379rare and not supported by libjpeg-turbo.) 380 3812. Fixed an issue whereby, under certain circumstances, libjpeg-turbo would 382incorrectly encode certain JPEG images when quality=100 and the fast integer 383forward DCT were used. This was known to cause `make test` to fail when the 384library was built with `-march=haswell` on x86 systems. 385 3863. Fixed an issue whereby libjpeg-turbo would crash when built with the latest 387& greatest development version of the Clang/LLVM compiler. This was caused by 388an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD 389routines. Those routines were incorrectly using a 64-bit `mov` instruction to 390transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper 391(unused) 32 bits of a 32-bit argument's register to be undefined. The new 392Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit 393structure members into a single 64-bit register, and this exposed the ABI 394conformance issue. 395 3964. Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged) 397upsampling routine that caused a buffer overflow (and subsequent segfault) when 398decompressing a 4:2:0 JPEG image whose scaled output width was less than 16 399pixels. The "plain" upsampling routines are normally only used when 400decompressing a non-YCbCr JPEG image, but they are also used when decompressing 401a JPEG image whose scaled output height is 1. 402 4035. Fixed various negative left shifts and other issues reported by the GCC and 404Clang undefined behavior sanitizers. None of these was known to pose a 405security threat, but removing the warnings makes it easier to detect actual 406security issues, should they arise in the future. 407 408 4091.4.1 410===== 411 412### Significant changes relative to 1.4.0: 413 4141. tjbench now properly handles CMYK/YCCK JPEG files. Passing an argument of 415`-cmyk` (instead of, for instance, `-rgb`) will cause tjbench to internally 416convert the source bitmap to CMYK prior to compression, to generate YCCK JPEG 417files, and to internally convert the decompressed CMYK pixels back to RGB after 418decompression (the latter is done automatically if a CMYK or YCCK JPEG is 419passed to tjbench as a source image.) The CMYK<->RGB conversion operation is 420not benchmarked. NOTE: The quick & dirty CMYK<->RGB conversions that tjbench 421uses are suitable for testing only. Proper conversion between CMYK and RGB 422requires a color management system. 423 4242. `make test` now performs additional bitwise regression tests using tjbench, 425mainly for the purpose of testing compression from/decompression to a subregion 426of a larger image buffer. 427 4283. `make test` no longer tests the regression of the floating point DCT/IDCT 429by default, since the results of those tests can vary if the algorithms in 430question are not implemented using SIMD instructions on a particular platform. 431See the comments in [Makefile.am](Makefile.am) for information on how to 432re-enable the tests and to specify an expected result for them based on the 433particulars of your platform. 434 4354. The NULL color conversion routines have been significantly optimized, 436which speeds up the compression of RGB and CMYK JPEGs by 5-20% when using 43764-bit code and 0-3% when using 32-bit code, and the decompression of those 438images by 10-30% when using 64-bit code and 3-12% when using 32-bit code. 439 4405. Fixed an "illegal instruction" error that occurred when djpeg from a 441SIMD-enabled libjpeg-turbo MIPS build was executed with the `-nosmooth` option 442on a MIPS machine that lacked DSPr2 support. The MIPS SIMD routines for h2v1 443and h2v2 merged upsampling were not properly checking for the existence of 444DSPr2. 445 4466. Performance has been improved significantly on 64-bit non-Linux and 447non-Windows platforms (generally 10-20% faster compression and 5-10% faster 448decompression.) Due to an oversight, the 64-bit version of the accelerated 449Huffman codec was not being compiled in when libjpeg-turbo was built on 450platforms other than Windows or Linux. Oops. 451 4527. Fixed an extremely rare bug in the Huffman encoder that caused 64-bit 453builds of libjpeg-turbo to incorrectly encode a few specific test images when 454quality=98, an optimized Huffman table, and the slow integer forward DCT were 455used. 456 4578. The Windows (CMake) build system now supports building only static or only 458shared libraries. This is accomplished by adding either `-DENABLE_STATIC=0` or 459`-DENABLE_SHARED=0` to the CMake command line. 460 4619. TurboJPEG API functions will now return an error code if a warning is 462triggered in the underlying libjpeg API. For instance, if a JPEG file is 463corrupt, the TurboJPEG decompression functions will attempt to decompress 464as much of the image as possible, but those functions will now return -1 to 465indicate that the decompression was not entirely successful. 466 46710. Fixed a bug in the MIPS DSPr2 4:2:2 fancy upsampling routine that caused a 468buffer overflow (and subsequent segfault) when decompressing a 4:2:2 JPEG image 469in which the right-most MCU was 5 or 6 pixels wide. 470 471 4721.4.0 473===== 474 475### Significant changes relative to 1.4 beta1: 476 4771. Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build 478because OS X does not provide the `le32toh()` and `htole32()` functions.) 479 4802. The non-SIMD RGB565 color conversion code did not work correctly on big 481endian machines. This has been fixed. 482 4833. Fixed an issue in `tjPlaneSizeYUV()` whereby it would erroneously return 1 484instead of -1 if `componentID` was > 0 and `subsamp` was `TJSAMP_GRAY`. 485 4863. Fixed an issue in `tjBufSizeYUV2()` whereby it would erroneously return 0 487instead of -1 if `width` was < 1. 488 4895. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting 490on ARM64 platforms (see 1.4 beta1[5].) 491 4926. The `close()` method in the TJCompressor and TJDecompressor Java classes is 493now idempotent. Previously, that method would call the native `tjDestroy()` 494function even if the TurboJPEG instance had already been destroyed. This 495caused an exception to be thrown during finalization, if the `close()` method 496had already been called. The exception was caught, but it was still an 497expensive operation. 498 4997. The TurboJPEG API previously generated an error (`Could not determine 500subsampling type for JPEG image`) when attempting to decompress grayscale JPEG 501images that were compressed with a sampling factor other than 1 (for instance, 502with `cjpeg -grayscale -sample 2x2`). Subsampling technically has no meaning 503with grayscale JPEGs, and thus the horizontal and vertical sampling factors 504for such images are ignored by the decompressor. However, the TurboJPEG API 505was being too rigid and was expecting the sampling factors to be equal to 1 506before it treated the image as a grayscale JPEG. 507 5088. cjpeg, djpeg, and jpegtran now accept an argument of `-version`, which will 509print the library version and exit. 510 5119. Referring to 1.4 beta1[15], another extremely rare circumstance was 512discovered under which the Huffman encoder's local buffer can be overrun 513when a buffered destination manager is being used and an 514extremely-high-frequency block (basically junk image data) is being encoded. 515Even though the Huffman local buffer was increased from 128 bytes to 136 bytes 516to address the previous issue, the new issue caused even the larger buffer to 517be overrun. Further analysis reveals that, in the absolute worst case (such as 518setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning 519order), the Huffman encoder can produce encoded blocks that approach double the 520size of the unencoded blocks. Thus, the Huffman local buffer was increased to 521256 bytes, which should prevent any such issue from re-occurring in the future. 522 52310. The new `tjPlaneSizeYUV()`, `tjPlaneWidth()`, and `tjPlaneHeight()` 524functions were not actually usable on any platform except OS X and Windows, 525because those functions were not included in the libturbojpeg mapfile. This 526has been fixed. 527 52811. Restored the `JPP()`, `JMETHOD()`, and `FAR` macros in the libjpeg-turbo 529header files. The `JPP()` and `JMETHOD()` macros were originally implemented 530in libjpeg as a way of supporting non-ANSI compilers that lacked support for 531prototype parameters. libjpeg-turbo has never supported such compilers, but 532some software packages still use the macros to define their own prototypes. 533Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that 534have far symbols, but some software packages still use the `FAR` macro. A 535pretty good argument can be made that this is a bad practice on the part of the 536software in question, but since this affects more than one package, it's just 537easier to fix it here. 538 53912. Fixed issues that were preventing the ARM 64-bit SIMD code from compiling 540for iOS, and included an ARMv8 architecture in all of the binaries installed by 541the "official" libjpeg-turbo SDK for OS X. 542 543 5441.3.90 (1.4 beta1) 545================== 546 547### Significant changes relative to 1.3.1: 548 5491. New features in the TurboJPEG API: 550 551 - YUV planar images can now be generated with an arbitrary line padding 552(previously only 4-byte padding, which was compatible with X Video, was 553supported.) 554 - The decompress-to-YUV function has been extended to support image 555scaling. 556 - JPEG images can now be compressed from YUV planar source images. 557 - YUV planar images can now be decoded into RGB or grayscale images. 558 - 4:1:1 subsampling is now supported. This is mainly included for 559compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no 560significant advantages relative to 4:2:0. 561 - CMYK images are now supported. This feature allows CMYK source images 562to be compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to 563CMYK destination images. Conversion between CMYK/YCCK and RGB or YUV images is 564not supported. Such conversion requires a color management system and is thus 565out of scope for a codec library. 566 - The handling of YUV images in the Java API has been significantly 567refactored and should now be much more intuitive. 568 - The Java API now supports encoding a YUV image from an arbitrary 569position in a large image buffer. 570 - All of the YUV functions now have a corresponding function that operates 571on separate image planes instead of a unified image buffer. This allows for 572compressing/decoding from or decompressing/encoding to a subregion of a larger 573YUV image. It also allows for handling YUV formats that swap the order of the 574U and V planes. 575 5762. Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up 577the compression of full-color JPEGs by 70-80% on such platforms and 578decompression by 25-35%. 579 5803. If an application attempts to decompress a Huffman-coded JPEG image whose 581header does not contain Huffman tables, libjpeg-turbo will now insert the 582default Huffman tables. In order to save space, many motion JPEG video frames 583are encoded without the default Huffman tables, so these frames can now be 584successfully decompressed by libjpeg-turbo without additional work on the part 585of the application. An application can still override the Huffman tables, for 586instance to re-use tables from a previous frame of the same video. 587 5884. The Mac packaging system now uses pkgbuild and productbuild rather than 589PackageMaker (which is obsolete and no longer supported.) This means that 590OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo, 591although the packages produced can be installed on OS X 10.5 "Leopard" or 592later. OS X 10.4 "Tiger" is no longer supported. 593 5945. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting 595on ARM platforms rather than a lookup table. This reduces the memory footprint 596by 64k, which may be important for some mobile applications. Out of four 597Android devices that were tested, two demonstrated a small overall performance 598loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with 599ARMv7 code when enabling this new feature, but the other two devices 600demonstrated a significant overall performance gain with both ARMv6 and ARMv7 601code (~10-20%) when enabling the feature. Actual mileage may vary. 602 6036. Worked around an issue with Visual C++ 2010 and later that caused incorrect 604pixels to be generated when decompressing a JPEG image to a 256-color bitmap, 605if compiler optimization was enabled when libjpeg-turbo was built. This caused 606the regression tests to fail when doing a release build under Visual C++ 2010 607and later. 608 6097. Improved the accuracy and performance of the non-SIMD implementation of the 610floating point inverse DCT (using code borrowed from libjpeg v8a and later.) 611The accuracy of this implementation now matches the accuracy of the SSE/SSE2 612implementation. Note, however, that the floating point DCT/IDCT algorithms are 613mainly a legacy feature. They generally do not produce significantly better 614accuracy than the slow integer DCT/IDCT algorithms, and they are quite a bit 615slower. 616 6178. Added a new output colorspace (`JCS_RGB565`) to the libjpeg API that allows 618for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not 619used, then this code path is SIMD-accelerated on ARM platforms. 620 6219. Numerous obsolete features, such as support for non-ANSI compilers and 622support for the MS-DOS memory model, were removed from the libjpeg code, 623greatly improving its readability and making it easier to maintain and extend. 624 62510. Fixed a segfault that occurred when calling `output_message()` with 626`msg_code` set to `JMSG_COPYRIGHT`. 627 62811. Fixed an issue whereby wrjpgcom was allowing comments longer than 65k 629characters to be passed on the command line, which was causing it to generate 630incorrect JPEG files. 631 63212. Fixed a bug in the build system that was causing the Windows version of 633wrjpgcom to be built using the rdjpgcom source code. 634 63513. Restored 12-bit-per-component JPEG support. A 12-bit version of 636libjpeg-turbo can now be built by passing an argument of `--with-12bit` to 637configure (Unix) or `-DWITH_12BIT=1` to cmake (Windows.) 12-bit JPEG support 638is included only for convenience. Enabling this feature disables all of the 639performance features in libjpeg-turbo, as well as arithmetic coding and the 640TurboJPEG API. The resulting library still contains the other libjpeg-turbo 641features (such as the colorspace extensions), but in general, it performs no 642faster than libjpeg v6b. 643 64414. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion 645and IDCT algorithms (both are used during JPEG decompression.) For unknown 646reasons (probably related to clang), this code cannot currently be compiled for 647iOS. 648 64915. Fixed an extremely rare bug that could cause the Huffman encoder's local 650buffer to overrun when a very high-frequency MCU is compressed using quality 651100 and no subsampling, and when the JPEG output buffer is being dynamically 652resized by the destination manager. This issue was so rare that, even with a 653test program specifically designed to make the bug occur (by injecting random 654high-frequency YUV data into the compressor), it was reproducible only once in 655about every 25 million iterations. 656 65716. Fixed an oversight in the TurboJPEG C wrapper: if any of the JPEG 658compression functions was called repeatedly with the same 659automatically-allocated destination buffer, then TurboJPEG would erroneously 660assume that the `jpegSize` parameter was equal to the size of the buffer, when 661in fact that parameter was probably equal to the size of the most recently 662compressed JPEG image. If the size of the previous JPEG image was not as large 663as the current JPEG image, then TurboJPEG would unnecessarily reallocate the 664destination buffer. 665 666 6671.3.1 668===== 669 670### Significant changes relative to 1.3.0: 671 6721. On Un*x systems, `make install` now installs the libjpeg-turbo libraries 673into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86, 674and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just 675x86-64. You can override this by overriding either the `prefix` or `libdir` 676configure variables. 677 6782. The Windows installer now places a copy of the TurboJPEG DLLs in the same 679directory as the rest of the libjpeg-turbo binaries. This was mainly done 680to support TurboVNC 1.3, which bundles the DLLs in its Windows installation. 681When using a 32-bit version of CMake on 64-bit Windows, it is impossible to 682access the c:\WINDOWS\system32 directory, which made it impossible for the 683TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL. 684 6853. Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic 686entropy coding (by passing arguments of `-progressive -arithmetic` to cjpeg or 687jpegtran, for instance) would result in an error, `Requested feature was 688omitted at compile time`. 689 6904. Fixed a couple of issues whereby malformed JPEG images would cause 691libjpeg-turbo to use uninitialized memory during decompression. 692 6935. Fixed an error (`Buffer passed to JPEG library is too small`) that occurred 694when calling the TurboJPEG YUV encoding function with a very small (< 5x5) 695source image, and added a unit test to check for this error. 696 6976. The Java classes should now build properly under Visual Studio 2010 and 698later. 699 7007. Fixed an issue that prevented SRPMs generated using the in-tree packaging 701tools from being rebuilt on certain newer Linux distributions. 702 7038. Numerous minor fixes to eliminate compilation and build/packaging system 704warnings, fix cosmetic issues, improve documentation clarity, and other general 705source cleanup. 706 707 7081.3.0 709===== 710 711### Significant changes relative to 1.3 beta1: 712 7131. `make test` now works properly on FreeBSD, and it no longer requires the 714md5sum executable to be present on other Un*x platforms. 715 7162. Overhauled the packaging system: 717 718 - To avoid conflict with vendor-supplied libjpeg-turbo packages, the 719official RPMs and DEBs for libjpeg-turbo have been renamed to 720"libjpeg-turbo-official". 721 - The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the 722official Linux and Mac packages, to avoid conflict with vendor-supplied 723packages and also to streamline the packaging system. 724 - Release packages are now created with the directory structure defined 725by the configure variables `prefix`, `bindir`, `libdir`, etc. (Un\*x) or by the 726`CMAKE_INSTALL_PREFIX` variable (Windows.) The exception is that the docs are 727always located under the system default documentation directory on Un\*x and 728Mac systems, and on Windows, the TurboJPEG DLL is always located in the Windows 729system directory. 730 - To avoid confusion, official libjpeg-turbo packages on Linux/Unix 731platforms (except for Mac) will always install the 32-bit libraries in 732/opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64. 733 - Fixed an issue whereby, in some cases, the libjpeg-turbo executables on 734Un*x systems were not properly linking with the shared libraries installed by 735the same package. 736 - Fixed an issue whereby building the "installer" target on Windows when 737`WITH_JAVA=1` would fail if the TurboJPEG JAR had not been previously built. 738 - Building the "install" target on Windows now installs files into the 739same places that the installer does. 740 7413. Fixed a Huffman encoder bug that prevented I/O suspension from working 742properly. 743 744 7451.2.90 (1.3 beta1) 746================== 747 748### Significant changes relative to 1.2.1: 749 7501. Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4, 75111/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing. Note that the IDCT will 752not be SIMD-accelerated when using any of these new scaling factors. 753 7542. The TurboJPEG dynamic library is now versioned. It was not strictly 755necessary to do so, because TurboJPEG uses versioned symbols, and if a function 756changes in an ABI-incompatible way, that function is renamed and a legacy 757function is provided to maintain backward compatibility. However, certain 758Linux distro maintainers have a policy against accepting any library that isn't 759versioned. 760 7613. Extended the TurboJPEG Java API so that it can be used to compress a JPEG 762image from and decompress a JPEG image to an arbitrary position in a large 763image buffer. 764 7654. The `tjDecompressToYUV()` function now supports the `TJFLAG_FASTDCT` flag. 766 7675. The 32-bit supplementary package for amd64 Debian systems now provides 768symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32. 769This allows those libraries to be used on MultiArch-compatible systems (such as 770Ubuntu 11 and later) without setting the linker path. 771 7726. The TurboJPEG Java wrapper should now find the JNI library on Mac systems 773without having to pass `-Djava.library.path=/usr/lib` to java. 774 7757. TJBench has been ported to Java to provide a convenient way of validating 776the performance of the TurboJPEG Java API. It can be run with 777`java -cp turbojpeg.jar TJBench`. 778 7798. cjpeg can now be used to generate JPEG files with the RGB colorspace 780(feature ported from jpeg-8d.) 781 7829. The width and height in the `-crop` argument passed to jpegtran can now be 783suffixed with `f` to indicate that, when the upper left corner of the cropping 784region is automatically moved to the nearest iMCU boundary, the bottom right 785corner should be moved by the same amount. In other words, this feature causes 786jpegtran to strictly honor the specified width/height rather than the specified 787bottom right corner (feature ported from jpeg-8d.) 788 78910. JPEG files using the RGB colorspace can now be decompressed into grayscale 790images (feature ported from jpeg-8d.) 791 79211. Fixed a regression caused by 1.2.1[7] whereby the build would fail with 793multiple "Mismatch in operand sizes" errors when attempting to build the x86 794SIMD code with NASM 0.98. 795 79612. The in-memory source/destination managers (`jpeg_mem_src()` and 797`jpeg_mem_dest()`) are now included by default when building libjpeg-turbo with 798libjpeg v6b or v7 emulation, so that programs can take advantage of these 799functions without requiring the use of the backward-incompatible libjpeg v8 800ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been 801incremented by 1 to reflect this. You can disable this feature with a 802configure/CMake switch in order to retain strict API/ABI compatibility with the 803libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See 804[README.md](README.md) for more details. 805 80613. Added ARMv7s architecture to libjpeg.a and libturbojpeg.a in the official 807libjpeg-turbo binary package for OS X, so that those libraries can be used to 808build applications that leverage the faster CPUs in the iPhone 5 and iPad 4. 809 810 8111.2.1 812===== 813 814### Significant changes relative to 1.2.0: 815 8161. Creating or decoding a JPEG file that uses the RGB colorspace should now 817properly work when the input or output colorspace is one of the libjpeg-turbo 818colorspace extensions. 819 8202. When libjpeg-turbo was built without SIMD support and merged (non-fancy) 821upsampling was used along with an alpha-enabled colorspace during 822decompression, the unused byte of the decompressed pixels was not being set to 8230xFF. This has been fixed. TJUnitTest has also been extended to test for the 824correct behavior of the colorspace extensions when merged upsampling is used. 825 8263. Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the 827upper 64 bits of xmm6 and xmm7 on Win64 platforms, which violated the Win64 828calling conventions. 829 8304. Fixed a regression caused by 1.2.0[6] whereby decompressing corrupt JPEG 831images (specifically, images in which the component count was erroneously set 832to a large value) would cause libjpeg-turbo to segfault. 833 8345. Worked around a severe performance issue with "Bobcat" (AMD Embedded APU) 835processors. The `MASKMOVDQU` instruction, which was used by the libjpeg-turbo 836SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and 837it is painfully slow on Bobcat processors in particular. Eliminating the use 838of this instruction improved performance by an order of magnitude on Bobcat 839processors and by a small amount (typically 5%) on AMD desktop processors. 840 8416. Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM 842platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such 843platforms. 844 8457. Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms 846running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or 8474:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy 848upsampling would produce several incorrect columns of pixels at the right-hand 849side of the output image if each row in the output image was not evenly 850divisible by 16 bytes. 851 8528. Fixed an issue whereby attempting to build the SIMD extensions with Xcode 8534.3 on OS X platforms would cause NASM to return numerous errors of the form 854"'%define' expects a macro identifier". 855 8569. Added flags to the TurboJPEG API that allow the caller to force the use of 857either the fast or the accurate DCT/IDCT algorithms in the underlying codec. 858 859 8601.2.0 861===== 862 863### Significant changes relative to 1.2 beta1: 864 8651. Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system 866was not adding the current directory to the assembler include path, so YASM 867was not able to find jsimdcfg.inc.) 868 8692. Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing 870a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes. 871This was more of an annoyance than an actual bug, since it did not cause any 872actual run-time problems, but the issue showed up when running libjpeg-turbo in 873valgrind. See <http://crbug.com/72399> for more information. 874 8753. Added a compile-time macro (`LIBJPEG_TURBO_VERSION`) that can be used to 876check the version of libjpeg-turbo against which an application was compiled. 877 8784. Added new RGBA/BGRA/ABGR/ARGB colorspace extension constants (libjpeg API) 879and pixel formats (TurboJPEG API), which allow applications to specify that, 880when decompressing to a 4-component RGB buffer, the unused byte should be set 881to 0xFF so that it can be interpreted as an opaque alpha channel. 882 8835. Fixed regression issue whereby DevIL failed to build against libjpeg-turbo 884because libjpeg-turbo's distributed version of jconfig.h contained an `INLINE` 885macro, which conflicted with a similar macro in DevIL. This macro is used only 886internally when building libjpeg-turbo, so it was moved into config.h. 887 8886. libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose 889K component is assigned a component ID of 1 instead of 4. Although these files 890are in violation of the spec, other JPEG implementations handle them 891correctly. 892 8937. Added ARMv6 and ARMv7 architectures to libjpeg.a and libturbojpeg.a in 894the official libjpeg-turbo binary package for OS X, so that those libraries can 895be used to build both OS X and iOS applications. 896 897 8981.1.90 (1.2 beta1) 899================== 900 901### Significant changes relative to 1.1.1: 902 9031. Added a Java wrapper for the TurboJPEG API. See [java/README](java/README) 904for more details. 905 9062. The TurboJPEG API can now be used to scale down images during 907decompression. 908 9093. Added SIMD routines for RGB-to-grayscale color conversion, which 910significantly improves the performance of grayscale JPEG compression from an 911RGB source image. 912 9134. Improved the performance of the C color conversion routines, which are used 914on platforms for which SIMD acceleration is not available. 915 9165. Added a function to the TurboJPEG API that performs lossless transforms. 917This function is implemented using the same back end as jpegtran, but it 918performs transcoding entirely in memory and allows multiple transforms and/or 919crop operations to be batched together, so the source coefficients only need to 920be read once. This is useful when generating image tiles from a single source 921JPEG. 922 9236. Added tests for the new TurboJPEG scaled decompression and lossless 924transform features to tjbench (the TurboJPEG benchmark, formerly called 925"jpgtest".) 926 9277. Added support for 4:4:0 (transposed 4:2:2) subsampling in TurboJPEG, which 928was necessary in order for it to read 4:2:2 JPEG files that had been losslessly 929transposed or rotated 90 degrees. 930 9318. All legacy VirtualGL code has been re-factored, and this has allowed 932libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license. 933 9349. libjpeg-turbo can now be built with YASM. 935 93610. Added SIMD acceleration for ARM Linux and iOS platforms that support 937NEON instructions. 938 93911. Refactored the TurboJPEG C API and documented it using Doxygen. The 940TurboJPEG 1.2 API uses pixel formats to define the size and component order of 941the uncompressed source/destination images, and it includes a more efficient 942version of `TJBUFSIZE()` that computes a worst-case JPEG size based on the 943level of chrominance subsampling. The refactored implementation of the 944TurboJPEG API now uses the libjpeg memory source and destination managers, 945which allows the TurboJPEG compressor to grow the JPEG buffer as necessary. 946 94712. Eliminated errors in the output of jpegtran on Windows that occurred when 948the application was invoked using I/O redirection 949(`jpegtran <input.jpg >output.jpg`.) 950 95113. The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding 952support in libjpeg-turbo v1.1.0 introduced several new error constants in 953jerror.h, and these were mistakenly enabled for all emulation modes, causing 954the error enum in libjpeg-turbo to sometimes have different values than the 955same enum in libjpeg. This represents an ABI incompatibility, and it caused 956problems with rare applications that took specific action based on a particular 957error value. The fix was to include the new error constants conditionally 958based on whether libjpeg v7 or v8 emulation was enabled. 959 96014. Fixed an issue whereby Windows applications that used libjpeg-turbo would 961fail to compile if the Windows system headers were included before jpeglib.h. 962This issue was caused by a conflict in the definition of the INT32 type. 963 96415. Fixed 32-bit supplementary package for amd64 Debian systems, which was 965broken by enhancements to the packaging system in 1.1. 966 96716. When decompressing a JPEG image using an output colorspace of 968`JCS_EXT_RGBX`, `JCS_EXT_BGRX`, `JCS_EXT_XBGR`, or `JCS_EXT_XRGB`, 969libjpeg-turbo will now set the unused byte to 0xFF, which allows applications 970to interpret that byte as an alpha channel (0xFF = opaque). 971 972 9731.1.1 974===== 975 976### Significant changes relative to 1.1.0: 977 9781. Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated 979by `tjEncodeYUV()`. 980 9812. libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected 982markers found in the middle of the JPEG data stream during decompression. It 983will now hand off decoding of a particular block to the unaccelerated Huffman 984decoder if an unexpected marker is found, so that the unaccelerated Huffman 985decoder can generate an appropriate warning. 986 9873. Older versions of MinGW64 prefixed symbol names with underscores by 988default, which differed from the behavior of 64-bit Visual C++. MinGW64 1.0 989has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate 990this, the libjpeg-turbo SIMD function names are no longer prefixed with an 991underscore when building with MinGW64. This means that, when building 992libjpeg-turbo with older versions of MinGW64, you will now have to add 993`-fno-leading-underscore` to the `CFLAGS`. 994 9954. Fixed a regression bug in the NSIS script that caused the Windows installer 996build to fail when using the Visual Studio IDE. 997 9985. Fixed a bug in `jpeg_read_coefficients()` whereby it would not initialize 999`cinfo->image_width` and `cinfo->image_height` if libjpeg v7 or v8 emulation 1000was enabled. This specifically caused the jpegoptim program to fail if it was 1001linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8 1002emulation. 1003 10046. Eliminated excessive I/O overhead that occurred when reading BMP files in 1005cjpeg. 1006 10077. Eliminated errors in the output of cjpeg on Windows that occurred when the 1008application was invoked using I/O redirection (`cjpeg <inputfile >output.jpg`.) 1009 1010 10111.1.0 1012===== 1013 1014### Significant changes relative to 1.1 beta1: 1015 10161. The algorithm used by the SIMD quantization function cannot produce correct 1017results when the JPEG quality is >= 98 and the fast integer forward DCT is 1018used. Thus, the non-SIMD quantization function is now used for those cases, 1019and libjpeg-turbo should now produce identical output to libjpeg v6b in all 1020cases. 1021 10222. Despite the above, the fast integer forward DCT still degrades somewhat for 1023JPEG qualities greater than 95, so the TurboJPEG wrapper will now automatically 1024use the slow integer forward DCT when generating JPEG images of quality 96 or 1025greater. This reduces compression performance by as much as 15% for these 1026high-quality images but is necessary to ensure that the images are perceptually 1027lossless. It also ensures that the library can avoid the performance pitfall 1028created by [1]. 1029 10303. Ported jpgtest.cxx to pure C to avoid the need for a C++ compiler. 1031 10324. Fixed visual artifacts in grayscale JPEG compression caused by a typo in 1033the RGB-to-luminance lookup tables. 1034 10355. The Windows distribution packages now include the libjpeg run-time programs 1036(cjpeg, etc.) 1037 10386. All packages now include jpgtest. 1039 10407. The TurboJPEG dynamic library now uses versioned symbols. 1041 10428. Added two new TurboJPEG API functions, `tjEncodeYUV()` and 1043`tjDecompressToYUV()`, to replace the somewhat hackish `TJ_YUV` flag. 1044 1045 10461.0.90 (1.1 beta1) 1047================== 1048 1049### Significant changes relative to 1.0.1: 1050 10511. Added emulation of the libjpeg v7 and v8 APIs and ABIs. See 1052[README.md](README.md) for more details. This feature was sponsored by 1053CamTrace SAS. 1054 10552. Created a new CMake-based build system for the Visual C++ and MinGW builds. 1056 10573. Grayscale bitmaps can now be compressed from/decompressed to using the 1058TurboJPEG API. 1059 10604. jpgtest can now be used to test decompression performance with existing 1061JPEG images. 1062 10635. If the default install prefix (/opt/libjpeg-turbo) is used, then 1064`make install` now creates /opt/libjpeg-turbo/lib32 and 1065/opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary 1066packages. 1067 10686. All symbols in the libjpeg-turbo dynamic library are now versioned, even 1069when the library is built with libjpeg v6b emulation. 1070 10717. Added arithmetic encoding and decoding support (can be disabled with 1072configure or CMake options) 1073 10748. Added a `TJ_YUV` flag to the TurboJPEG API, which causes both the compressor 1075and decompressor to output planar YUV images. 1076 10779. Added an extended version of `tjDecompressHeader()` to the TurboJPEG API, 1078which allows the caller to determine the type of subsampling used in a JPEG 1079image. 1080 108110. Added further protections against invalid Huffman codes. 1082 1083 10841.0.1 1085===== 1086 1087### Significant changes relative to 1.0.0: 1088 10891. The Huffman decoder will now handle erroneous Huffman codes (for instance, 1090from a corrupt JPEG image.) Previously, these would cause libjpeg-turbo to 1091crash under certain circumstances. 1092 10932. Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to 1094be used instead of 4:2:0 when decompressing JPEG images using SSE2 code. 1095 10963. The configure script will now automatically determine whether the 1097`INCOMPLETE_TYPES_BROKEN` macro should be defined. 1098 1099 11001.0.0 1101===== 1102 1103### Significant changes relative to 0.0.93: 1104 11051. 2983700: Further FreeBSD build tweaks (no longer necessary to specify 1106`--host` when configuring on a 64-bit system) 1107 11082. Created symlinks in the Unix/Linux packages so that the TurboJPEG 1109include file can always be found in /opt/libjpeg-turbo/include, the 32-bit 1110static libraries can always be found in /opt/libjpeg-turbo/lib32, and the 111164-bit static libraries can always be found in /opt/libjpeg-turbo/lib64. 1112 11133. The Unix/Linux distribution packages now include the libjpeg run-time 1114programs (cjpeg, etc.) and man pages. 1115 11164. Created a 32-bit supplementary package for amd64 Debian systems, which 1117contains just the 32-bit libjpeg-turbo libraries. 1118 11195. Moved the libraries from */lib32 to */lib in the i386 Debian package. 1120 11216. Include distribution package for Cygwin 1122 11237. No longer necessary to specify `--without-simd` on non-x86 architectures, 1124and unit tests now work on those architectures. 1125 1126 11270.0.93 1128====== 1129 1130### Significant changes since 0.0.91: 1131 11321. 2982659: Fixed x86-64 build on FreeBSD systems 1133 11342. 2988188: Added support for Windows 64-bit systems 1135 1136 11370.0.91 1138====== 1139 1140### Significant changes relative to 0.0.90: 1141 11421. Added documentation to .deb packages 1143 11442. 2968313: Fixed data corruption issues when decompressing large JPEG images 1145and/or using buffered I/O with the libjpeg-turbo decompressor 1146 1147 11480.0.90 1149====== 1150 1151Initial release 1152