blob: ed32eb9d07df64eb167b544c466c112e8e6115d8 [file] [log] [blame]
DRCf610d612013-04-26 10:33:29 +000011.4 pre-beta
2============
3
DRCfc26b652014-03-16 22:56:26 +00004[1] New features in the TurboJPEG API:
5-- YUV planar images can now be generated with an arbitrary line padding
6(previously only 4-byte padding, which was compatible with X Video, was
7supported.)
8-- The decompress-to-YUV function has been extended to support image scaling.
9-- JPEG images can now be compressed from YUV planar source images.
10-- YUV planar images can now be decoded into RGB or grayscale images.
11-- 4:1:1 subsampling is now supported. This is mainly included for
12compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no
13significant advantages relative to 4:2:0.
14-- CMYK images are now supported. This feature allows CMYK source images to be
15compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to CMYK
16destination images. Conversion between CMYK and RGB or YUV images is not
17supported. Such conversion requires a color management system and is out of
18scope for a codec library.
19-- The handling of YUV images in the Java API has been significantly refactored
20and should now be much more intuitive.
21-- The Java API now supports encoding a YUV image from an arbitrary position in
22a large image buffer.
DRCf610d612013-04-26 10:33:29 +000023
DRCa6b7fbd2013-09-30 18:13:27 +000024[2] Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up
DRCd64e23e2013-10-08 02:32:07 +000025the compression of full-color JPEGs by 70-80% on such platforms and
26decompression by 25-35%.
DRC0be9fa52013-07-24 21:50:20 +000027
DRCfc26b652014-03-16 22:56:26 +000028[3] If an application attempts to decompress a Huffman-coded JPEG image whose
DRCa1135062014-01-31 17:22:15 +000029header does not contain Huffman tables, libjpeg-turbo will now insert the
30default Huffman tables. In order to save space, many motion JPEG video frames
31are encoded without the default Huffman tables, so these frames can now be
32successfully decompressed by libjpeg-turbo without additional work on the part
33of the application. An application can still override the Huffman tables, for
34instance to re-use tables from a previous frame of the same video.
35
DRCb1068fa2014-03-23 17:53:07 +000036[4] The Mac packaging system now uses pkgbuild and productbuild rather than
37PackageMaker (which is obsolete and no longer supported.) This means that
38OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo,
39although the packages produced can be installed on OS X 10.5 "Leopard" or
40later. OS X 10.4 "Tiger" is no longer supported.
41
DRC0cfc4c12014-03-28 18:33:25 +000042[5] The Huffman encoder now uses clz and bsr instructions for bit counting on
43ARM platforms rather than a lookup table. This reduces the memory footprint
44by 64k, which may be important for some mobile applications. Out of four
DRCfdd625e2014-04-15 03:07:44 +000045Android devices that were tested, two demonstrated a small overall performance
46loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with
47ARMv7 code when enabling this new feature, but the other two devices
48demonstrated a significant overall performance gain with both ARMv6 and ARMv7
49code (~10-20%.) Actual mileage may vary.
DRC0cfc4c12014-03-28 18:33:25 +000050
DRCf610d612013-04-26 10:33:29 +000051
DRC96573d02013-08-11 23:23:41 +0000521.3.1
53=====
54
55[1] On Un*x systems, 'make install' now installs the libjpeg-turbo libraries
56into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86,
57and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just
58x86-64. You can override this by overriding either the 'prefix' or 'libdir'
59configure variables.
60
DRC4d877932013-09-19 22:55:57 +000061[2] The Windows installer now places a copy of the TurboJPEG DLLs in the same
62directory as the rest of the libjpeg-turbo binaries. This was mainly done
63to support TurboVNC 1.3, which bundles the DLLs in its Windows installation.
64When using a 32-bit version of CMake on 64-bit Windows, it is impossible to
65access the c:\WINDOWS\system32 directory, which made it impossible for the
66TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL.
67
DRCcadabd42013-09-28 03:10:31 +000068[3] Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic
69entropy coding (by passing arguments of -progressive -arithmetic to cjpeg or
70jpegtran, for instance) would result in an error, "Requested feature was
71omitted at compile time".
DRC1370f102013-09-24 03:21:38 +000072
DRC7ebf2942013-11-21 18:32:48 +000073[4] Fixed a couple of issues whereby malformed JPEG images would cause
DRC43d8cf42013-11-21 18:34:39 +000074libjpeg-turbo to use uninitialized memory during decompression.
75
DRC38c99702014-02-11 09:45:18 +000076[5] Fixed an error ("Buffer passed to JPEG library is too small") that occurred
77when calling the TurboJPEG YUV encoding function with a very small (< 5x5)
78source image, and added a unit test to check for this error.
79
DRCd45c5492014-03-11 06:21:46 +000080[6] The Java classes should now build properly under Visual Studio 2010 and
81later.
82
DRCde23dd82014-03-22 20:43:03 +000083[7] Fixed an issue that prevented SRPMs generated using the in-tree packaging
84tools from being rebuilt on certain newer Linux distributions.
85
86[8] Numerous minor fixes to eliminate compilation and build/packaging system
87warnings, fix cosmetic issues, improve documentation clarity, and other general
88source cleanup.
89
DRC96573d02013-08-11 23:23:41 +000090
DRC0bf58f22013-02-06 23:51:08 +0000911.3.0
92=====
93
94[1] 'make test' now works properly on FreeBSD, and it no longer requires the
95md5sum executable to be present on other Un*x platforms.
96
DRCd7a642b2013-04-24 06:40:25 +000097[2] Overhauled the packaging system:
DRC764e1e22013-04-19 04:25:14 +000098-- To avoid conflict with vendor-supplied libjpeg-turbo packages, the
99official RPMs and DEBs for libjpeg-turbo have been renamed to
DRCd7a642b2013-04-24 06:40:25 +0000100"libjpeg-turbo-official".
101-- The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the
102official Linux and Mac packages, to avoid conflict with vendor-supplied
103packages and also to streamline the packaging system.
104-- Release packages are now created with the directory structure defined
105by the configure variables "prefix", "bindir", "libdir", etc. (Un*x) or by the
106CMAKE_INSTALL_PREFIX variable (Windows.) The exception is that the docs are
107always located under the system default documentation directory on Un*x and Mac
108systems, and on Windows, the TurboJPEG DLL is always located in the Windows
109system directory.
DRC764e1e22013-04-19 04:25:14 +0000110-- To avoid confusion, official libjpeg-turbo packages on Linux/Unix platforms
111(except for Mac) will always install the 32-bit libraries in
112/opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64.
DRCd7a642b2013-04-24 06:40:25 +0000113-- Fixed an issue whereby, in some cases, the libjpeg-turbo executables on Un*x
114systems were not properly linking with the shared libraries installed by the
115same package.
116-- Fixed an issue whereby building the "installer" target on Windows when
117WITH_JAVA=1 would fail if the TurboJPEG JAR had not been previously built.
118-- Building the "install" target on Windows now installs files into the same
119places that the installer does.
DRC764e1e22013-04-19 04:25:14 +0000120
DRC4c17a452013-04-25 08:55:31 +0000121[3] Fixed a Huffman encoder bug that prevented I/O suspension from working
122properly.
123
DRC0bf58f22013-02-06 23:51:08 +0000124
DRC84f71222012-12-31 09:44:31 +00001251.2.90 (1.3 beta1)
126==================
DRC27fb3fc2012-01-28 01:48:07 +0000127
128[1] Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4,
DRCffe4fc12012-03-16 14:30:46 +000012911/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing. Note that the IDCT will
130not be SIMD-accelerated when using any of these new scaling factors.
DRC27fb3fc2012-01-28 01:48:07 +0000131
DRC575317b2012-06-15 22:00:47 +0000132[2] The TurboJPEG dynamic library is now versioned. It was not strictly
DRCfd407772012-03-23 03:24:39 +0000133necessary to do so, because TurboJPEG uses versioned symbols, and if a function
134changes in an ABI-incompatible way, that function is renamed and a legacy
135function is provided to maintain backward compatibility. However, certain
DRC5a84a0e2013-02-14 07:31:35 +0000136Linux distro maintainers have a policy against accepting any library that isn't
137versioned.
DRCfd407772012-03-23 03:24:39 +0000138
DRCfac3bea2012-09-24 02:27:55 +0000139[3] Extended the TurboJPEG Java API so that it can be used to compress a JPEG
140image from and decompress a JPEG image to an arbitrary position in a large
141image buffer.
DRC575317b2012-06-15 22:00:47 +0000142
DRC21868092012-07-03 20:02:49 +0000143[4] The tjDecompressToYUV() function now supports the TJFLAG_FASTDCT flag.
DRCe0419b52012-07-03 20:01:31 +0000144
DRCa394bf72012-08-07 18:44:24 +0000145[5] The 32-bit supplementary package for amd64 Debian systems now provides
DRC0a0f8d12012-08-07 18:42:07 +0000146symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32.
147This allows those libraries to be used on MultiArch-compatible systems (such as
148Ubuntu 11 and later) without setting the linker path.
149
DRC61e13412012-08-24 02:44:39 +0000150[6] The TurboJPEG Java wrapper should now find the JNI library on Mac systems
151without having to pass -Djava.library.path=/usr/lib to java.
152
DRCd9d1d672012-10-02 04:20:43 +0000153[7] TJBench has been ported to Java to provide a convenient way of validating
154the performance of the TurboJPEG Java API. It can be run with
155'java -cp turbojpeg.jar TJBench'.
156
DRCf73a27c2013-01-01 10:25:43 +0000157[8] cjpeg can now be used to generate JPEG files with the RGB colorspace
158(feature ported from jpeg-8d.)
159
DRC8cbf8932013-01-01 10:44:00 +0000160[9] The width and height in the -crop argument passed to jpegtran can now be
161suffixed with "f" to indicate that, when the upper left corner of the cropping
162region is automatically moved to the nearest iMCU boundary, the bottom right
163corner should be moved by the same amount. In other words, this feature causes
164jpegtran to strictly honor the specified width/height rather than the specified
165bottom right corner (feature ported from jpeg-8d.)
166
DRCf37e4da2013-01-01 10:52:29 +0000167[10] JPEG files using the RGB colorspace can now be decompressed into grayscale
168images (feature ported from jpeg-8d.)
169
DRC00c2cf32013-01-13 12:12:53 +0000170[11] Fixed a regression caused by 1.2.1[7] whereby the build would fail with
DRCb87a0b42013-01-13 12:15:58 +0000171multiple "Mismatch in operand sizes" errors when attempting to build the x86
172SIMD code with NASM 0.98.
173
DRCab706232013-01-18 23:42:31 +0000174[12] The in-memory source/destination managers (jpeg_mem_src() and
175jpeg_mem_dest()) are now included by default when building libjpeg-turbo with
176libjpeg v6b or v7 emulation, so that programs can take advantage of these
177functions without requiring the use of the backward-incompatible libjpeg v8
178ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been
179incremented by 1 to reflect this. You can disable this feature with a
180configure/CMake switch in order to retain strict API/ABI compatibility with the
181libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See
182README-turbo.txt for more details.
183
DRCa2a2cd62013-02-04 22:29:57 +0000184[13] Added ARM v7s architecture to libjpeg.a and libturbojpeg.a in the official
185libjpeg-turbo binary package for OS X, so that those libraries can be used to
186build applications that leverage the faster CPUs in the iPhone 5 and iPad 4.
187
DRC575317b2012-06-15 22:00:47 +0000188
1891.2.1
190=====
191
192[1] Creating or decoding a JPEG file that uses the RGB colorspace should now
193properly work when the input or output colorspace is one of the libjpeg-turbo
194colorspace extensions.
195
196[2] When libjpeg-turbo was built without SIMD support and merged (non-fancy)
197upsampling was used along with an alpha-enabled colorspace during
198decompression, the unused byte of the decompressed pixels was not being set to
1990xFF. This has been fixed. TJUnitTest has also been extended to test for the
200correct behavior of the colorspace extensions when merged upsampling is used.
201
202[3] Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the
DRC4f240162012-04-26 19:50:37 +0000203upper 64 bits of xmm6 and xmm7 on Win64 platforms, which violated the Win64
204calling conventions.
205
DRC575317b2012-06-15 22:00:47 +0000206[4] Fixed a regression caused by 1.2.0[6] whereby decompressing corrupt JPEG
DRCdd2b6512012-05-30 20:36:42 +0000207images (specifically, images in which the component count was erroneously set
208to a large value) would cause libjpeg-turbo to segfault.
209
DRC575317b2012-06-15 22:00:47 +0000210[5] Worked around a severe performance issue with "Bobcat" (AMD Embedded APU)
DRC69799272012-06-13 01:21:29 +0000211processors. The MASKMOVDQU instruction, which was used by the libjpeg-turbo
212SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and
213it is painfully slow on Bobcat processors in particular. Eliminating the use
214of this instruction improved performance by an order of magnitude on Bobcat
215processors and by a small amount (typically 5%) on AMD desktop processors.
216
DRC575317b2012-06-15 22:00:47 +0000217[6] Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM
218platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such
219platforms.
220
DRCde37e072012-06-18 00:08:18 +0000221[7] Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms
222running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or
2234:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy
224upsampling would produce several incorrect columns of pixels at the right-hand
225side of the output image if each row in the output image was not evenly
226divisible by 16 bytes.
DRC8126d0c2012-06-15 21:54:45 +0000227
DRC112a0bb2012-06-28 23:25:34 +0000228[8] Fixed an issue whereby attempting to build the SIMD extensions with Xcode
2294.3 on OS X platforms would cause NASM to return numerous errors of the form
230"'%define' expects a macro identifier".
231
DRC73d74c12012-06-29 23:46:38 +0000232[9] Added flags to the TurboJPEG API that allow the caller to force the use of
233either the fast or the accurate DCT/IDCT algorithms in the underlying codec.
234
DRC27fb3fc2012-01-28 01:48:07 +0000235
DRC1ca924a2011-11-29 08:58:27 +00002361.2.0
237=====
238
239[1] Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system
240was not adding the current directory to the assembler include path, so YASM
241was not able to find jsimdcfg.inc.)
242
DRCebfe9e42011-12-01 10:58:36 +0000243[2] Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
244a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes.
245This was more of an annoyance than an actual bug, since it did not cause any
246actual run-time problems, but the issue showed up when running libjpeg-turbo in
247valgrind. See http://crbug.com/72399 for more information.
248
DRCab64b622011-12-18 16:29:35 +0000249[3] Added a compile-time macro (LIBJPEG_TURBO_VERSION) that can be used to
250check the version of libjpeg-turbo against which an application was compiled.
251
DRC67ce3b22011-12-19 02:21:03 +0000252[4] Added new RGBA/BGRA/ABGR/ARGB colorspace extension constants (libjpeg API)
253and pixel formats (TurboJPEG API), which allow applications to specify that,
254when decompressing to a 4-component RGB buffer, the unused byte should be set
255to 0xFF so that it can be interpreted as an opaque alpha channel.
256
DRCa7466c92012-01-26 22:20:31 +0000257[5] Fixed regression issue whereby DevIL failed to build against libjpeg-turbo
258because libjpeg-turbo's distributed version of jconfig.h contained an INLINE
259macro, which conflicted with a similar macro in DevIL. This macro is used only
260internally when building libjpeg-turbo, so it was moved into config.h.
261
DRC12781cb2012-01-27 01:23:20 +0000262[6] libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose
263K component is assigned a component ID of 1 instead of 4. Although these files
264are in violation of the spec, other JPEG implementations handle them
265correctly.
266
DRCc0526462012-02-10 01:44:55 +0000267[7] Added ARM v6 and ARM v7 architectures to libjpeg.a and libturbojpeg.a in
DRCa2a2cd62013-02-04 22:29:57 +0000268the official libjpeg-turbo binary package for OS X, so that those libraries can
269be used to build both OS X and iOS applications.
DRCc0526462012-02-10 01:44:55 +0000270
DRC1ca924a2011-11-29 08:58:27 +0000271
DRCf8e00552011-02-04 11:06:36 +00002721.1.90 (1.2 beta1)
273==================
274
DRC7bc3fb52011-10-28 06:45:53 +0000275[1] Added a Java wrapper for the TurboJPEG API. See java/README for more
276details.
DRCf8e00552011-02-04 11:06:36 +0000277
DRC7bc3fb52011-10-28 06:45:53 +0000278[2] The TurboJPEG API can now be used to scale down images during
279decompression.
DRCa3c30592011-02-07 08:06:16 +0000280
DRC15866ac2011-03-04 13:46:55 +0000281[3] Added SIMD routines for RGB-to-grayscale color conversion, which
282significantly improves the performance of grayscale JPEG compression from an
283RGB source image.
284
DRC3c21b082011-10-28 06:25:13 +0000285[4] Improved the performance of the C color conversion routines, which are used
286on platforms for which SIMD acceleration is not available.
DRC15866ac2011-03-04 13:46:55 +0000287
DRC3c21b082011-10-28 06:25:13 +0000288[5] Added a function to the TurboJPEG API that performs lossless transforms.
289This function is implemented using the same back end as jpegtran, but it
290performs transcoding entirely in memory and allows multiple transforms and/or
291crop operations to be batched together, so the source coefficients only need to
292be read once. This is useful when generating image tiles from a single source
293JPEG.
DRC15866ac2011-03-04 13:46:55 +0000294
DRC3c21b082011-10-28 06:25:13 +0000295[6] Added tests for the new TurboJPEG scaled decompression and lossless
DRC77fee432011-11-01 17:14:22 +0000296transform features to tjbench (the TurboJPEG benchmark, formerly called
297"jpgtest".)
DRC15866ac2011-03-04 13:46:55 +0000298
299[7] Added support for 4:4:0 (transposed 4:2:2) subsampling in TurboJPEG, which
300was necessary in order for it to read 4:2:2 JPEG files that had been losslessly
301transposed or rotated 90 degrees.
302
DRC67d1fc12011-05-24 14:13:01 +0000303[8] All legacy VirtualGL code has been re-factored, and this has allowed
304libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license.
DRCee269922011-04-26 23:46:38 +0000305
DRCf89dd1e2011-05-21 14:23:30 +0000306[9] libjpeg-turbo can now be built with YASM.
DRC56fb2372011-05-03 06:32:41 +0000307
DRCe5c6eb52011-08-17 20:59:56 +0000308[10] Added SIMD acceleration for ARM Linux and iOS platforms that support
309NEON instructions.
DRC321e0682011-05-03 08:47:43 +0000310
DRC3c21b082011-10-28 06:25:13 +0000311[11] Refactored the TurboJPEG C API and documented it using Doxygen. The
312TurboJPEG 1.2 API uses pixel formats to define the size and component order of
313the uncompressed source/destination images, and it includes a more efficient
314version of TJBUFSIZE() that computes a worst-case JPEG size based on the level
DRC5039d732013-01-21 23:42:12 +0000315of chrominance subsampling. The refactored implementation of the TurboJPEG API
DRC3c21b082011-10-28 06:25:13 +0000316now uses the libjpeg memory source and destination managers, which allows the
317TurboJPEG compressor to grow the JPEG buffer as necessary.
DRC9b28def2011-05-21 14:37:15 +0000318
DRCe9f9ec42011-05-25 06:02:50 +0000319[12] Eliminated errors in the output of jpegtran on Windows that occurred when
DRC7e3fd2f2011-05-25 06:04:43 +0000320the application was invoked using I/O redirection
321(jpegtran <input.jpg >output.jpg).
322
DRCb8c6ee32011-05-31 20:22:37 +0000323[13] The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding
DRC0571e172011-05-31 20:17:16 +0000324support in libjpeg-turbo v1.1.0 introduced several new error constants in
325jerror.h, and these were mistakenly enabled for all emulation modes, causing
DRCfa9ff8e2011-06-21 06:17:10 +0000326the error enum in libjpeg-turbo to sometimes have different values than the
327same enum in libjpeg. This represents an ABI incompatibility, and it caused
328problems with rare applications that took specific action based on a particular
329error value. The fix was to include the new error constants conditionally
330based on whether libjpeg v7 or v8 emulation was enabled.
DRC0571e172011-05-31 20:17:16 +0000331
DRCeed08612011-06-21 04:56:02 +0000332[14] Fixed an issue whereby Windows applications that used libjpeg-turbo would
DRCb7120ca2011-06-21 04:57:32 +0000333fail to compile if the Windows system headers were included before jpeglib.h.
334This issue was caused by a conflict in the definition of the INT32 type.
DRC6ca69532011-02-18 03:31:11 +0000335
DRC3c21b082011-10-28 06:25:13 +0000336[15] Fixed 32-bit supplementary package for amd64 Debian systems, which was
DRC68a086a2011-07-19 09:26:23 +0000337broken by enhancements to the packaging system in 1.1.
338
DRC3c21b082011-10-28 06:25:13 +0000339[16] When decompressing a JPEG image using an output colorspace of
DRCc08e8c12011-09-08 23:54:40 +0000340JCS_EXT_RGBX, JCS_EXT_BGRX, JCS_EXT_XBGR, or JCS_EXT_XRGB, libjpeg-turbo will
341now set the unused byte to 0xFF, which allows applications to interpret that
342byte as an alpha channel (0xFF = opaque).
343
DRCf8e00552011-02-04 11:06:36 +0000344
DRC6ee54592011-03-01 08:18:30 +00003451.1.1
346=====
347
348[1] Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated
349by tjEncodeYUV().
350
DRC8071c392011-04-17 15:29:17 +0000351[2] libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
352markers found in the middle of the JPEG data stream during decompression. It
353will now hand off decoding of a particular block to the unaccelerated Huffman
354decoder if an unexpected marker is found, so that the unaccelerated Huffman
355decoder can generate an appropriate warning.
DRC6ee54592011-03-01 08:18:30 +0000356
DRC47aaf6f2011-03-22 05:40:39 +0000357[3] Older versions of MinGW64 prefixed symbol names with underscores by
DRC1da78582011-03-22 09:34:01 +0000358default, which differed from the behavior of 64-bit Visual C++. MinGW64 1.0
359has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate
360this, the libjpeg-turbo SIMD function names are no longer prefixed with an
361underscore when building with MinGW64. This means that, when building
362libjpeg-turbo with older versions of MinGW64, you will now have to add
363-fno-leading-underscore to the CFLAGS.
364
DRCd8840112011-04-25 22:46:25 +0000365[4] Fixed a regression bug in the NSIS script that caused the Windows installer
366build to fail when using the Visual Studio IDE.
367
368[5] Fixed a bug in jpeg_read_coefficients() whereby it would not initialize
369cinfo->image_width and cinfo->image_height if libjpeg v7 or v8 emulation was
370enabled. This specifically caused the jpegoptim program to fail if it was
371linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8
372emulation.
373
DRC049aef52011-04-25 22:41:14 +0000374[6] Eliminated excessive I/O overhead that occurred when reading BMP files in
375cjpeg.
376
DRC5ee81f42011-05-02 00:35:50 +0000377[7] Eliminated errors in the output of cjpeg on Windows that occurred when the
DRC34a8e352011-05-10 22:14:38 +0000378application was invoked using I/O redirection (cjpeg <inputfile >output.jpg).
DRC5ee81f42011-05-02 00:35:50 +0000379
DRCf5c3bb32011-03-18 05:59:07 +0000380
DRC958b2c02011-01-28 08:00:40 +00003811.1.0
382=====
DRCfa1d1832011-01-26 05:35:20 +0000383
DRCa49c4e52011-02-18 20:50:08 +0000384[1] The algorithm used by the SIMD quantization function cannot produce correct
385results when the JPEG quality is >= 98 and the fast integer forward DCT is
386used. Thus, the non-SIMD quantization function is now used for those cases,
387and libjpeg-turbo should now produce identical output to libjpeg v6b in all
388cases.
DRCe1716b82011-02-18 03:19:43 +0000389
DRCa49c4e52011-02-18 20:50:08 +0000390[2] Despite the above, the fast integer forward DCT still degrades somewhat for
DRC5039d732013-01-21 23:42:12 +0000391JPEG qualities greater than 95, so the TurboJPEG wrapper will now automatically
392use the slow integer forward DCT when generating JPEG images of quality 96 or
393greater. This reduces compression performance by as much as 15% for these
394high-quality images but is necessary to ensure that the images are perceptually
395lossless. It also ensures that the library can avoid the performance pitfall
396created by [1].
DRCa49c4e52011-02-18 20:50:08 +0000397
398[3] Ported jpgtest.cxx to pure C to avoid the need for a C++ compiler.
399
400[4] Fixed visual artifacts in grayscale JPEG compression caused by a typo in
DRCd9ee65c2011-04-05 07:01:26 +0000401the RGB-to-luminance lookup tables.
DRC8ed7b812011-02-15 08:31:34 +0000402
DRC240d82f2011-02-19 00:00:34 +0000403[5] The Windows distribution packages now include the libjpeg run-time programs
404(cjpeg, etc.)
405
DRC9cd2c422011-02-19 17:52:45 +0000406[6] All packages now include jpgtest.
DRC240d82f2011-02-19 00:00:34 +0000407
DRCe4d9b5b2011-02-25 06:17:17 +0000408[7] The TurboJPEG dynamic library now uses versioned symbols.
409
410[8] Added two new TurboJPEG API functions, tjEncodeYUV() and
411tjDecompressToYUV(), to replace the somewhat hackish TJ_YUV flag.
412
DRC2d94e262011-01-25 06:52:31 +0000413
DRC958b2c02011-01-28 08:00:40 +00004141.0.90 (1.1 beta1)
415==================
DRC766dc5c2010-10-12 02:50:18 +0000416
DRCf38eee02011-02-18 07:00:38 +0000417[1] Added emulation of the libjpeg v7 and v8 APIs and ABIs. See
DRCefa618e2010-10-18 08:41:11 +0000418README-turbo.txt for more details. This feature was sponsored by CamTrace SAS.
419
420[2] Created a new CMake-based build system for the Visual C++ and MinGW builds.
DRC766dc5c2010-10-12 02:50:18 +0000421
DRC2c62da32012-01-17 22:55:03 +0000422[3] Grayscale bitmaps can now be compressed from/decompressed to using the
423TurboJPEG API.
DRC09854f52010-11-04 22:39:59 +0000424
DRC01e69092011-01-06 01:19:43 +0000425[4] jpgtest can now be used to test decompression performance with existing
426JPEG images.
DRCe89bbae2010-11-12 10:18:08 +0000427
DRCd1c281a2010-11-17 22:44:40 +0000428[5] If the default install prefix (/opt/libjpeg-turbo) is used, then
429'make install' now creates /opt/libjpeg-turbo/lib32 and
430/opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary
431packages.
432
DRCec311932010-11-22 19:51:42 +0000433[6] All symbols in the libjpeg-turbo dynamic library are now versioned, even
434when the library is built with libjpeg v6b emulation.
435
DRC01e69092011-01-06 01:19:43 +0000436[7] Added arithmetic encoding and decoding support (can be disabled with
DRC245cfdf2010-11-23 17:11:06 +0000437configure or CMake options)
DRC66f97e62010-11-23 05:49:54 +0000438
DRC2c62da32012-01-17 22:55:03 +0000439[8] Added a TJ_YUV flag to the TurboJPEG API, which causes both the compressor
440and decompressor to output planar YUV images.
DRCfbb67472010-11-24 04:02:37 +0000441
DRC2c62da32012-01-17 22:55:03 +0000442[9] Added an extended version of tjDecompressHeader() to the TurboJPEG API,
443which allows the caller to determine the type of subsampling used in a JPEG
444image.
DRC50c657b2010-12-14 01:23:16 +0000445
DRC958b2c02011-01-28 08:00:40 +0000446[10] Added further protections against invalid Huffman codes.
DRCfa1d1832011-01-26 05:35:20 +0000447
DRC766dc5c2010-10-12 02:50:18 +0000448
DRC958b2c02011-01-28 08:00:40 +00004491.0.1
450=====
DRC0fbb28e2010-07-30 17:15:52 +0000451
452[1] The Huffman decoder will now handle erroneous Huffman codes (for instance,
453from a corrupt JPEG image.) Previously, these would cause libjpeg-turbo to
454crash under certain circumstances.
455
DRC81a50f72012-01-17 22:56:22 +0000456[2] Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to
DRC025a2792010-08-07 16:27:56 +0000457be used instead of 4:2:0 when decompressing JPEG images using SSE2 code.
DRC30959712010-08-07 16:06:56 +0000458
DRCbdb12882010-08-21 21:14:17 +0000459[3] configure script will now automatically determine whether the
460INCOMPLETE_TYPES_BROKEN macro should be defined.
461
DRC0fbb28e2010-07-30 17:15:52 +0000462
DRC958b2c02011-01-28 08:00:40 +00004631.0.0
464=====
DRC49597872010-05-17 20:47:57 +0000465
DRCc773d102010-06-05 06:58:22 +0000466[1] 2983700: Further FreeBSD build tweaks (no longer necessary to specify
467--host when configuring on a 64-bit system)
DRC49597872010-05-17 20:47:57 +0000468
DRCd5e964c2013-01-10 11:47:39 +0000469[2] Created symlinks in the Unix/Linux packages so that the TurboJPEG
DRCf12c7db2010-05-18 19:04:47 +0000470include file can always be found in /opt/libjpeg-turbo/include, the 32-bit
471static libraries can always be found in /opt/libjpeg-turbo/lib32, and the
47264-bit static libraries can always be found in /opt/libjpeg-turbo/lib64.
473
DRC4bf3b582010-06-05 01:03:23 +0000474[3] The Unix/Linux distribution packages now include the libjpeg run-time
475programs (cjpeg, etc.) and man pages.
476
DRC81a50f72012-01-17 22:56:22 +0000477[4] Created a 32-bit supplementary package for amd64 Debian systems, which
DRC4bf3b582010-06-05 01:03:23 +0000478contains just the 32-bit libjpeg-turbo libraries.
479
480[5] Moved the libraries from */lib32 to */lib in the i386 Debian package.
481
DRCdf3337c2010-07-02 09:13:58 +0000482[6] Include distribution package for Cygwin
DRC4bf3b582010-06-05 01:03:23 +0000483
DRCdf3337c2010-07-02 09:13:58 +0000484[7] No longer necessary to specify --without-simd on non-x86 architectures, and
DRC38ccf852010-06-10 19:49:49 +0000485unit tests now work on those architectures.
486
DRC49597872010-05-17 20:47:57 +0000487
DRC958b2c02011-01-28 08:00:40 +00004880.0.93
489======
DRC0f413b22010-04-06 20:05:39 +0000490
DRCc773d102010-06-05 06:58:22 +0000491[1] 2982659, Fixed x86-64 build on FreeBSD systems
DRC0f413b22010-04-06 20:05:39 +0000492
DRCc773d102010-06-05 06:58:22 +0000493[2] 2988188: Added support for Windows 64-bit systems
DRC1a2219e2010-05-10 20:03:36 +0000494
DRC0f413b22010-04-06 20:05:39 +0000495
DRC958b2c02011-01-28 08:00:40 +00004960.0.91
497======
DRCae19bf62010-03-15 11:40:31 +0000498
499[1] Added documentation to .deb packages
500
501[2] 2968313: Fixed data corruption issues when decompressing large JPEG images
502and/or using buffered I/O with the libjpeg-turbo decompressor
DRC958b2c02011-01-28 08:00:40 +0000503
504
5050.0.90
506======
507
508Initial release