OLD | NEW |
| 1 1.5 beta1 |
| 2 ========= |
| 3 |
| 4 [1] Added full SIMD acceleration for PowerPC platforms using AltiVec VMX |
| 5 (128-bit SIMD) instructions. Although the performance of libjpeg-turbo on |
| 6 PowerPC was already good, due to the increased number of registers available |
| 7 to the compiler vs. x86, it was still possible to speed up compression by about |
| 8 3-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the |
| 9 use of AltiVec instructions. |
| 10 |
| 11 [2] Added two new libjpeg API functions (jpeg_skip_scanlines() and |
| 12 jpeg_crop_scanline()) that can be used to partially decode a JPEG image. See |
| 13 libjpeg.txt for more details. |
| 14 |
| 15 [3] The TJCompressor and TJDecompressor classes in the TurboJPEG Java API now |
| 16 implement the Closeable interface, so those classes can be used with a |
| 17 try-with-resources statement. |
| 18 |
| 19 [4] The TurboJPEG Java classes now throw unchecked idiomatic exceptions |
| 20 (IllegalArgumentException, IllegalStateException) for unrecoverable errors |
| 21 caused by incorrect API usage, and those classes throw a new checked exception |
| 22 type (TJException) for errors that are passed through from the C library. |
| 23 |
| 24 [5] Source buffers for the TurboJPEG C API functions, as well as the |
| 25 jpeg_mem_src() function in the libjpeg API, are now declared as const pointers. |
| 26 This facilitates passing read-only buffers to those functions and ensures the |
| 27 caller that the source buffer will not be modified. This should not create any |
| 28 backward API or ABI incompatibilities with prior libjpeg-turbo releases. |
| 29 |
| 30 [6] The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1 |
| 31 FPUs. |
| 32 |
| 33 [7] Fixed additional negative left shifts and other issues reported by the GCC |
| 34 and Clang undefined behavior sanitizers. Most of these issues affected only |
| 35 32-bit code, and none of them was known to pose a security threat, but removing |
| 36 the warnings makes it easier to detect actual security issues, should they |
| 37 arise in the future. |
| 38 |
| 39 [8] Removed the unnecessary .arch directive from the ARM64 NEON SIMD code. |
| 40 This directive was preventing the code from assembling using the clang |
| 41 integrated assembler. |
| 42 |
| 43 [9] Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit |
| 44 libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora |
| 45 distributions. This was due to the addition of a macro in jconfig.h that |
| 46 allows the Huffman codec to determine the word size at compile time. Since |
| 47 that macro differs between 32-bit and 64-bit builds, this caused a conflict |
| 48 between the i386 and x86_64 RPMs (any differing files, other than executables, |
| 49 are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.) |
| 50 Since the macro is used only internally, it has been moved into jconfigint.h. |
| 51 |
| 52 [10] The x86-64 SIMD code can now be disabled at run time by setting the |
| 53 JSIMD_FORCENONE environment variable to 1 (the other SIMD implementations |
| 54 already had this capability.) |
| 55 |
| 56 [11] Added a new command-line argument to TJBench (-nowrite) that prevents the |
| 57 benchmark from outputting any images. This removes any potential operating |
| 58 system overhead that might be caused by lazy writes to disk and thus improves |
| 59 the consistency of the performance measurements. |
| 60 |
| 61 [12] Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and |
| 62 x86-64 platforms. This speeds up the compression of full-color JPEGs by about |
| 63 10-15% on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and |
| 64 AMD CPUs. Additionally, this works around an issue in the clang optimizer that |
| 65 prevents it (as of this writing) from achieving the same performance as GCC |
| 66 when compiling the C version of the Huffman encoder |
| 67 (https://llvm.org/bugs/show_bug.cgi?id=16035). For the purposes of benchmarking |
| 68 or regression testing, SIMD-accelerated Huffman encoding can be disabled by |
| 69 setting the JSIMD_NOHUFFENC environment variable to 1. |
| 70 |
| 71 [13] Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used |
| 72 compression algorithms (including the slow integer forward DCT and h2v2 & h2v1 |
| 73 downsampling algorithms, which are not accelerated in the 32-bit NEON |
| 74 implementation.) This speeds up the compression of full-color JPEGs by about |
| 75 75% on average on a Cavium ThunderX processor and by about 2-2.5x on average on |
| 76 Cortex-A53 and Cortex-A57 cores. |
| 77 |
| 78 [14] Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit |
| 79 and 64-bit platforms. |
| 80 |
| 81 For 32-bit code, this speeds up the compression of full-color JPEGs by about |
| 82 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by about 6-7% |
| 83 on average on a typical Android device (Nexus 5X, Cortex-A53 and Cortex-A57), |
| 84 relative to libjpeg-turbo 1.4.x. Note that the larger speedup under iOS is due |
| 85 to the fact that iOS builds use LLVM, which does not optimize the C Huffman |
| 86 encoder as well as GCC does. |
| 87 |
| 88 For 64-bit code, NEON-accelerated Huffman encoding speeds up the compression of |
| 89 full-color JPEGs by about 40% on average on a typical iOS device (iPhone 5S, |
| 90 Apple A7) and by about 7-8% on average on a typical Android device (Nexus 5X, |
| 91 Cortex-A53 and Cortex-A57), in addition to the speedup described in [13] above. |
| 92 |
| 93 For the purposes of benchmarking or regression testing, SIMD-accelerated |
| 94 Huffman encoding can be disabled by setting the JSIMD_NOHUFFENC environment |
| 95 variable to 1. |
| 96 |
| 97 [15] pkg-config (.pc) scripts are now included for both the libjpeg and |
| 98 TurboJPEG API libraries on Un*x systems. Note that if a project's build system |
| 99 relies on these scripts, then it will not be possible to build that project |
| 100 with libjpeg or with a prior version of libjpeg-turbo. |
| 101 |
| 102 [16] Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to |
| 103 improve performance on CPUs with in-order pipelines. This speeds up the |
| 104 decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX |
| 105 processor and by about 15% on average on a Cortex-A53 core. |
| 106 |
| 107 [17] Fixed an issue in the accelerated Huffman decoder that could have caused |
| 108 the decoder to read past the end of the input buffer when a malformed, |
| 109 specially-crafted JPEG image was being decompressed. In prior versions of |
| 110 libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only |
| 111 if there were > 128 bytes of data in the input buffer. However, it is possible |
| 112 to construct a JPEG image in which a single Huffman block is over 430 bytes |
| 113 long, so this version of libjpeg-turbo activates the accelerated Huffman |
| 114 decoder only if there are > 512 bytes of data in the input buffer. |
| 115 |
| 116 [18] Fixed a memory leak in tjunittest encountered when running the program |
| 117 with the -yuv option. |
| 118 |
| 119 |
| 120 1.4.2 |
| 121 ===== |
| 122 |
| 123 [1] Fixed an issue whereby cjpeg would segfault if a Windows bitmap with a |
| 124 negative width or height was used as an input image (Windows bitmaps can have |
| 125 a negative height if they are stored in top-down order, but such files are |
| 126 rare and not supported by libjpeg-turbo.) |
| 127 |
| 128 [2] Fixed an issue whereby, under certain circumstances, libjpeg-turbo would |
| 129 incorrectly encode certain JPEG images when quality=100 and the fast integer |
| 130 forward DCT were used. This was known to cause 'make test' to fail when the |
| 131 library was built with '-march=haswell' on x86 systems. |
| 132 |
| 133 [3] Fixed an issue whereby libjpeg-turbo would crash when built with the latest |
| 134 & greatest development version of the Clang/LLVM compiler. This was caused by |
| 135 an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD |
| 136 routines. Those routines were incorrectly using a 64-bit mov instruction to |
| 137 transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper |
| 138 (unused) 32 bits of a 32-bit argument's register to be undefined. The new |
| 139 Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit |
| 140 structure members into a single 64-bit register, and this exposed the ABI |
| 141 conformance issue. |
| 142 |
| 143 [4] Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged) |
| 144 upsampling routine that caused a buffer overflow (and subsequent segfault) when |
| 145 decompressing a 4:2:0 JPEG image whose scaled output width was less than 16 |
| 146 pixels. The "plain" upsampling routines are normally only used when |
| 147 decompressing a non-YCbCr JPEG image, but they are also used when decompressing |
| 148 a JPEG image whose scaled output height is 1. |
| 149 |
| 150 [5] Fixed various negative left shifts and other issues reported by the GCC and |
| 151 Clang undefined behavior sanitizers. None of these was known to pose a |
| 152 security threat, but removing the warnings makes it easier to detect actual |
| 153 security issues, should they arise in the future. |
| 154 |
| 155 |
| 156 1.4.1 |
| 157 ===== |
| 158 |
| 159 [1] tjbench now properly handles CMYK/YCCK JPEG files. Passing an argument of |
| 160 -cmyk (instead of, for instance, -rgb) will cause tjbench to internally convert |
| 161 the source bitmap to CMYK prior to compression, to generate YCCK JPEG files, |
| 162 and to internally convert the decompressed CMYK pixels back to RGB after |
| 163 decompression (the latter is done automatically if a CMYK or YCCK JPEG is |
| 164 passed to tjbench as a source image.) The CMYK<->RGB conversion operation is |
| 165 not benchmarked. NOTE: The quick & dirty CMYK<->RGB conversions that tjbench |
| 166 uses are suitable for testing only. Proper conversion between CMYK and RGB |
| 167 requires a color management system. |
| 168 |
| 169 [2] 'make test' now performs additional bitwise regression tests using tjbench, |
| 170 mainly for the purpose of testing compression from/decompression to a subregion |
| 171 of a larger image buffer. |
| 172 |
| 173 [3] 'make test' no longer tests the regression of the floating point DCT/IDCT |
| 174 by default, since the results of those tests can vary if the algorithms in |
| 175 question are not implemented using SIMD instructions on a particular platform. |
| 176 See the comments in Makefile.am for information on how to re-enable the tests |
| 177 and to specify an expected result for them based on the particulars of your |
| 178 platform. |
| 179 |
| 180 [4] The NULL color conversion routines have been significantly optimized, |
| 181 which speeds up the compression of RGB and CMYK JPEGs by 5-20% when using |
| 182 64-bit code and 0-3% when using 32-bit code, and the decompression of those |
| 183 images by 10-30% when using 64-bit code and 3-12% when using 32-bit code. |
| 184 |
| 185 [5] Fixed an "illegal instruction" error that occurred when djpeg from a |
| 186 SIMD-enabled libjpeg-turbo MIPS build was executed with the -nosmooth option on |
| 187 a MIPS machine that lacked DSPr2 support. The MIPS SIMD routines for h2v1 and |
| 188 h2v2 merged upsampling were not properly checking for the existence of DSPr2. |
| 189 |
| 190 [6] Performance has been improved significantly on 64-bit non-Linux and |
| 191 non-Windows platforms (generally 10-20% faster compression and 5-10% faster |
| 192 decompression.) Due to an oversight, the 64-bit version of the accelerated |
| 193 Huffman codec was not being compiled in when libjpeg-turbo was built on |
| 194 platforms other than Windows or Linux. Oops. |
| 195 |
| 196 [7] Fixed an extremely rare bug in the Huffman encoder that caused 64-bit |
| 197 builds of libjpeg-turbo to incorrectly encode a few specific test images when |
| 198 quality=98, an optimized Huffman table, and the slow integer forward DCT were |
| 199 used. |
| 200 |
| 201 [8] The Windows (CMake) build system now supports building only static or only |
| 202 shared libraries. This is accomplished by adding either -DENABLE_STATIC=0 or |
| 203 -DENABLE_SHARED=0 to the CMake command line. |
| 204 |
| 205 [9] TurboJPEG API functions will now return an error code if a warning is |
| 206 triggered in the underlying libjpeg API. For instance, if a JPEG file is |
| 207 corrupt, the TurboJPEG decompression functions will attempt to decompress |
| 208 as much of the image as possible, but those functions will now return -1 to |
| 209 indicate that the decompression was not entirely successful. |
| 210 |
| 211 [10] Fixed a bug in the MIPS DSPr2 4:2:2 fancy upsampling routine that caused a |
| 212 buffer overflow (and subsequent segfault) when decompressing a 4:2:2 JPEG image |
| 213 in which the right-most MCU was 5 or 6 pixels wide. |
| 214 |
| 215 |
| 216 1.4.0 |
| 217 ===== |
| 218 |
| 219 [1] Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build |
| 220 because OS X does not provide the le32toh() and htole32() functions.) |
| 221 |
| 222 [2] The non-SIMD RGB565 color conversion code did not work correctly on big |
| 223 endian machines. This has been fixed. |
| 224 |
| 225 [3] Fixed an issue in tjPlaneSizeYUV() whereby it would erroneously return 1 |
| 226 instead of -1 if componentID was > 0 and subsamp was TJSAMP_GRAY. |
| 227 |
| 228 [3] Fixed an issue in tjBufSizeYUV2() whereby it would erroneously return 0 |
| 229 instead of -1 if width was < 1. |
| 230 |
| 231 [5] The Huffman encoder now uses clz and bsr instructions for bit counting on |
| 232 ARM64 platforms (see 1.4 beta1 [5].) |
| 233 |
| 234 [6] The close() method in the TJCompressor and TJDecompressor Java classes is |
| 235 now idempotent. Previously, that method would call the native tjDestroy() |
| 236 function even if the TurboJPEG instance had already been destroyed. This |
| 237 caused an exception to be thrown during finalization, if the close() method had |
| 238 already been called. The exception was caught, but it was still an expensive |
| 239 operation. |
| 240 |
| 241 [7] The TurboJPEG API previously generated an error ("Could not determine |
| 242 subsampling type for JPEG image") when attempting to decompress grayscale JPEG |
| 243 images that were compressed with a sampling factor other than 1 (for instance, |
| 244 with 'cjpeg -grayscale -sample 2x2'). Subsampling technically has no meaning |
| 245 with grayscale JPEGs, and thus the horizontal and vertical sampling factors |
| 246 for such images are ignored by the decompressor. However, the TurboJPEG API |
| 247 was being too rigid and was expecting the sampling factors to be equal to 1 |
| 248 before it treated the image as a grayscale JPEG. |
| 249 |
| 250 [8] cjpeg, djpeg, and jpegtran now accept an argument of -version, which will |
| 251 print the library version and exit. |
| 252 |
| 253 [9] Referring to 1.4 beta1 [15], another extremely rare circumstance was |
| 254 discovered under which the Huffman encoder's local buffer can be overrun |
| 255 when a buffered destination manager is being used and an |
| 256 extremely-high-frequency block (basically junk image data) is being encoded. |
| 257 Even though the Huffman local buffer was increased from 128 bytes to 136 bytes |
| 258 to address the previous issue, the new issue caused even the larger buffer to |
| 259 be overrun. Further analysis reveals that, in the absolute worst case (such as |
| 260 setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning |
| 261 order), the Huffman encoder can produce encoded blocks that approach double the |
| 262 size of the unencoded blocks. Thus, the Huffman local buffer was increased to |
| 263 256 bytes, which should prevent any such issue from re-occurring in the future. |
| 264 |
| 265 [10] The new tjPlaneSizeYUV(), tjPlaneWidth(), and tjPlaneHeight() functions |
| 266 were not actually usable on any platform except OS X and Windows, because |
| 267 those functions were not included in the libturbojpeg mapfile. This has been |
| 268 fixed. |
| 269 |
| 270 [11] Restored the JPP(), JMETHOD(), and FAR macros in the libjpeg-turbo header |
| 271 files. The JPP() and JMETHOD() macros were originally implemented in libjpeg |
| 272 as a way of supporting non-ANSI compilers that lacked support for prototype |
| 273 parameters. libjpeg-turbo has never supported such compilers, but some |
| 274 software packages still use the macros to define their own prototypes. |
| 275 Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that |
| 276 have far symbols, but some software packages still use the FAR macro. A pretty |
| 277 good argument can be made that this is a bad practice on the part of the |
| 278 software in question, but since this affects more than one package, it's just |
| 279 easier to fix it here. |
| 280 |
| 281 [12] Fixed issues that were preventing the ARM 64-bit SIMD code from compiling |
| 282 for iOS, and included an ARMv8 architecture in all of the binaries installed by |
| 283 the "official" libjpeg-turbo SDK for OS X. |
| 284 |
| 285 |
| 286 1.3.90 (1.4 beta1) |
| 287 ================== |
| 288 |
| 289 [1] New features in the TurboJPEG API: |
| 290 -- YUV planar images can now be generated with an arbitrary line padding |
| 291 (previously only 4-byte padding, which was compatible with X Video, was |
| 292 supported.) |
| 293 -- The decompress-to-YUV function has been extended to support image scaling. |
| 294 -- JPEG images can now be compressed from YUV planar source images. |
| 295 -- YUV planar images can now be decoded into RGB or grayscale images. |
| 296 -- 4:1:1 subsampling is now supported. This is mainly included for |
| 297 compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no |
| 298 significant advantages relative to 4:2:0. |
| 299 -- CMYK images are now supported. This feature allows CMYK source images to be |
| 300 compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to CMYK |
| 301 destination images. Conversion between CMYK/YCCK and RGB or YUV images is not |
| 302 supported. Such conversion requires a color management system and is thus out |
| 303 of scope for a codec library. |
| 304 -- The handling of YUV images in the Java API has been significantly refactored |
| 305 and should now be much more intuitive. |
| 306 -- The Java API now supports encoding a YUV image from an arbitrary position in |
| 307 a large image buffer. |
| 308 -- All of the YUV functions now have a corresponding function that operates on |
| 309 separate image planes instead of a unified image buffer. This allows for |
| 310 compressing/decoding from or decompressing/encoding to a subregion of a larger |
| 311 YUV image. It also allows for handling YUV formats that swap the order of the |
| 312 U and V planes. |
| 313 |
| 314 [2] Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up |
| 315 the compression of full-color JPEGs by 70-80% on such platforms and |
| 316 decompression by 25-35%. |
| 317 |
| 318 [3] If an application attempts to decompress a Huffman-coded JPEG image whose |
| 319 header does not contain Huffman tables, libjpeg-turbo will now insert the |
| 320 default Huffman tables. In order to save space, many motion JPEG video frames |
| 321 are encoded without the default Huffman tables, so these frames can now be |
| 322 successfully decompressed by libjpeg-turbo without additional work on the part |
| 323 of the application. An application can still override the Huffman tables, for |
| 324 instance to re-use tables from a previous frame of the same video. |
| 325 |
| 326 [4] The Mac packaging system now uses pkgbuild and productbuild rather than |
| 327 PackageMaker (which is obsolete and no longer supported.) This means that |
| 328 OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo, |
| 329 although the packages produced can be installed on OS X 10.5 "Leopard" or |
| 330 later. OS X 10.4 "Tiger" is no longer supported. |
| 331 |
| 332 [5] The Huffman encoder now uses clz and bsr instructions for bit counting on |
| 333 ARM platforms rather than a lookup table. This reduces the memory footprint |
| 334 by 64k, which may be important for some mobile applications. Out of four |
| 335 Android devices that were tested, two demonstrated a small overall performance |
| 336 loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with |
| 337 ARMv7 code when enabling this new feature, but the other two devices |
| 338 demonstrated a significant overall performance gain with both ARMv6 and ARMv7 |
| 339 code (~10-20%) when enabling the feature. Actual mileage may vary. |
| 340 |
| 341 [6] Worked around an issue with Visual C++ 2010 and later that caused incorrect |
| 342 pixels to be generated when decompressing a JPEG image to a 256-color bitmap, |
| 343 if compiler optimization was enabled when libjpeg-turbo was built. This caused |
| 344 the regression tests to fail when doing a release build under Visual C++ 2010 |
| 345 and later. |
| 346 |
| 347 [7] Improved the accuracy and performance of the non-SIMD implementation of the |
| 348 floating point inverse DCT (using code borrowed from libjpeg v8a and later.) |
| 349 The accuracy of this implementation now matches the accuracy of the SSE/SSE2 |
| 350 implementation. Note, however, that the floating point DCT/IDCT algorithms are |
| 351 mainly a legacy feature. They generally do not produce significantly better |
| 352 accuracy than the slow integer DCT/IDCT algorithms, and they are quite a bit |
| 353 slower. |
| 354 |
| 355 [8] Added a new output colorspace (JCS_RGB565) to the libjpeg API that allows |
| 356 for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not |
| 357 used, then this code path is SIMD-accelerated on ARM platforms. |
| 358 |
| 359 [9] Numerous obsolete features, such as support for non-ANSI compilers and |
| 360 support for the MS-DOS memory model, were removed from the libjpeg code, |
| 361 greatly improving its readability and making it easier to maintain and extend. |
| 362 |
| 363 [10] Fixed a segfault that occurred when calling output_message() with msg_code |
| 364 set to JMSG_COPYRIGHT. |
| 365 |
| 366 [11] Fixed an issue whereby wrjpgcom was allowing comments longer than 65k |
| 367 characters to be passed on the command line, which was causing it to generate |
| 368 incorrect JPEG files. |
| 369 |
| 370 [12] Fixed a bug in the build system that was causing the Windows version of |
| 371 wrjpgcom to be built using the rdjpgcom source code. |
| 372 |
| 373 [13] Restored 12-bit-per-component JPEG support. A 12-bit version of |
| 374 libjpeg-turbo can now be built by passing an argument of --with-12bit to |
| 375 configure (Unix) or -DWITH_12BIT=1 to cmake (Windows.) 12-bit JPEG support is |
| 376 included only for convenience. Enabling this feature disables all of the |
| 377 performance features in libjpeg-turbo, as well as arithmetic coding and the |
| 378 TurboJPEG API. The resulting library still contains the other libjpeg-turbo |
| 379 features (such as the colorspace extensions), but in general, it performs no |
| 380 faster than libjpeg v6b. |
| 381 |
| 382 [14] Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion |
| 383 and IDCT algorithms (both are used during JPEG decompression.) For unknown |
| 384 reasons (probably related to clang), this code cannot currently be compiled for |
| 385 iOS. |
| 386 |
| 387 [15] Fixed an extremely rare bug that could cause the Huffman encoder's local |
| 388 buffer to overrun when a very high-frequency MCU is compressed using quality |
| 389 100 and no subsampling, and when the JPEG output buffer is being dynamically |
| 390 resized by the destination manager. This issue was so rare that, even with a |
| 391 test program specifically designed to make the bug occur (by injecting random |
| 392 high-frequency YUV data into the compressor), it was reproducible only once in |
| 393 about every 25 million iterations. |
| 394 |
| 395 [16] Fixed an oversight in the TurboJPEG C wrapper: if any of the JPEG |
| 396 compression functions was called repeatedly with the same |
| 397 automatically-allocated destination buffer, then TurboJPEG would erroneously |
| 398 assume that the jpegSize parameter was equal to the size of the buffer, when in |
| 399 fact that parameter was probably equal to the size of the most recently |
| 400 compressed JPEG image. If the size of the previous JPEG image was not as large |
| 401 as the current JPEG image, then TurboJPEG would unnecessarily reallocate the |
| 402 destination buffer. |
| 403 |
| 404 |
1 1.3.1 | 405 1.3.1 |
2 ===== | 406 ===== |
3 | 407 |
4 [1] On Un*x systems, 'make install' now installs the libjpeg-turbo libraries | 408 [1] On Un*x systems, 'make install' now installs the libjpeg-turbo libraries |
5 into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86, | 409 into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86, |
6 and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just | 410 and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just |
7 x86-64. You can override this by overriding either the 'prefix' or 'libdir' | 411 x86-64. You can override this by overriding either the 'prefix' or 'libdir' |
8 configure variables. | 412 configure variables. |
9 | 413 |
10 [2] The Windows installer now places a copy of the TurboJPEG DLLs in the same | 414 [2] The Windows installer now places a copy of the TurboJPEG DLLs in the same |
(...skipping 110 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
121 SIMD code with NASM 0.98. | 525 SIMD code with NASM 0.98. |
122 | 526 |
123 [12] The in-memory source/destination managers (jpeg_mem_src() and | 527 [12] The in-memory source/destination managers (jpeg_mem_src() and |
124 jpeg_mem_dest()) are now included by default when building libjpeg-turbo with | 528 jpeg_mem_dest()) are now included by default when building libjpeg-turbo with |
125 libjpeg v6b or v7 emulation, so that programs can take advantage of these | 529 libjpeg v6b or v7 emulation, so that programs can take advantage of these |
126 functions without requiring the use of the backward-incompatible libjpeg v8 | 530 functions without requiring the use of the backward-incompatible libjpeg v8 |
127 ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been | 531 ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been |
128 incremented by 1 to reflect this. You can disable this feature with a | 532 incremented by 1 to reflect this. You can disable this feature with a |
129 configure/CMake switch in order to retain strict API/ABI compatibility with the | 533 configure/CMake switch in order to retain strict API/ABI compatibility with the |
130 libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See | 534 libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See |
131 README-turbo.txt for more details. | 535 README.md for more details. |
132 | 536 |
133 [13] Added ARM v7s architecture to libjpeg.a and libturbojpeg.a in the official | 537 [13] Added ARMv7s architecture to libjpeg.a and libturbojpeg.a in the official |
134 libjpeg-turbo binary package for OS X, so that those libraries can be used to | 538 libjpeg-turbo binary package for OS X, so that those libraries can be used to |
135 build applications that leverage the faster CPUs in the iPhone 5 and iPad 4. | 539 build applications that leverage the faster CPUs in the iPhone 5 and iPad 4. |
136 | 540 |
137 | 541 |
138 1.2.1 | 542 1.2.1 |
139 ===== | 543 ===== |
140 | 544 |
141 [1] Creating or decoding a JPEG file that uses the RGB colorspace should now | 545 [1] Creating or decoding a JPEG file that uses the RGB colorspace should now |
142 properly work when the input or output colorspace is one of the libjpeg-turbo | 546 properly work when the input or output colorspace is one of the libjpeg-turbo |
143 colorspace extensions. | 547 colorspace extensions. |
(...skipping 62 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
206 [5] Fixed regression issue whereby DevIL failed to build against libjpeg-turbo | 610 [5] Fixed regression issue whereby DevIL failed to build against libjpeg-turbo |
207 because libjpeg-turbo's distributed version of jconfig.h contained an INLINE | 611 because libjpeg-turbo's distributed version of jconfig.h contained an INLINE |
208 macro, which conflicted with a similar macro in DevIL. This macro is used only | 612 macro, which conflicted with a similar macro in DevIL. This macro is used only |
209 internally when building libjpeg-turbo, so it was moved into config.h. | 613 internally when building libjpeg-turbo, so it was moved into config.h. |
210 | 614 |
211 [6] libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose | 615 [6] libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose |
212 K component is assigned a component ID of 1 instead of 4. Although these files | 616 K component is assigned a component ID of 1 instead of 4. Although these files |
213 are in violation of the spec, other JPEG implementations handle them | 617 are in violation of the spec, other JPEG implementations handle them |
214 correctly. | 618 correctly. |
215 | 619 |
216 [7] Added ARM v6 and ARM v7 architectures to libjpeg.a and libturbojpeg.a in | 620 [7] Added ARMv6 and ARMv7 architectures to libjpeg.a and libturbojpeg.a in |
217 the official libjpeg-turbo binary package for OS X, so that those libraries can | 621 the official libjpeg-turbo binary package for OS X, so that those libraries can |
218 be used to build both OS X and iOS applications. | 622 be used to build both OS X and iOS applications. |
219 | 623 |
220 | 624 |
221 1.1.90 (1.2 beta1) | 625 1.1.90 (1.2 beta1) |
222 ================== | 626 ================== |
223 | 627 |
224 [1] Added a Java wrapper for the TurboJPEG API. See java/README for more | 628 [1] Added a Java wrapper for the TurboJPEG API. See java/README for more |
225 details. | 629 details. |
226 | 630 |
(...skipping 130 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
357 [7] The TurboJPEG dynamic library now uses versioned symbols. | 761 [7] The TurboJPEG dynamic library now uses versioned symbols. |
358 | 762 |
359 [8] Added two new TurboJPEG API functions, tjEncodeYUV() and | 763 [8] Added two new TurboJPEG API functions, tjEncodeYUV() and |
360 tjDecompressToYUV(), to replace the somewhat hackish TJ_YUV flag. | 764 tjDecompressToYUV(), to replace the somewhat hackish TJ_YUV flag. |
361 | 765 |
362 | 766 |
363 1.0.90 (1.1 beta1) | 767 1.0.90 (1.1 beta1) |
364 ================== | 768 ================== |
365 | 769 |
366 [1] Added emulation of the libjpeg v7 and v8 APIs and ABIs. See | 770 [1] Added emulation of the libjpeg v7 and v8 APIs and ABIs. See |
367 README-turbo.txt for more details. This feature was sponsored by CamTrace SAS. | 771 README.md for more details. This feature was sponsored by CamTrace SAS. |
368 | 772 |
369 [2] Created a new CMake-based build system for the Visual C++ and MinGW builds. | 773 [2] Created a new CMake-based build system for the Visual C++ and MinGW builds. |
370 | 774 |
371 [3] Grayscale bitmaps can now be compressed from/decompressed to using the | 775 [3] Grayscale bitmaps can now be compressed from/decompressed to using the |
372 TurboJPEG API. | 776 TurboJPEG API. |
373 | 777 |
374 [4] jpgtest can now be used to test decompression performance with existing | 778 [4] jpgtest can now be used to test decompression performance with existing |
375 JPEG images. | 779 JPEG images. |
376 | 780 |
377 [5] If the default install prefix (/opt/libjpeg-turbo) is used, then | 781 [5] If the default install prefix (/opt/libjpeg-turbo) is used, then |
(...skipping 70 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
448 [1] Added documentation to .deb packages | 852 [1] Added documentation to .deb packages |
449 | 853 |
450 [2] 2968313: Fixed data corruption issues when decompressing large JPEG images | 854 [2] 2968313: Fixed data corruption issues when decompressing large JPEG images |
451 and/or using buffered I/O with the libjpeg-turbo decompressor | 855 and/or using buffered I/O with the libjpeg-turbo decompressor |
452 | 856 |
453 | 857 |
454 0.0.90 | 858 0.0.90 |
455 ====== | 859 ====== |
456 | 860 |
457 Initial release | 861 Initial release |
OLD | NEW |