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