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