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