blob: d376ace7851b9f7e96160937a39760214bf5294e [file] [log] [blame]
DRCac9a92e2014-04-20 07:22:21 +000011.3.2
DRCe0419b52012-07-03 20:01:31 +00002=====
3
DRCac9a92e2014-04-20 07:22:21 +00004[1] Worked around an issue with Visual C++ 2010 and later that caused incorrect
DRCbeb0b332014-04-20 07:36:33 +00005pixels to be generated when decompressing a JPEG image to a 256-color bitmap,
6if compiler optimization was enabled when libjpeg-turbo was built. This caused
7the regression tests to fail when doing a release build under Visual C++ 2010
8and later.
9
DRCe0419b52012-07-03 20:01:31 +000010
DRCdadebe92013-08-11 23:04:34 +0000111.3.1
12=====
13
14[1] On Un*x systems, 'make install' now installs the libjpeg-turbo libraries
15into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86,
16and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just
17x86-64. You can override this by overriding either the 'prefix' or 'libdir'
18configure variables.
19
DRC4d877932013-09-19 22:55:57 +000020[2] The Windows installer now places a copy of the TurboJPEG DLLs in the same
21directory as the rest of the libjpeg-turbo binaries. This was mainly done
22to support TurboVNC 1.3, which bundles the DLLs in its Windows installation.
23When using a 32-bit version of CMake on 64-bit Windows, it is impossible to
24access the c:\WINDOWS\system32 directory, which made it impossible for the
25TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL.
26
DRCcadabd42013-09-28 03:10:31 +000027[3] Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic
28entropy coding (by passing arguments of -progressive -arithmetic to cjpeg or
29jpegtran, for instance) would result in an error, "Requested feature was
30omitted at compile time".
DRC1370f102013-09-24 03:21:38 +000031
DRC7ebf2942013-11-21 18:32:48 +000032[4] Fixed a couple of issues whereby malformed JPEG images would cause
DRC43d8cf42013-11-21 18:34:39 +000033libjpeg-turbo to use uninitialized memory during decompression.
34
DRC2c0c8072014-02-11 09:56:12 +000035[5] Fixed an error ("Buffer passed to JPEG library is too small") that occurred
36when calling the TurboJPEG YUV encoding function with a very small (< 5x5)
37source image, and added a unit test to check for this error.
38
DRCd45c5492014-03-11 06:21:46 +000039[6] The Java classes should now build properly under Visual Studio 2010 and
40later.
41
DRCc8b02262014-03-22 20:42:01 +000042[7] Fixed an issue that prevented SRPMs generated using the in-tree packaging
43tools from being rebuilt on certain newer Linux distributions.
44
45[8] Numerous minor fixes to eliminate compilation and build/packaging system
46warnings, fix cosmetic issues, improve documentation clarity, and other general
47source cleanup.
48
DRCdadebe92013-08-11 23:04:34 +000049
DRC0bf58f22013-02-06 23:51:08 +0000501.3.0
51=====
52
53[1] 'make test' now works properly on FreeBSD, and it no longer requires the
54md5sum executable to be present on other Un*x platforms.
55
DRCd7a642b2013-04-24 06:40:25 +000056[2] Overhauled the packaging system:
DRC764e1e22013-04-19 04:25:14 +000057-- To avoid conflict with vendor-supplied libjpeg-turbo packages, the
58official RPMs and DEBs for libjpeg-turbo have been renamed to
DRCd7a642b2013-04-24 06:40:25 +000059"libjpeg-turbo-official".
60-- The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the
61official Linux and Mac packages, to avoid conflict with vendor-supplied
62packages and also to streamline the packaging system.
63-- Release packages are now created with the directory structure defined
64by the configure variables "prefix", "bindir", "libdir", etc. (Un*x) or by the
65CMAKE_INSTALL_PREFIX variable (Windows.) The exception is that the docs are
66always located under the system default documentation directory on Un*x and Mac
67systems, and on Windows, the TurboJPEG DLL is always located in the Windows
68system directory.
DRC764e1e22013-04-19 04:25:14 +000069-- To avoid confusion, official libjpeg-turbo packages on Linux/Unix platforms
70(except for Mac) will always install the 32-bit libraries in
71/opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64.
DRCd7a642b2013-04-24 06:40:25 +000072-- Fixed an issue whereby, in some cases, the libjpeg-turbo executables on Un*x
73systems were not properly linking with the shared libraries installed by the
74same package.
75-- Fixed an issue whereby building the "installer" target on Windows when
76WITH_JAVA=1 would fail if the TurboJPEG JAR had not been previously built.
77-- Building the "install" target on Windows now installs files into the same
78places that the installer does.
DRC764e1e22013-04-19 04:25:14 +000079
DRC4c17a452013-04-25 08:55:31 +000080[3] Fixed a Huffman encoder bug that prevented I/O suspension from working
81properly.
82
DRC0bf58f22013-02-06 23:51:08 +000083
DRC84f71222012-12-31 09:44:31 +0000841.2.90 (1.3 beta1)
85==================
DRC27fb3fc2012-01-28 01:48:07 +000086
87[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 +00008811/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing. Note that the IDCT will
89not be SIMD-accelerated when using any of these new scaling factors.
DRC27fb3fc2012-01-28 01:48:07 +000090
DRC575317b2012-06-15 22:00:47 +000091[2] The TurboJPEG dynamic library is now versioned. It was not strictly
DRCfd407772012-03-23 03:24:39 +000092necessary to do so, because TurboJPEG uses versioned symbols, and if a function
93changes in an ABI-incompatible way, that function is renamed and a legacy
94function is provided to maintain backward compatibility. However, certain
DRC5a84a0e2013-02-14 07:31:35 +000095Linux distro maintainers have a policy against accepting any library that isn't
96versioned.
DRCfd407772012-03-23 03:24:39 +000097
DRCfac3bea2012-09-24 02:27:55 +000098[3] Extended the TurboJPEG Java API so that it can be used to compress a JPEG
99image from and decompress a JPEG image to an arbitrary position in a large
100image buffer.
DRC575317b2012-06-15 22:00:47 +0000101
DRC21868092012-07-03 20:02:49 +0000102[4] The tjDecompressToYUV() function now supports the TJFLAG_FASTDCT flag.
DRCa9b646c2012-03-11 22:06:54 +0000103
DRCa394bf72012-08-07 18:44:24 +0000104[5] The 32-bit supplementary package for amd64 Debian systems now provides
DRCa9b646c2012-03-11 22:06:54 +0000105symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32.
106This allows those libraries to be used on MultiArch-compatible systems (such as
107Ubuntu 11 and later) without setting the linker path.
108
DRC61e13412012-08-24 02:44:39 +0000109[6] The TurboJPEG Java wrapper should now find the JNI library on Mac systems
110without having to pass -Djava.library.path=/usr/lib to java.
111
DRCd9d1d672012-10-02 04:20:43 +0000112[7] TJBench has been ported to Java to provide a convenient way of validating
113the performance of the TurboJPEG Java API. It can be run with
114'java -cp turbojpeg.jar TJBench'.
115
DRCf73a27c2013-01-01 10:25:43 +0000116[8] cjpeg can now be used to generate JPEG files with the RGB colorspace
117(feature ported from jpeg-8d.)
118
DRC8cbf8932013-01-01 10:44:00 +0000119[9] The width and height in the -crop argument passed to jpegtran can now be
120suffixed with "f" to indicate that, when the upper left corner of the cropping
121region is automatically moved to the nearest iMCU boundary, the bottom right
122corner should be moved by the same amount. In other words, this feature causes
123jpegtran to strictly honor the specified width/height rather than the specified
124bottom right corner (feature ported from jpeg-8d.)
125
DRCf37e4da2013-01-01 10:52:29 +0000126[10] JPEG files using the RGB colorspace can now be decompressed into grayscale
127images (feature ported from jpeg-8d.)
128
DRC00c2cf32013-01-13 12:12:53 +0000129[11] Fixed a regression caused by 1.2.1[7] whereby the build would fail with
DRCb87a0b42013-01-13 12:15:58 +0000130multiple "Mismatch in operand sizes" errors when attempting to build the x86
131SIMD code with NASM 0.98.
132
DRCab706232013-01-18 23:42:31 +0000133[12] The in-memory source/destination managers (jpeg_mem_src() and
134jpeg_mem_dest()) are now included by default when building libjpeg-turbo with
135libjpeg v6b or v7 emulation, so that programs can take advantage of these
136functions without requiring the use of the backward-incompatible libjpeg v8
137ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been
138incremented by 1 to reflect this. You can disable this feature with a
139configure/CMake switch in order to retain strict API/ABI compatibility with the
140libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See
141README-turbo.txt for more details.
142
DRCa2a2cd62013-02-04 22:29:57 +0000143[13] Added ARM v7s architecture to libjpeg.a and libturbojpeg.a in the official
144libjpeg-turbo binary package for OS X, so that those libraries can be used to
145build applications that leverage the faster CPUs in the iPhone 5 and iPad 4.
146
DRC575317b2012-06-15 22:00:47 +0000147
1481.2.1
149=====
150
151[1] Creating or decoding a JPEG file that uses the RGB colorspace should now
152properly work when the input or output colorspace is one of the libjpeg-turbo
153colorspace extensions.
154
155[2] When libjpeg-turbo was built without SIMD support and merged (non-fancy)
156upsampling was used along with an alpha-enabled colorspace during
157decompression, the unused byte of the decompressed pixels was not being set to
1580xFF. This has been fixed. TJUnitTest has also been extended to test for the
159correct behavior of the colorspace extensions when merged upsampling is used.
160
161[3] Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the
DRC4f240162012-04-26 19:50:37 +0000162upper 64 bits of xmm6 and xmm7 on Win64 platforms, which violated the Win64
163calling conventions.
164
DRC575317b2012-06-15 22:00:47 +0000165[4] Fixed a regression caused by 1.2.0[6] whereby decompressing corrupt JPEG
DRCdd2b6512012-05-30 20:36:42 +0000166images (specifically, images in which the component count was erroneously set
167to a large value) would cause libjpeg-turbo to segfault.
168
DRC575317b2012-06-15 22:00:47 +0000169[5] Worked around a severe performance issue with "Bobcat" (AMD Embedded APU)
DRC69799272012-06-13 01:21:29 +0000170processors. The MASKMOVDQU instruction, which was used by the libjpeg-turbo
171SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and
172it is painfully slow on Bobcat processors in particular. Eliminating the use
173of this instruction improved performance by an order of magnitude on Bobcat
174processors and by a small amount (typically 5%) on AMD desktop processors.
175
DRC575317b2012-06-15 22:00:47 +0000176[6] Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM
177platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such
178platforms.
179
DRCde37e072012-06-18 00:08:18 +0000180[7] Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms
181running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or
1824:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy
183upsampling would produce several incorrect columns of pixels at the right-hand
184side of the output image if each row in the output image was not evenly
185divisible by 16 bytes.
DRC8126d0c2012-06-15 21:54:45 +0000186
DRC112a0bb2012-06-28 23:25:34 +0000187[8] Fixed an issue whereby attempting to build the SIMD extensions with Xcode
1884.3 on OS X platforms would cause NASM to return numerous errors of the form
189"'%define' expects a macro identifier".
190
DRC73d74c12012-06-29 23:46:38 +0000191[9] Added flags to the TurboJPEG API that allow the caller to force the use of
192either the fast or the accurate DCT/IDCT algorithms in the underlying codec.
193
DRC27fb3fc2012-01-28 01:48:07 +0000194
DRC1ca924a2011-11-29 08:58:27 +00001951.2.0
196=====
197
198[1] Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system
199was not adding the current directory to the assembler include path, so YASM
200was not able to find jsimdcfg.inc.)
201
DRCebfe9e42011-12-01 10:58:36 +0000202[2] Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
203a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes.
204This was more of an annoyance than an actual bug, since it did not cause any
205actual run-time problems, but the issue showed up when running libjpeg-turbo in
206valgrind. See http://crbug.com/72399 for more information.
207
DRCab64b622011-12-18 16:29:35 +0000208[3] Added a compile-time macro (LIBJPEG_TURBO_VERSION) that can be used to
209check the version of libjpeg-turbo against which an application was compiled.
210
DRC67ce3b22011-12-19 02:21:03 +0000211[4] Added new RGBA/BGRA/ABGR/ARGB colorspace extension constants (libjpeg API)
212and pixel formats (TurboJPEG API), which allow applications to specify that,
213when decompressing to a 4-component RGB buffer, the unused byte should be set
214to 0xFF so that it can be interpreted as an opaque alpha channel.
215
DRCa7466c92012-01-26 22:20:31 +0000216[5] Fixed regression issue whereby DevIL failed to build against libjpeg-turbo
217because libjpeg-turbo's distributed version of jconfig.h contained an INLINE
218macro, which conflicted with a similar macro in DevIL. This macro is used only
219internally when building libjpeg-turbo, so it was moved into config.h.
220
DRC12781cb2012-01-27 01:23:20 +0000221[6] libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose
222K component is assigned a component ID of 1 instead of 4. Although these files
223are in violation of the spec, other JPEG implementations handle them
224correctly.
225
DRCc0526462012-02-10 01:44:55 +0000226[7] Added ARM v6 and ARM v7 architectures to libjpeg.a and libturbojpeg.a in
DRCa2a2cd62013-02-04 22:29:57 +0000227the official libjpeg-turbo binary package for OS X, so that those libraries can
228be used to build both OS X and iOS applications.
DRCc0526462012-02-10 01:44:55 +0000229
DRC1ca924a2011-11-29 08:58:27 +0000230
DRCf8e00552011-02-04 11:06:36 +00002311.1.90 (1.2 beta1)
232==================
233
DRC7bc3fb52011-10-28 06:45:53 +0000234[1] Added a Java wrapper for the TurboJPEG API. See java/README for more
235details.
DRCf8e00552011-02-04 11:06:36 +0000236
DRC7bc3fb52011-10-28 06:45:53 +0000237[2] The TurboJPEG API can now be used to scale down images during
238decompression.
DRCa3c30592011-02-07 08:06:16 +0000239
DRC15866ac2011-03-04 13:46:55 +0000240[3] Added SIMD routines for RGB-to-grayscale color conversion, which
241significantly improves the performance of grayscale JPEG compression from an
242RGB source image.
243
DRC3c21b082011-10-28 06:25:13 +0000244[4] Improved the performance of the C color conversion routines, which are used
245on platforms for which SIMD acceleration is not available.
DRC15866ac2011-03-04 13:46:55 +0000246
DRC3c21b082011-10-28 06:25:13 +0000247[5] Added a function to the TurboJPEG API that performs lossless transforms.
248This function is implemented using the same back end as jpegtran, but it
249performs transcoding entirely in memory and allows multiple transforms and/or
250crop operations to be batched together, so the source coefficients only need to
251be read once. This is useful when generating image tiles from a single source
252JPEG.
DRC15866ac2011-03-04 13:46:55 +0000253
DRC3c21b082011-10-28 06:25:13 +0000254[6] Added tests for the new TurboJPEG scaled decompression and lossless
DRC77fee432011-11-01 17:14:22 +0000255transform features to tjbench (the TurboJPEG benchmark, formerly called
256"jpgtest".)
DRC15866ac2011-03-04 13:46:55 +0000257
258[7] Added support for 4:4:0 (transposed 4:2:2) subsampling in TurboJPEG, which
259was necessary in order for it to read 4:2:2 JPEG files that had been losslessly
260transposed or rotated 90 degrees.
261
DRC67d1fc12011-05-24 14:13:01 +0000262[8] All legacy VirtualGL code has been re-factored, and this has allowed
263libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license.
DRCee269922011-04-26 23:46:38 +0000264
DRCf89dd1e2011-05-21 14:23:30 +0000265[9] libjpeg-turbo can now be built with YASM.
DRC56fb2372011-05-03 06:32:41 +0000266
DRCe5c6eb52011-08-17 20:59:56 +0000267[10] Added SIMD acceleration for ARM Linux and iOS platforms that support
268NEON instructions.
DRC321e0682011-05-03 08:47:43 +0000269
DRC3c21b082011-10-28 06:25:13 +0000270[11] Refactored the TurboJPEG C API and documented it using Doxygen. The
271TurboJPEG 1.2 API uses pixel formats to define the size and component order of
272the uncompressed source/destination images, and it includes a more efficient
273version of TJBUFSIZE() that computes a worst-case JPEG size based on the level
DRC5039d732013-01-21 23:42:12 +0000274of chrominance subsampling. The refactored implementation of the TurboJPEG API
DRC3c21b082011-10-28 06:25:13 +0000275now uses the libjpeg memory source and destination managers, which allows the
276TurboJPEG compressor to grow the JPEG buffer as necessary.
DRC9b28def2011-05-21 14:37:15 +0000277
DRCe9f9ec42011-05-25 06:02:50 +0000278[12] Eliminated errors in the output of jpegtran on Windows that occurred when
DRC7e3fd2f2011-05-25 06:04:43 +0000279the application was invoked using I/O redirection
280(jpegtran <input.jpg >output.jpg).
281
DRCb8c6ee32011-05-31 20:22:37 +0000282[13] The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding
DRC0571e172011-05-31 20:17:16 +0000283support in libjpeg-turbo v1.1.0 introduced several new error constants in
284jerror.h, and these were mistakenly enabled for all emulation modes, causing
DRCfa9ff8e2011-06-21 06:17:10 +0000285the error enum in libjpeg-turbo to sometimes have different values than the
286same enum in libjpeg. This represents an ABI incompatibility, and it caused
287problems with rare applications that took specific action based on a particular
288error value. The fix was to include the new error constants conditionally
289based on whether libjpeg v7 or v8 emulation was enabled.
DRC0571e172011-05-31 20:17:16 +0000290
DRCeed08612011-06-21 04:56:02 +0000291[14] Fixed an issue whereby Windows applications that used libjpeg-turbo would
DRCb7120ca2011-06-21 04:57:32 +0000292fail to compile if the Windows system headers were included before jpeglib.h.
293This issue was caused by a conflict in the definition of the INT32 type.
DRC6ca69532011-02-18 03:31:11 +0000294
DRC3c21b082011-10-28 06:25:13 +0000295[15] Fixed 32-bit supplementary package for amd64 Debian systems, which was
DRC68a086a2011-07-19 09:26:23 +0000296broken by enhancements to the packaging system in 1.1.
297
DRC3c21b082011-10-28 06:25:13 +0000298[16] When decompressing a JPEG image using an output colorspace of
DRCc08e8c12011-09-08 23:54:40 +0000299JCS_EXT_RGBX, JCS_EXT_BGRX, JCS_EXT_XBGR, or JCS_EXT_XRGB, libjpeg-turbo will
300now set the unused byte to 0xFF, which allows applications to interpret that
301byte as an alpha channel (0xFF = opaque).
302
DRCf8e00552011-02-04 11:06:36 +0000303
DRC6ee54592011-03-01 08:18:30 +00003041.1.1
305=====
306
307[1] Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated
308by tjEncodeYUV().
309
DRC8071c392011-04-17 15:29:17 +0000310[2] libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
311markers found in the middle of the JPEG data stream during decompression. It
312will now hand off decoding of a particular block to the unaccelerated Huffman
313decoder if an unexpected marker is found, so that the unaccelerated Huffman
314decoder can generate an appropriate warning.
DRC6ee54592011-03-01 08:18:30 +0000315
DRC47aaf6f2011-03-22 05:40:39 +0000316[3] Older versions of MinGW64 prefixed symbol names with underscores by
DRC1da78582011-03-22 09:34:01 +0000317default, which differed from the behavior of 64-bit Visual C++. MinGW64 1.0
318has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate
319this, the libjpeg-turbo SIMD function names are no longer prefixed with an
320underscore when building with MinGW64. This means that, when building
321libjpeg-turbo with older versions of MinGW64, you will now have to add
322-fno-leading-underscore to the CFLAGS.
323
DRCd8840112011-04-25 22:46:25 +0000324[4] Fixed a regression bug in the NSIS script that caused the Windows installer
325build to fail when using the Visual Studio IDE.
326
327[5] Fixed a bug in jpeg_read_coefficients() whereby it would not initialize
328cinfo->image_width and cinfo->image_height if libjpeg v7 or v8 emulation was
329enabled. This specifically caused the jpegoptim program to fail if it was
330linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8
331emulation.
332
DRC049aef52011-04-25 22:41:14 +0000333[6] Eliminated excessive I/O overhead that occurred when reading BMP files in
334cjpeg.
335
DRC5ee81f42011-05-02 00:35:50 +0000336[7] Eliminated errors in the output of cjpeg on Windows that occurred when the
DRC34a8e352011-05-10 22:14:38 +0000337application was invoked using I/O redirection (cjpeg <inputfile >output.jpg).
DRC5ee81f42011-05-02 00:35:50 +0000338
DRCf5c3bb32011-03-18 05:59:07 +0000339
DRC958b2c02011-01-28 08:00:40 +00003401.1.0
341=====
DRCfa1d1832011-01-26 05:35:20 +0000342
DRCa49c4e52011-02-18 20:50:08 +0000343[1] The algorithm used by the SIMD quantization function cannot produce correct
344results when the JPEG quality is >= 98 and the fast integer forward DCT is
345used. Thus, the non-SIMD quantization function is now used for those cases,
346and libjpeg-turbo should now produce identical output to libjpeg v6b in all
347cases.
DRCe1716b82011-02-18 03:19:43 +0000348
DRCa49c4e52011-02-18 20:50:08 +0000349[2] Despite the above, the fast integer forward DCT still degrades somewhat for
DRC5039d732013-01-21 23:42:12 +0000350JPEG qualities greater than 95, so the TurboJPEG wrapper will now automatically
351use the slow integer forward DCT when generating JPEG images of quality 96 or
352greater. This reduces compression performance by as much as 15% for these
353high-quality images but is necessary to ensure that the images are perceptually
354lossless. It also ensures that the library can avoid the performance pitfall
355created by [1].
DRCa49c4e52011-02-18 20:50:08 +0000356
357[3] Ported jpgtest.cxx to pure C to avoid the need for a C++ compiler.
358
359[4] Fixed visual artifacts in grayscale JPEG compression caused by a typo in
DRCd9ee65c2011-04-05 07:01:26 +0000360the RGB-to-luminance lookup tables.
DRC8ed7b812011-02-15 08:31:34 +0000361
DRC240d82f2011-02-19 00:00:34 +0000362[5] The Windows distribution packages now include the libjpeg run-time programs
363(cjpeg, etc.)
364
DRC9cd2c422011-02-19 17:52:45 +0000365[6] All packages now include jpgtest.
DRC240d82f2011-02-19 00:00:34 +0000366
DRCe4d9b5b2011-02-25 06:17:17 +0000367[7] The TurboJPEG dynamic library now uses versioned symbols.
368
369[8] Added two new TurboJPEG API functions, tjEncodeYUV() and
370tjDecompressToYUV(), to replace the somewhat hackish TJ_YUV flag.
371
DRC2d94e262011-01-25 06:52:31 +0000372
DRC958b2c02011-01-28 08:00:40 +00003731.0.90 (1.1 beta1)
374==================
DRC766dc5c2010-10-12 02:50:18 +0000375
DRCf38eee02011-02-18 07:00:38 +0000376[1] Added emulation of the libjpeg v7 and v8 APIs and ABIs. See
DRCefa618e2010-10-18 08:41:11 +0000377README-turbo.txt for more details. This feature was sponsored by CamTrace SAS.
378
379[2] Created a new CMake-based build system for the Visual C++ and MinGW builds.
DRC766dc5c2010-10-12 02:50:18 +0000380
DRC2c62da32012-01-17 22:55:03 +0000381[3] Grayscale bitmaps can now be compressed from/decompressed to using the
382TurboJPEG API.
DRC09854f52010-11-04 22:39:59 +0000383
DRC01e69092011-01-06 01:19:43 +0000384[4] jpgtest can now be used to test decompression performance with existing
385JPEG images.
DRCe89bbae2010-11-12 10:18:08 +0000386
DRCd1c281a2010-11-17 22:44:40 +0000387[5] If the default install prefix (/opt/libjpeg-turbo) is used, then
388'make install' now creates /opt/libjpeg-turbo/lib32 and
389/opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary
390packages.
391
DRCec311932010-11-22 19:51:42 +0000392[6] All symbols in the libjpeg-turbo dynamic library are now versioned, even
393when the library is built with libjpeg v6b emulation.
394
DRC01e69092011-01-06 01:19:43 +0000395[7] Added arithmetic encoding and decoding support (can be disabled with
DRC245cfdf2010-11-23 17:11:06 +0000396configure or CMake options)
DRC66f97e62010-11-23 05:49:54 +0000397
DRC2c62da32012-01-17 22:55:03 +0000398[8] Added a TJ_YUV flag to the TurboJPEG API, which causes both the compressor
399and decompressor to output planar YUV images.
DRCfbb67472010-11-24 04:02:37 +0000400
DRC2c62da32012-01-17 22:55:03 +0000401[9] Added an extended version of tjDecompressHeader() to the TurboJPEG API,
402which allows the caller to determine the type of subsampling used in a JPEG
403image.
DRC50c657b2010-12-14 01:23:16 +0000404
DRC958b2c02011-01-28 08:00:40 +0000405[10] Added further protections against invalid Huffman codes.
DRCfa1d1832011-01-26 05:35:20 +0000406
DRC766dc5c2010-10-12 02:50:18 +0000407
DRC958b2c02011-01-28 08:00:40 +00004081.0.1
409=====
DRC0fbb28e2010-07-30 17:15:52 +0000410
411[1] The Huffman decoder will now handle erroneous Huffman codes (for instance,
412from a corrupt JPEG image.) Previously, these would cause libjpeg-turbo to
413crash under certain circumstances.
414
DRC81a50f72012-01-17 22:56:22 +0000415[2] Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to
DRC025a2792010-08-07 16:27:56 +0000416be used instead of 4:2:0 when decompressing JPEG images using SSE2 code.
DRC30959712010-08-07 16:06:56 +0000417
DRCbdb12882010-08-21 21:14:17 +0000418[3] configure script will now automatically determine whether the
419INCOMPLETE_TYPES_BROKEN macro should be defined.
420
DRC0fbb28e2010-07-30 17:15:52 +0000421
DRC958b2c02011-01-28 08:00:40 +00004221.0.0
423=====
DRC49597872010-05-17 20:47:57 +0000424
DRCc773d102010-06-05 06:58:22 +0000425[1] 2983700: Further FreeBSD build tweaks (no longer necessary to specify
426--host when configuring on a 64-bit system)
DRC49597872010-05-17 20:47:57 +0000427
DRCd5e964c2013-01-10 11:47:39 +0000428[2] Created symlinks in the Unix/Linux packages so that the TurboJPEG
DRCf12c7db2010-05-18 19:04:47 +0000429include file can always be found in /opt/libjpeg-turbo/include, the 32-bit
430static libraries can always be found in /opt/libjpeg-turbo/lib32, and the
43164-bit static libraries can always be found in /opt/libjpeg-turbo/lib64.
432
DRC4bf3b582010-06-05 01:03:23 +0000433[3] The Unix/Linux distribution packages now include the libjpeg run-time
434programs (cjpeg, etc.) and man pages.
435
DRC81a50f72012-01-17 22:56:22 +0000436[4] Created a 32-bit supplementary package for amd64 Debian systems, which
DRC4bf3b582010-06-05 01:03:23 +0000437contains just the 32-bit libjpeg-turbo libraries.
438
439[5] Moved the libraries from */lib32 to */lib in the i386 Debian package.
440
DRCdf3337c2010-07-02 09:13:58 +0000441[6] Include distribution package for Cygwin
DRC4bf3b582010-06-05 01:03:23 +0000442
DRCdf3337c2010-07-02 09:13:58 +0000443[7] No longer necessary to specify --without-simd on non-x86 architectures, and
DRC38ccf852010-06-10 19:49:49 +0000444unit tests now work on those architectures.
445
DRC49597872010-05-17 20:47:57 +0000446
DRC958b2c02011-01-28 08:00:40 +00004470.0.93
448======
DRC0f413b22010-04-06 20:05:39 +0000449
DRCc773d102010-06-05 06:58:22 +0000450[1] 2982659, Fixed x86-64 build on FreeBSD systems
DRC0f413b22010-04-06 20:05:39 +0000451
DRCc773d102010-06-05 06:58:22 +0000452[2] 2988188: Added support for Windows 64-bit systems
DRC1a2219e2010-05-10 20:03:36 +0000453
DRC0f413b22010-04-06 20:05:39 +0000454
DRC958b2c02011-01-28 08:00:40 +00004550.0.91
456======
DRCae19bf62010-03-15 11:40:31 +0000457
458[1] Added documentation to .deb packages
459
460[2] 2968313: Fixed data corruption issues when decompressing large JPEG images
461and/or using buffered I/O with the libjpeg-turbo decompressor
DRC958b2c02011-01-28 08:00:40 +0000462
463
4640.0.90
465======
466
467Initial release