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