Bump to 2.0.6
[platform/upstream/libjpeg-turbo.git] / ChangeLog.md
1 2.0.6
2 =====
3
4 ### Significant changes relative to 2.0.5:
5
6 1. Fixed "using JNI after critical get" errors that occurred on Android
7 platforms when using any of the YUV encoding/compression/decompression/decoding
8 methods in the TurboJPEG Java API.
9
10 2. Fixed or worked around multiple issues with `jpeg_skip_scanlines()`:
11
12      - Fixed segfaults or "Corrupt JPEG data: premature end of data segment"
13 errors in `jpeg_skip_scanlines()` that occurred when decompressing 4:2:2 or
14 4:2:0 JPEG images using merged (non-fancy) upsampling/color conversion (that
15 is, when setting `cinfo.do_fancy_upsampling` to `FALSE`.)  2.0.0[6] was a
16 similar fix, but it did not cover all cases.
17      - `jpeg_skip_scanlines()` now throws an error if two-pass color
18 quantization is enabled.  Two-pass color quantization never worked properly
19 with `jpeg_skip_scanlines()`, and the issues could not readily be fixed.
20      - Fixed an issue whereby `jpeg_skip_scanlines()` always returned 0 when
21 skipping past the end of an image.
22
23 3. The Arm 64-bit (Armv8) Neon SIMD extensions can now be built using MinGW
24 toolchains targetting Arm64 (AArch64) Windows binaries.
25
26 4. Fixed unexpected visual artifacts that occurred when using
27 `jpeg_crop_scanline()` and interblock smoothing while decompressing only the DC
28 scan of a progressive JPEG image.
29
30 5. Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-component
31 JPEG support (`WITH_12BIT`) was enabled along with libjpeg v7 or libjpeg v8
32 API/ABI emulation (`WITH_JPEG7` or `WITH_JPEG8`.)
33
34
35 2.0.5
36 =====
37
38 ### Significant changes relative to 2.0.4:
39
40 1. Worked around issues in the MIPS DSPr2 SIMD extensions that caused failures
41 in the libjpeg-turbo regression tests.  Specifically, the
42 `jsimd_h2v1_downsample_dspr2()` and `jsimd_h2v2_downsample_dspr2()` functions
43 in the MIPS DSPr2 SIMD extensions are now disabled until/unless they can be
44 fixed, and other functions that are incompatible with big endian MIPS CPUs are
45 disabled when building libjpeg-turbo for such CPUs.
46
47 2. Fixed an oversight in the `TJCompressor.compress(int)` method in the
48 TurboJPEG Java API that caused an error ("java.lang.IllegalStateException: No
49 source image is associated with this instance") when attempting to use that
50 method to compress a YUV image.
51
52 3. Fixed an issue (CVE-2020-13790) in the PPM reader that caused a buffer
53 overrun in cjpeg, TJBench, or the `tjLoadImage()` function if one of the values
54 in a binary PPM/PGM input file exceeded the maximum value defined in the file's
55 header and that maximum value was less than 255.  libjpeg-turbo 1.5.0 already
56 included a similar fix for binary PPM/PGM files with maximum values greater
57 than 255.
58
59 4. The TurboJPEG API library's global error handler, which is used in functions
60 such as `tjBufSize()` and `tjLoadImage()` that do not require a TurboJPEG
61 instance handle, is now thread-safe on platforms that support thread-local
62 storage.
63
64
65 2.0.4
66 =====
67
68 ### Significant changes relative to 2.0.3:
69
70 1. Fixed a regression in the Windows packaging system (introduced by
71 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo SDK for GCC and the
72 64-bit libjpeg-turbo SDK for Visual C++ were installed on the same system, only
73 one of them could be uninstalled.
74
75 2. Fixed a signed integer overflow and subsequent segfault that occurred when
76 attempting to decompress images with more than 715827882 pixels using the
77 64-bit C version of TJBench.
78
79 3. Fixed out-of-bounds write in `tjDecompressToYUV2()` and
80 `tjDecompressToYUVPlanes()` (sometimes manifesting as a double free) that
81 occurred when attempting to decompress grayscale JPEG images that were
82 compressed with a sampling factor other than 1 (for instance, with
83 `cjpeg -grayscale -sample 2x2`).
84
85 4. Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to
86 incorrectly identify some JPEG images with unusual sampling factors as 4:4:4
87 JPEG images.  This was known to cause a buffer overflow when attempting to
88 decompress some such images using `tjDecompressToYUV2()` or
89 `tjDecompressToYUVPlanes()`.
90
91 5. Fixed an issue, detected by ASan, whereby attempting to losslessly transform
92 a specially-crafted malformed JPEG image containing an extremely-high-frequency
93 coefficient block (junk image data that could never be generated by a
94 legitimate JPEG compressor) could cause the Huffman encoder's local buffer to
95 be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].)  Given that the buffer
96 overrun was fully contained within the stack and did not cause a segfault or
97 other user-visible errant behavior, and given that the lossless transformer
98 (unlike the decompressor) is not generally exposed to arbitrary data exploits,
99 this issue did not likely pose a security risk.
100
101 6. The Arm 64-bit (Armv8) Neon SIMD assembly code now stores constants in a
102 separate read-only data section rather than in the text section, to support
103 execute-only memory layouts.
104
105
106 2.0.3
107 =====
108
109 ### Significant changes relative to 2.0.2:
110
111 1. Fixed "using JNI after critical get" errors that occurred on Android
112 platforms when passing invalid arguments to certain methods in the TurboJPEG
113 Java API.
114
115 2. Fixed a regression in the SIMD feature detection code, introduced by
116 the AVX2 SIMD extensions (2.0 beta1[1]), that was known to cause an illegal
117 instruction exception, in rare cases, on CPUs that lack support for CPUID leaf
118 07H (or on which the maximum CPUID leaf has been limited by way of a BIOS
119 setting.)
120
121 3. The 4:4:0 (h1v2) fancy (smooth) chroma upsampling algorithm in the
122 decompressor now uses a similar bias pattern to that of the 4:2:2 (h2v1) fancy
123 chroma upsampling algorithm, rounding up or down the upsampled result for
124 alternate pixels rather than always rounding down.  This ensures that,
125 regardless of whether a 4:2:2 JPEG image is rotated or transposed prior to
126 decompression (in the frequency domain) or after decompression (in the spatial
127 domain), the final image will be similar.
128
129 4. Fixed an integer overflow and subsequent segfault that occurred when
130 attempting to compress or decompress images with more than 1 billion pixels
131 using the TurboJPEG API.
132
133 5. Fixed a regression introduced by 2.0 beta1[15] whereby attempting to
134 generate a progressive JPEG image on an SSE2-capable CPU using a scan script
135 containing one or more scans with lengths divisible by 16 would result in an
136 error ("Missing Huffman code table entry") and an invalid JPEG image.
137
138 6. Fixed an issue whereby `tjDecodeYUV()` and `tjDecodeYUVPlanes()` would throw
139 an error ("Invalid progressive parameters") or a warning ("Inconsistent
140 progression sequence") if passed a TurboJPEG instance that was previously used
141 to decompress a progressive JPEG image.
142
143
144 2.0.2
145 =====
146
147 ### Significant changes relative to 2.0.1:
148
149 1. Fixed a regression introduced by 2.0.1[5] that prevented a runtime search
150 path (rpath) from being embedded in the libjpeg-turbo shared libraries and
151 executables for macOS and iOS.  This caused a fatal error of the form
152 "dyld: Library not loaded" when attempting to use one of the executables,
153 unless `DYLD_LIBRARY_PATH` was explicitly set to the location of the
154 libjpeg-turbo shared libraries.
155
156 2. Fixed an integer overflow and subsequent segfault (CVE-2018-20330) that
157 occurred when attempting to load a BMP file with more than 1 billion pixels
158 using the `tjLoadImage()` function.
159
160 3. Fixed a buffer overrun (CVE-2018-19664) that occurred when attempting to
161 decompress a specially-crafted malformed JPEG image to a 256-color BMP using
162 djpeg.
163
164 4. Fixed a floating point exception that occurred when attempting to
165 decompress a specially-crafted malformed JPEG image with a specified image
166 width or height of 0 using the C version of TJBench.
167
168 5. The TurboJPEG API will now decompress 4:4:4 JPEG images with 2x1, 1x2, 3x1,
169 or 1x3 luminance and chrominance sampling factors.  This is a non-standard way
170 of specifying 1x subsampling (normally 4:4:4 JPEGs have 1x1 luminance and
171 chrominance sampling factors), but the JPEG format and the libjpeg API both
172 allow it.
173
174 6. Fixed a regression introduced by 2.0 beta1[7] that caused djpeg to generate
175 incorrect PPM images when used with the `-colors` option.
176
177 7. Fixed an issue whereby a static build of libjpeg-turbo (a build in which
178 `ENABLE_SHARED` is `0`) could not be installed using the Visual Studio IDE.
179
180 8. Fixed a severe performance issue in the Loongson MMI SIMD extensions that
181 occurred when compressing RGB images whose image rows were not 64-bit-aligned.
182
183
184 2.0.1
185 =====
186
187 ### Significant changes relative to 2.0.0:
188
189 1. Fixed a regression introduced with the new CMake-based Un*x build system,
190 whereby jconfig.h could cause compiler warnings of the form
191 `"HAVE_*_H" redefined` if it was included by downstream Autotools-based
192 projects that used `AC_CHECK_HEADERS()` to check for the existence of locale.h,
193 stddef.h, or stdlib.h.
194
195 2. The `jsimd_quantize_float_dspr2()` and `jsimd_convsamp_float_dspr2()`
196 functions in the MIPS DSPr2 SIMD extensions are now disabled at compile time
197 if the soft float ABI is enabled.  Those functions use instructions that are
198 incompatible with the soft float ABI.
199
200 3. Fixed a regression in the SIMD feature detection code, introduced by
201 the AVX2 SIMD extensions (2.0 beta1[1]), that caused libjpeg-turbo to crash on
202 Windows 7 if Service Pack 1 was not installed.
203
204 4. Fixed out-of-bounds read in cjpeg that occurred when attempting to compress
205 a specially-crafted malformed color-index (8-bit-per-sample) Targa file in
206 which some of the samples (color indices) exceeded the bounds of the Targa
207 file's color table.
208
209 5. Fixed an issue whereby installing a fully static build of libjpeg-turbo
210 (a build in which `CFLAGS` contains `-static` and `ENABLE_SHARED` is `0`) would
211 fail with "No valid ELF RPATH or RUNPATH entry exists in the file."
212
213
214 2.0.0
215 =====
216
217 ### Significant changes relative to 2.0 beta1:
218
219 1. The TurboJPEG API can now decompress CMYK JPEG images that have subsampled M
220 and Y components (not to be confused with YCCK JPEG images, in which the C/M/Y
221 components have been transformed into luma and chroma.)   Previously, an error
222 was generated ("Could not determine subsampling type for JPEG image") when such
223 an image was passed to `tjDecompressHeader3()`, `tjTransform()`,
224 `tjDecompressToYUVPlanes()`, `tjDecompressToYUV2()`, or the equivalent Java
225 methods.
226
227 2. Fixed an issue (CVE-2018-11813) whereby a specially-crafted malformed input
228 file (specifically, a file with a valid Targa header but incomplete pixel data)
229 would cause cjpeg to generate a JPEG file that was potentially thousands of
230 times larger than the input file.  The Targa reader in cjpeg was not properly
231 detecting that the end of the input file had been reached prematurely, so after
232 all valid pixels had been read from the input, the reader injected dummy pixels
233 with values of 255 into the JPEG compressor until the number of pixels
234 specified in the Targa header had been compressed.  The Targa reader in cjpeg
235 now behaves like the PPM reader and aborts compression if the end of the input
236 file is reached prematurely.  Because this issue only affected cjpeg and not
237 the underlying library, and because it did not involve any out-of-bounds reads
238 or other exploitable behaviors, it was not believed to represent a security
239 threat.
240
241 3. Fixed an issue whereby the `tjLoadImage()` and `tjSaveImage()` functions
242 would produce a "Bogus message code" error message if the underlying bitmap and
243 PPM readers/writers threw an error that was specific to the readers/writers
244 (as opposed to a general libjpeg API error.)
245
246 4. Fixed an issue (CVE-2018-1152) whereby a specially-crafted malformed BMP
247 file, one in which the header specified an image width of 1073741824 pixels,
248 would trigger a floating point exception (division by zero) in the
249 `tjLoadImage()` function when attempting to load the BMP file into a
250 4-component image buffer.
251
252 5. Fixed an issue whereby certain combinations of calls to
253 `jpeg_skip_scanlines()` and `jpeg_read_scanlines()` could trigger an infinite
254 loop when decompressing progressive JPEG images that use vertical chroma
255 subsampling (for instance, 4:2:0 or 4:4:0.)
256
257 6. Fixed a segfault in `jpeg_skip_scanlines()` that occurred when decompressing
258 a 4:2:2 or 4:2:0 JPEG image using the merged (non-fancy) upsampling algorithms
259 (that is, when setting `cinfo.do_fancy_upsampling` to `FALSE`.)
260
261 7. The new CMake-based build system will now disable the MIPS DSPr2 SIMD
262 extensions if it detects that the compiler does not support DSPr2 instructions.
263
264 8. Fixed out-of-bounds read in cjpeg (CVE-2018-14498) that occurred when
265 attempting to compress a specially-crafted malformed color-index
266 (8-bit-per-sample) BMP file in which some of the samples (color indices)
267 exceeded the bounds of the BMP file's color table.
268
269 9. Fixed a signed integer overflow in the progressive Huffman decoder, detected
270 by the Clang and GCC undefined behavior sanitizers, that could be triggered by
271 attempting to decompress a specially-crafted malformed JPEG image.  This issue
272 did not pose a security threat, but removing the warning made it easier to
273 detect actual security issues, should they arise in the future.
274
275
276 1.5.90 (2.0 beta1)
277 ==================
278
279 ### Significant changes relative to 1.5.3:
280
281 1. Added AVX2 SIMD implementations of the colorspace conversion, chroma
282 downsampling and upsampling, integer quantization and sample conversion, and
283 accurate integer DCT/IDCT algorithms.  When using the accurate integer DCT/IDCT
284 algorithms on AVX2-equipped CPUs, the compression of RGB images is
285 approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x) with
286 64-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the
287 decompression of RGB images is approximately 9-35% (avg. 17%) faster with
288 64-bit code and 7-17% (avg. 12%) faster with 32-bit code.  (As tested on a
289 3 GHz Intel Core i7.  Actual mileage may vary.)
290
291 2. Overhauled the build system to use CMake on all platforms, and removed the
292 autotools-based build system.  This decision resulted from extensive
293 discussions within the libjpeg-turbo community.  libjpeg-turbo traditionally
294 used CMake only for Windows builds, but there was an increasing amount of
295 demand to extend CMake support to other platforms.  However, because of the
296 unique nature of our code base (the need to support different assemblers on
297 each platform, the need for Java support, etc.), providing dual build systems
298 as other OSS imaging libraries do (including libpng and libtiff) would have
299 created a maintenance burden.  The use of CMake greatly simplifies some aspects
300 of our build system, owing to CMake's built-in support for various assemblers,
301 Java, and unit testing, as well as generally fewer quirks that have to be
302 worked around in order to implement our packaging system.  Eliminating
303 autotools puts our project slightly at odds with the traditional practices of
304 the OSS community, since most "system libraries" tend to be built with
305 autotools, but it is believed that the benefits of this move outweigh the
306 risks.  In addition to providing a unified build environment, switching to
307 CMake allows for the use of various build tools and IDEs that aren't supported
308 under autotools, including XCode, Ninja, and Eclipse.  It also eliminates the
309 need to install autotools via MacPorts/Homebrew on OS X and allows
310 libjpeg-turbo to be configured without the use of a terminal/command prompt.
311 Extensive testing was conducted to ensure that all features provided by the
312 autotools-based build system are provided by the new build system.
313
314 3. The libjpeg API in this version of libjpeg-turbo now includes two additional
315 functions, `jpeg_read_icc_profile()` and `jpeg_write_icc_profile()`, that can
316 be used to extract ICC profile data from a JPEG file while decompressing or to
317 embed ICC profile data in a JPEG file while compressing or transforming.  This
318 eliminates the need for downstream projects, such as color management libraries
319 and browsers, to include their own glueware for accomplishing this.
320
321 4. Improved error handling in the TurboJPEG API library:
322
323      - Introduced a new function (`tjGetErrorStr2()`) in the TurboJPEG C API
324 that allows compression/decompression/transform error messages to be retrieved
325 in a thread-safe manner.  Retrieving error messages from global functions, such
326 as `tjInitCompress()` or `tjBufSize()`, is still thread-unsafe, but since those
327 functions will only throw errors if passed an invalid argument or if a memory
328 allocation failure occurs, thread safety is not as much of a concern.
329      - Introduced a new function (`tjGetErrorCode()`) in the TurboJPEG C API
330 and a new method (`TJException.getErrorCode()`) in the TurboJPEG Java API that
331 can be used to determine the severity of the last
332 compression/decompression/transform error.  This allows applications to
333 choose whether to ignore warnings (non-fatal errors) from the underlying
334 libjpeg API or to treat them as fatal.
335      - Introduced a new flag (`TJFLAG_STOPONWARNING` in the TurboJPEG C API and
336 `TJ.FLAG_STOPONWARNING` in the TurboJPEG Java API) that causes the library to
337 immediately halt a compression/decompression/transform operation if it
338 encounters a warning from the underlying libjpeg API (the default behavior is
339 to allow the operation to complete unless a fatal error is encountered.)
340
341 5. Introduced a new flag in the TurboJPEG C and Java APIs (`TJFLAG_PROGRESSIVE`
342 and `TJ.FLAG_PROGRESSIVE`, respectively) that causes the library to use
343 progressive entropy coding in JPEG images generated by compression and
344 transform operations.  Additionally, a new transform option
345 (`TJXOPT_PROGRESSIVE` in the C API and `TJTransform.OPT_PROGRESSIVE` in the
346 Java API) has been introduced, allowing progressive entropy coding to be
347 enabled for selected transforms in a multi-transform operation.
348
349 6. Introduced a new transform option in the TurboJPEG API (`TJXOPT_COPYNONE` in
350 the C API and `TJTransform.OPT_COPYNONE` in the Java API) that allows the
351 copying of markers (including EXIF and ICC profile data) to be disabled for a
352 particular transform.
353
354 7. Added two functions to the TurboJPEG C API (`tjLoadImage()` and
355 `tjSaveImage()`) that can be used to load/save a BMP or PPM/PGM image to/from a
356 memory buffer with a specified pixel format and layout.  These functions
357 replace the project-private (and slow) bmp API, which was previously used by
358 TJBench, and they also provide a convenient way for first-time users of
359 libjpeg-turbo to quickly develop a complete JPEG compression/decompression
360 program.
361
362 8. The TurboJPEG C API now includes a new convenience array (`tjAlphaOffset[]`)
363 that contains the alpha component index for each pixel format (or -1 if the
364 pixel format lacks an alpha component.)  The TurboJPEG Java API now includes a
365 new method (`TJ.getAlphaOffset()`) that returns the same value.  In addition,
366 the `tjRedOffset[]`, `tjGreenOffset[]`, and `tjBlueOffset[]` arrays-- and the
367 corresponding `TJ.getRedOffset()`, `TJ.getGreenOffset()`, and
368 `TJ.getBlueOffset()` methods-- now return -1 for `TJPF_GRAY`/`TJ.PF_GRAY`
369 rather than 0.  This allows programs to easily determine whether a pixel format
370 has red, green, blue, and alpha components.
371
372 9. Added a new example (tjexample.c) that demonstrates the basic usage of the
373 TurboJPEG C API.  This example mirrors the functionality of TJExample.java.
374 Both files are now included in the libjpeg-turbo documentation.
375
376 10. Fixed two signed integer overflows in the arithmetic decoder, detected by
377 the Clang undefined behavior sanitizer, that could be triggered by attempting
378 to decompress a specially-crafted malformed JPEG image.  These issues did not
379 pose a security threat, but removing the warnings makes it easier to detect
380 actual security issues, should they arise in the future.
381
382 11. Fixed a bug in the merged 4:2:0 upsampling/dithered RGB565 color conversion
383 algorithm that caused incorrect dithering in the output image.  This algorithm
384 now produces bitwise-identical results to the unmerged algorithms.
385
386 12. The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64] (if
387 libjpeg-turbo is built with YASM), and iOS/Arm[64] builds are now private.
388 This prevents those symbols from being exposed in applications or shared
389 libraries that link statically with libjpeg-turbo.
390
391 13. Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and
392 YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy
393 chroma upsampling, integer quantization, and accurate integer DCT/IDCT
394 algorithms.  When using the accurate integer DCT/IDCT, this speeds up the
395 compression of RGB images by approximately 70-100% and the decompression of RGB
396 images by approximately 2-3.5x.
397
398 14. Fixed a build error when building with older MinGW releases (regression
399 caused by 1.5.1[7].)
400
401 15. Added SIMD acceleration for progressive Huffman encoding on SSE2-capable
402 x86 and x86-64 platforms.  This speeds up the compression of full-color
403 progressive JPEGs by about 85-90% on average (relative to libjpeg-turbo 1.5.x)
404 when using modern Intel and AMD CPUs.
405
406
407 1.5.3
408 =====
409
410 ### Significant changes relative to 1.5.2:
411
412 1. Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred
413 when using the YUVImage constructor that creates an instance backed by separate
414 image planes and allocates memory for the image planes.
415
416 2. Fixed an issue whereby the Java version of TJUnitTest would fail when
417 testing BufferedImage encoding/decoding on big endian systems.
418
419 3. Fixed a segfault in djpeg that would occur if an output format other than
420 PPM/PGM was selected along with the `-crop` option.  The `-crop` option now
421 works with the GIF and Targa formats as well (unfortunately, it cannot be made
422 to work with the BMP and RLE formats due to the fact that those output engines
423 write scanlines in bottom-up order.)  djpeg will now exit gracefully if an
424 output format other than PPM/PGM, GIF, or Targa is selected along with the
425 `-crop` option.
426
427 4. Fixed an issue (CVE-2017-15232) whereby `jpeg_skip_scanlines()` would
428 segfault if color quantization was enabled.
429
430 5. TJBench (both C and Java versions) will now display usage information if any
431 command-line argument is unrecognized.  This prevents the program from silently
432 ignoring typos.
433
434 6. Fixed an access violation in tjbench.exe (Windows) that occurred when the
435 program was used to decompress an existing JPEG image.
436
437 7. Fixed an ArrayIndexOutOfBoundsException in the TJExample Java program that
438 occurred when attempting to decompress a JPEG image that had been compressed
439 with 4:1:1 chrominance subsampling.
440
441 8. Fixed an issue whereby, when using `jpeg_skip_scanlines()` to skip to the
442 end of a single-scan (non-progressive) image, subsequent calls to
443 `jpeg_consume_input()` would return `JPEG_SUSPENDED` rather than
444 `JPEG_REACHED_EOI`.
445
446 9. `jpeg_crop_scanline()` now works correctly when decompressing grayscale JPEG
447 images that were compressed with a sampling factor other than 1 (for instance,
448 with `cjpeg -grayscale -sample 2x2`).
449
450
451 1.5.2
452 =====
453
454 ### Significant changes relative to 1.5.1:
455
456 1. Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from
457 building with Android NDK platforms prior to android-21 (5.0).
458
459 2. Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD
460 code in libjpeg-turbo from building.
461
462 3. Fixed a regression introduced by 1.5 beta1[11] that prevented the Java
463 version of TJBench from outputting any reference images (the `-nowrite` switch
464 was accidentally enabled by default.)
465
466 4. libjpeg-turbo should now build and run with full AltiVec SIMD acceleration
467 on PowerPC-based AmigaOS 4 and OpenBSD systems.
468
469 5. Fixed build and runtime errors on Windows that occurred when building
470 libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory
471 source/destination managers.  Due to an oversight, the `jpeg_skip_scanlines()`
472 and `jpeg_crop_scanline()` functions were not being included in jpeg7.dll when
473 libjpeg-turbo was built with `-DWITH_JPEG7=1` and `-DWITH_MEMSRCDST=1`.
474
475 6. Fixed "Bogus virtual array access" error that occurred when using the
476 lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was
477 built with libjpeg v7 API/ABI emulation.  This was apparently a long-standing
478 bug that has existed since the introduction of libjpeg v7/v8 API/ABI emulation
479 in libjpeg-turbo v1.1.
480
481 7. The lossless transform features in jpegtran and the TurboJPEG API will now
482 always attempt to adjust the EXIF image width and height tags if the image size
483 changed as a result of the transform.  This behavior has always existed when
484 using libjpeg v8 API/ABI emulation.  It was supposed to be available with
485 libjpeg v7 API/ABI emulation as well but did not work properly due to a bug.
486 Furthermore, there was never any good reason not to enable it with libjpeg v6b
487 API/ABI emulation, since the behavior is entirely internal.  Note that
488 `-copy all` must be passed to jpegtran in order to transfer the EXIF tags from
489 the source image to the destination image.
490
491 8. Fixed several memory leaks in the TurboJPEG API library that could occur
492 if the library was built with certain compilers and optimization levels
493 (known to occur with GCC 4.x and clang with `-O1` and higher but not with
494 GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error
495 after a TurboJPEG API function allocated a local buffer.
496
497 9. The libjpeg-turbo memory manager will now honor the `max_memory_to_use`
498 structure member in jpeg\_memory\_mgr, which can be set to the maximum amount
499 of memory (in bytes) that libjpeg-turbo should use during decompression or
500 multi-pass (including progressive) compression.  This limit can also be set
501 using the `JPEGMEM` environment variable or using the `-maxmemory` switch in
502 cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.)
503 This has been a documented feature of libjpeg since v5, but the
504 `malloc()`/`free()` implementation of the memory manager (jmemnobs.c) never
505 implemented the feature.  Restricting libjpeg-turbo's memory usage is useful
506 for two reasons:  it allows testers to more easily work around the 2 GB limit
507 in libFuzzer, and it allows developers of security-sensitive applications to
508 more easily defend against one of the progressive JPEG exploits (LJT-01-004)
509 identified in
510 [this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf).
511
512 10. TJBench will now run each benchmark for 1 second prior to starting the
513 timer, in order to improve the consistency of the results.  Furthermore, the
514 `-warmup` option is now used to specify the amount of warmup time rather than
515 the number of warmup iterations.
516
517 11. Fixed an error (`short jump is out of range`) that occurred when assembling
518 the 32-bit x86 SIMD extensions with NASM versions prior to 2.04.  This was a
519 regression introduced by 1.5 beta1[12].
520
521
522 1.5.1
523 =====
524
525 ### Significant changes relative to 1.5.0:
526
527 1. Previously, the undocumented `JSIMD_FORCE*` environment variables could be
528 used to force-enable a particular SIMD instruction set if multiple instruction
529 sets were available on a particular platform.  On x86 platforms, where CPU
530 feature detection is bulletproof and multiple SIMD instruction sets are
531 available, it makes sense for those environment variables to allow forcing the
532 use of an instruction set only if that instruction set is available.  However,
533 since the ARM implementations of libjpeg-turbo can only use one SIMD
534 instruction set, and since their feature detection code is less bulletproof
535 (parsing /proc/cpuinfo), it makes sense for the `JSIMD_FORCENEON` environment
536 variable to bypass the feature detection code and really force the use of NEON
537 instructions.  A new environment variable (`JSIMD_FORCEDSPR2`) was introduced
538 in the MIPS implementation for the same reasons, and the existing
539 `JSIMD_FORCENONE` environment variable was extended to that implementation.
540 These environment variables provide a workaround for those attempting to test
541 ARM and MIPS builds of libjpeg-turbo in QEMU, which passes through
542 /proc/cpuinfo from the host system.
543
544 2. libjpeg-turbo previously assumed that AltiVec instructions were always
545 available on PowerPC platforms, which led to "illegal instruction" errors when
546 running on PowerPC chips that lack AltiVec support (such as the older 7xx/G3
547 and newer e5500 series.)  libjpeg-turbo now examines /proc/cpuinfo on
548 Linux/Android systems and enables AltiVec instructions only if the CPU supports
549 them.  It also now provides two environment variables, `JSIMD_FORCEALTIVEC` and
550 `JSIMD_FORCENONE`, to force-enable and force-disable AltiVec instructions in
551 environments where /proc/cpuinfo is an unreliable means of CPU feature
552 detection (such as when running in QEMU.)  On OS X, libjpeg-turbo continues to
553 assume that AltiVec support is always available, which means that libjpeg-turbo
554 cannot be used with G3 Macs unless you set the environment variable
555 `JSIMD_FORCENONE` to `1`.
556
557 3. Fixed an issue whereby 64-bit ARM (AArch64) builds of libjpeg-turbo would
558 crash when built with recent releases of the Clang/LLVM compiler.  This was
559 caused by an ABI conformance issue in some of libjpeg-turbo's 64-bit NEON SIMD
560 routines.  Those routines were incorrectly using 64-bit instructions to
561 transfer a 32-bit JDIMENSION argument, whereas the ABI allows the upper
562 (unused) 32 bits of a 32-bit argument's register to be undefined.  The new
563 Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit
564 structure members into a single 64-bit register, and this exposed the ABI
565 conformance issue.
566
567 4. Fancy upsampling is now supported when decompressing JPEG images that use
568 4:4:0 (h1v2) chroma subsampling.  These images are generated when losslessly
569 rotating or transposing JPEG images that use 4:2:2 (h2v1) chroma subsampling.
570 The h1v2 fancy upsampling algorithm is not currently SIMD-accelerated.
571
572 5. If merged upsampling isn't SIMD-accelerated but YCbCr-to-RGB conversion is,
573 then libjpeg-turbo will now disable merged upsampling when decompressing YCbCr
574 JPEG images into RGB or extended RGB output images.  This significantly speeds
575 up the decompression of 4:2:0 and 4:2:2 JPEGs on ARM platforms if fancy
576 upsampling is not used (for example, if the `-nosmooth` option to djpeg is
577 specified.)
578
579 6. The TurboJPEG API will now decompress 4:2:2 and 4:4:0 JPEG images with
580 2x2 luminance sampling factors and 2x1 or 1x2 chrominance sampling factors.
581 This is a non-standard way of specifying 2x subsampling (normally 4:2:2 JPEGs
582 have 2x1 luminance and 1x1 chrominance sampling factors, and 4:4:0 JPEGs have
583 1x2 luminance and 1x1 chrominance sampling factors), but the JPEG format and
584 the libjpeg API both allow it.
585
586 7. Fixed an unsigned integer overflow in the libjpeg memory manager, detected
587 by the Clang undefined behavior sanitizer, that could be triggered by
588 attempting to decompress a specially-crafted malformed JPEG image.  This issue
589 affected only 32-bit code and did not pose a security threat, but removing the
590 warning makes it easier to detect actual security issues, should they arise in
591 the future.
592
593 8. Fixed additional negative left shifts and other issues reported by the GCC
594 and Clang undefined behavior sanitizers when attempting to decompress
595 specially-crafted malformed JPEG images.  None of these issues posed a security
596 threat, but removing the warnings makes it easier to detect actual security
597 issues, should they arise in the future.
598
599 9. Fixed an out-of-bounds array reference, introduced by 1.4.90[2] (partial
600 image decompression) and detected by the Clang undefined behavior sanitizer,
601 that could be triggered by a specially-crafted malformed JPEG image with more
602 than four components.  Because the out-of-bounds reference was still within the
603 same structure, it was not known to pose a security threat, but removing the
604 warning makes it easier to detect actual security issues, should they arise in
605 the future.
606
607 10. Fixed another ABI conformance issue in the 64-bit ARM (AArch64) NEON SIMD
608 code.  Some of the routines were incorrectly reading and storing data below the
609 stack pointer, which caused segfaults in certain applications under specific
610 circumstances.
611
612
613 1.5.0
614 =====
615
616 ### Significant changes relative to 1.5 beta1:
617
618 1. Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast
619 path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory.
620
621 2. Added libjpeg-turbo version and build information to the global string table
622 of the libjpeg and TurboJPEG API libraries.  This is a common practice in other
623 infrastructure libraries, such as OpenSSL and libpng, because it makes it easy
624 to examine an application binary and determine which version of the library the
625 application was linked against.
626
627 3. Fixed a couple of issues in the PPM reader that would cause buffer overruns
628 in cjpeg if one of the values in a binary PPM/PGM input file exceeded the
629 maximum value defined in the file's header and that maximum value was greater
630 than 255.  libjpeg-turbo 1.4.2 already included a similar fix for ASCII PPM/PGM
631 files.  Note that these issues were not security bugs, since they were confined
632 to the cjpeg program and did not affect any of the libjpeg-turbo libraries.
633
634 4. Fixed an issue whereby attempting to decompress a JPEG file with a corrupt
635 header using the `tjDecompressToYUV2()` function would cause the function to
636 abort without returning an error and, under certain circumstances, corrupt the
637 stack.  This only occurred if `tjDecompressToYUV2()` was called prior to
638 calling `tjDecompressHeader3()`, or if the return value from
639 `tjDecompressHeader3()` was ignored (both cases represent incorrect usage of
640 the TurboJPEG API.)
641
642 5. Fixed an issue in the ARM 32-bit SIMD-accelerated Huffman encoder that
643 prevented the code from assembling properly with clang.
644
645 6. The `jpeg_stdio_src()`, `jpeg_mem_src()`, `jpeg_stdio_dest()`, and
646 `jpeg_mem_dest()` functions in the libjpeg API will now throw an error if a
647 source/destination manager has already been assigned to the compress or
648 decompress object by a different function or by the calling program.  This
649 prevents these functions from attempting to reuse a source/destination manager
650 structure that was allocated elsewhere, because there is no way to ensure that
651 it would be big enough to accommodate the new source/destination manager.
652
653
654 1.4.90 (1.5 beta1)
655 ==================
656
657 ### Significant changes relative to 1.4.2:
658
659 1. Added full SIMD acceleration for PowerPC platforms using AltiVec VMX
660 (128-bit SIMD) instructions.  Although the performance of libjpeg-turbo on
661 PowerPC was already good, due to the increased number of registers available
662 to the compiler vs. x86, it was still possible to speed up compression by about
663 3-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the
664 use of AltiVec instructions.
665
666 2. Added two new libjpeg API functions (`jpeg_skip_scanlines()` and
667 `jpeg_crop_scanline()`) that can be used to partially decode a JPEG image.  See
668 [libjpeg.txt](libjpeg.txt) for more details.
669
670 3. The TJCompressor and TJDecompressor classes in the TurboJPEG Java API now
671 implement the Closeable interface, so those classes can be used with a
672 try-with-resources statement.
673
674 4. The TurboJPEG Java classes now throw unchecked idiomatic exceptions
675 (IllegalArgumentException, IllegalStateException) for unrecoverable errors
676 caused by incorrect API usage, and those classes throw a new checked exception
677 type (TJException) for errors that are passed through from the C library.
678
679 5. Source buffers for the TurboJPEG C API functions, as well as the
680 `jpeg_mem_src()` function in the libjpeg API, are now declared as const
681 pointers.  This facilitates passing read-only buffers to those functions and
682 ensures the caller that the source buffer will not be modified.  This should
683 not create any backward API or ABI incompatibilities with prior libjpeg-turbo
684 releases.
685
686 6. The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1
687 FPUs.
688
689 7. Fixed additional negative left shifts and other issues reported by the GCC
690 and Clang undefined behavior sanitizers.  Most of these issues affected only
691 32-bit code, and none of them was known to pose a security threat, but removing
692 the warnings makes it easier to detect actual security issues, should they
693 arise in the future.
694
695 8. Removed the unnecessary `.arch` directive from the ARM64 NEON SIMD code.
696 This directive was preventing the code from assembling using the clang
697 integrated assembler.
698
699 9. Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit
700 libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora
701 distributions.  This was due to the addition of a macro in jconfig.h that
702 allows the Huffman codec to determine the word size at compile time.  Since
703 that macro differs between 32-bit and 64-bit builds, this caused a conflict
704 between the i386 and x86_64 RPMs (any differing files, other than executables,
705 are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.)
706 Since the macro is used only internally, it has been moved into jconfigint.h.
707
708 10. The x86-64 SIMD code can now be disabled at run time by setting the
709 `JSIMD_FORCENONE` environment variable to `1` (the other SIMD implementations
710 already had this capability.)
711
712 11. Added a new command-line argument to TJBench (`-nowrite`) that prevents the
713 benchmark from outputting any images.  This removes any potential operating
714 system overhead that might be caused by lazy writes to disk and thus improves
715 the consistency of the performance measurements.
716
717 12. Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and x86-64
718 platforms.  This speeds up the compression of full-color JPEGs by about 10-15%
719 on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and AMD
720 CPUs.  Additionally, this works around an issue in the clang optimizer that
721 prevents it (as of this writing) from achieving the same performance as GCC
722 when compiling the C version of the Huffman encoder
723 (<https://llvm.org/bugs/show_bug.cgi?id=16035>).  For the purposes of
724 benchmarking or regression testing, SIMD-accelerated Huffman encoding can be
725 disabled by setting the `JSIMD_NOHUFFENC` environment variable to `1`.
726
727 13. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used
728 compression algorithms (including the accurate integer forward DCT and h2v2 &
729 h2v1 downsampling algorithms, which are not accelerated in the 32-bit NEON
730 implementation.)  This speeds up the compression of full-color JPEGs by about
731 75% on average on a Cavium ThunderX processor and by about 2-2.5x on average on
732 Cortex-A53 and Cortex-A57 cores.
733
734 14. Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit
735 and 64-bit platforms.
736
737     For 32-bit code, this speeds up the compression of full-color JPEGs by
738 about 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by
739 about 6-7% on average on a typical Android device (Nexus 5X, Cortex-A53 and
740 Cortex-A57), relative to libjpeg-turbo 1.4.x.  Note that the larger speedup
741 under iOS is due to the fact that iOS builds use LLVM, which does not optimize
742 the C Huffman encoder as well as GCC does.
743
744     For 64-bit code, NEON-accelerated Huffman encoding speeds up the
745 compression of full-color JPEGs by about 40% on average on a typical iOS device
746 (iPhone 5S, Apple A7) and by about 7-8% on average on a typical Android device
747 (Nexus 5X, Cortex-A53 and Cortex-A57), in addition to the speedup described in
748 [13] above.
749
750     For the purposes of benchmarking or regression testing, SIMD-accelerated
751 Huffman encoding can be disabled by setting the `JSIMD_NOHUFFENC` environment
752 variable to `1`.
753
754 15. pkg-config (.pc) scripts are now included for both the libjpeg and
755 TurboJPEG API libraries on Un*x systems.  Note that if a project's build system
756 relies on these scripts, then it will not be possible to build that project
757 with libjpeg or with a prior version of libjpeg-turbo.
758
759 16. Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to
760 improve performance on CPUs with in-order pipelines.  This speeds up the
761 decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX
762 processor and by about 15% on average on a Cortex-A53 core.
763
764 17. Fixed an issue in the accelerated Huffman decoder that could have caused
765 the decoder to read past the end of the input buffer when a malformed,
766 specially-crafted JPEG image was being decompressed.  In prior versions of
767 libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only
768 if there were > 128 bytes of data in the input buffer.  However, it is possible
769 to construct a JPEG image in which a single Huffman block is over 430 bytes
770 long, so this version of libjpeg-turbo activates the accelerated Huffman
771 decoder only if there are > 512 bytes of data in the input buffer.
772
773 18. Fixed a memory leak in tjunittest encountered when running the program
774 with the `-yuv` option.
775
776
777 1.4.2
778 =====
779
780 ### Significant changes relative to 1.4.1:
781
782 1. Fixed an issue whereby cjpeg would segfault if a Windows bitmap with a
783 negative width or height was used as an input image (Windows bitmaps can have
784 a negative height if they are stored in top-down order, but such files are
785 rare and not supported by libjpeg-turbo.)
786
787 2. Fixed an issue whereby, under certain circumstances, libjpeg-turbo would
788 incorrectly encode certain JPEG images when quality=100 and the fast integer
789 forward DCT were used.  This was known to cause `make test` to fail when the
790 library was built with `-march=haswell` on x86 systems.
791
792 3. Fixed an issue whereby libjpeg-turbo would crash when built with the latest
793 & greatest development version of the Clang/LLVM compiler.  This was caused by
794 an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD
795 routines.  Those routines were incorrectly using a 64-bit `mov` instruction to
796 transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper
797 (unused) 32 bits of a 32-bit argument's register to be undefined.  The new
798 Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit
799 structure members into a single 64-bit register, and this exposed the ABI
800 conformance issue.
801
802 4. Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged)
803 upsampling routine that caused a buffer overflow (and subsequent segfault) when
804 decompressing a 4:2:0 JPEG image whose scaled output width was less than 16
805 pixels.  The "plain" upsampling routines are normally only used when
806 decompressing a non-YCbCr JPEG image, but they are also used when decompressing
807 a JPEG image whose scaled output height is 1.
808
809 5. Fixed various negative left shifts and other issues reported by the GCC and
810 Clang undefined behavior sanitizers.  None of these was known to pose a
811 security threat, but removing the warnings makes it easier to detect actual
812 security issues, should they arise in the future.
813
814
815 1.4.1
816 =====
817
818 ### Significant changes relative to 1.4.0:
819
820 1. tjbench now properly handles CMYK/YCCK JPEG files.  Passing an argument of
821 `-cmyk` (instead of, for instance, `-rgb`) will cause tjbench to internally
822 convert the source bitmap to CMYK prior to compression, to generate YCCK JPEG
823 files, and to internally convert the decompressed CMYK pixels back to RGB after
824 decompression (the latter is done automatically if a CMYK or YCCK JPEG is
825 passed to tjbench as a source image.)  The CMYK<->RGB conversion operation is
826 not benchmarked.  NOTE: The quick & dirty CMYK<->RGB conversions that tjbench
827 uses are suitable for testing only.  Proper conversion between CMYK and RGB
828 requires a color management system.
829
830 2. `make test` now performs additional bitwise regression tests using tjbench,
831 mainly for the purpose of testing compression from/decompression to a subregion
832 of a larger image buffer.
833
834 3. `make test` no longer tests the regression of the floating point DCT/IDCT
835 by default, since the results of those tests can vary if the algorithms in
836 question are not implemented using SIMD instructions on a particular platform.
837 See the comments in [Makefile.am](Makefile.am) for information on how to
838 re-enable the tests and to specify an expected result for them based on the
839 particulars of your platform.
840
841 4. The NULL color conversion routines have been significantly optimized,
842 which speeds up the compression of RGB and CMYK JPEGs by 5-20% when using
843 64-bit code and 0-3% when using 32-bit code, and the decompression of those
844 images by 10-30% when using 64-bit code and 3-12% when using 32-bit code.
845
846 5. Fixed an "illegal instruction" error that occurred when djpeg from a
847 SIMD-enabled libjpeg-turbo MIPS build was executed with the `-nosmooth` option
848 on a MIPS machine that lacked DSPr2 support.  The MIPS SIMD routines for h2v1
849 and h2v2 merged upsampling were not properly checking for the existence of
850 DSPr2.
851
852 6. Performance has been improved significantly on 64-bit non-Linux and
853 non-Windows platforms (generally 10-20% faster compression and 5-10% faster
854 decompression.)  Due to an oversight, the 64-bit version of the accelerated
855 Huffman codec was not being compiled in when libjpeg-turbo was built on
856 platforms other than Windows or Linux.  Oops.
857
858 7. Fixed an extremely rare bug in the Huffman encoder that caused 64-bit
859 builds of libjpeg-turbo to incorrectly encode a few specific test images when
860 quality=98, an optimized Huffman table, and the accurate integer forward DCT
861 were used.
862
863 8. The Windows (CMake) build system now supports building only static or only
864 shared libraries.  This is accomplished by adding either `-DENABLE_STATIC=0` or
865 `-DENABLE_SHARED=0` to the CMake command line.
866
867 9. TurboJPEG API functions will now return an error code if a warning is
868 triggered in the underlying libjpeg API.  For instance, if a JPEG file is
869 corrupt, the TurboJPEG decompression functions will attempt to decompress
870 as much of the image as possible, but those functions will now return -1 to
871 indicate that the decompression was not entirely successful.
872
873 10. Fixed a bug in the MIPS DSPr2 4:2:2 fancy upsampling routine that caused a
874 buffer overflow (and subsequent segfault) when decompressing a 4:2:2 JPEG image
875 in which the right-most MCU was 5 or 6 pixels wide.
876
877
878 1.4.0
879 =====
880
881 ### Significant changes relative to 1.4 beta1:
882
883 1. Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build
884 because OS X does not provide the `le32toh()` and `htole32()` functions.)
885
886 2. The non-SIMD RGB565 color conversion code did not work correctly on big
887 endian machines.  This has been fixed.
888
889 3. Fixed an issue in `tjPlaneSizeYUV()` whereby it would erroneously return 1
890 instead of -1 if `componentID` was > 0 and `subsamp` was `TJSAMP_GRAY`.
891
892 3. Fixed an issue in `tjBufSizeYUV2()` whereby it would erroneously return 0
893 instead of -1 if `width` was < 1.
894
895 5. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting
896 on ARM64 platforms (see 1.4 beta1[5].)
897
898 6. The `close()` method in the TJCompressor and TJDecompressor Java classes is
899 now idempotent.  Previously, that method would call the native `tjDestroy()`
900 function even if the TurboJPEG instance had already been destroyed.  This
901 caused an exception to be thrown during finalization, if the `close()` method
902 had already been called.  The exception was caught, but it was still an
903 expensive operation.
904
905 7. The TurboJPEG API previously generated an error (`Could not determine
906 subsampling type for JPEG image`) when attempting to decompress grayscale JPEG
907 images that were compressed with a sampling factor other than 1 (for instance,
908 with `cjpeg -grayscale -sample 2x2`).  Subsampling technically has no meaning
909 with grayscale JPEGs, and thus the horizontal and vertical sampling factors
910 for such images are ignored by the decompressor.  However, the TurboJPEG API
911 was being too rigid and was expecting the sampling factors to be equal to 1
912 before it treated the image as a grayscale JPEG.
913
914 8. cjpeg, djpeg, and jpegtran now accept an argument of `-version`, which will
915 print the library version and exit.
916
917 9. Referring to 1.4 beta1[15], another extremely rare circumstance was
918 discovered under which the Huffman encoder's local buffer can be overrun
919 when a buffered destination manager is being used and an
920 extremely-high-frequency block (basically junk image data) is being encoded.
921 Even though the Huffman local buffer was increased from 128 bytes to 136 bytes
922 to address the previous issue, the new issue caused even the larger buffer to
923 be overrun.  Further analysis reveals that, in the absolute worst case (such as
924 setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning
925 order), the Huffman encoder can produce encoded blocks that approach double the
926 size of the unencoded blocks.  Thus, the Huffman local buffer was increased to
927 256 bytes, which should prevent any such issue from re-occurring in the future.
928
929 10. The new `tjPlaneSizeYUV()`, `tjPlaneWidth()`, and `tjPlaneHeight()`
930 functions were not actually usable on any platform except OS X and Windows,
931 because those functions were not included in the libturbojpeg mapfile.  This
932 has been fixed.
933
934 11. Restored the `JPP()`, `JMETHOD()`, and `FAR` macros in the libjpeg-turbo
935 header files.  The `JPP()` and `JMETHOD()` macros were originally implemented
936 in libjpeg as a way of supporting non-ANSI compilers that lacked support for
937 prototype parameters.  libjpeg-turbo has never supported such compilers, but
938 some software packages still use the macros to define their own prototypes.
939 Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that
940 have far symbols, but some software packages still use the `FAR` macro.  A
941 pretty good argument can be made that this is a bad practice on the part of the
942 software in question, but since this affects more than one package, it's just
943 easier to fix it here.
944
945 12. Fixed issues that were preventing the ARM 64-bit SIMD code from compiling
946 for iOS, and included an ARMv8 architecture in all of the binaries installed by
947 the "official" libjpeg-turbo SDK for OS X.
948
949
950 1.3.90 (1.4 beta1)
951 ==================
952
953 ### Significant changes relative to 1.3.1:
954
955 1. New features in the TurboJPEG API:
956
957      - YUV planar images can now be generated with an arbitrary line padding
958 (previously only 4-byte padding, which was compatible with X Video, was
959 supported.)
960      - The decompress-to-YUV function has been extended to support image
961 scaling.
962      - JPEG images can now be compressed from YUV planar source images.
963      - YUV planar images can now be decoded into RGB or grayscale images.
964      - 4:1:1 subsampling is now supported.  This is mainly included for
965 compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no
966 significant advantages relative to 4:2:0.
967      - CMYK images are now supported.  This feature allows CMYK source images
968 to be compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to
969 CMYK destination images.  Conversion between CMYK/YCCK and RGB or YUV images is
970 not supported.  Such conversion requires a color management system and is thus
971 out of scope for a codec library.
972      - The handling of YUV images in the Java API has been significantly
973 refactored and should now be much more intuitive.
974      - The Java API now supports encoding a YUV image from an arbitrary
975 position in a large image buffer.
976      - All of the YUV functions now have a corresponding function that operates
977 on separate image planes instead of a unified image buffer.  This allows for
978 compressing/decoding from or decompressing/encoding to a subregion of a larger
979 YUV image.  It also allows for handling YUV formats that swap the order of the
980 U and V planes.
981
982 2. Added SIMD acceleration for DSPr2-capable MIPS platforms.  This speeds up
983 the compression of full-color JPEGs by 70-80% on such platforms and
984 decompression by 25-35%.
985
986 3. If an application attempts to decompress a Huffman-coded JPEG image whose
987 header does not contain Huffman tables, libjpeg-turbo will now insert the
988 default Huffman tables.  In order to save space, many motion JPEG video frames
989 are encoded without the default Huffman tables, so these frames can now be
990 successfully decompressed by libjpeg-turbo without additional work on the part
991 of the application.  An application can still override the Huffman tables, for
992 instance to re-use tables from a previous frame of the same video.
993
994 4. The Mac packaging system now uses pkgbuild and productbuild rather than
995 PackageMaker (which is obsolete and no longer supported.)  This means that
996 OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo,
997 although the packages produced can be installed on OS X 10.5 "Leopard" or
998 later.  OS X 10.4 "Tiger" is no longer supported.
999
1000 5. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting
1001 on ARM platforms rather than a lookup table.  This reduces the memory footprint
1002 by 64k, which may be important for some mobile applications.  Out of four
1003 Android devices that were tested, two demonstrated a small overall performance
1004 loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with
1005 ARMv7 code when enabling this new feature, but the other two devices
1006 demonstrated a significant overall performance gain with both ARMv6 and ARMv7
1007 code (~10-20%) when enabling the feature.  Actual mileage may vary.
1008
1009 6. Worked around an issue with Visual C++ 2010 and later that caused incorrect
1010 pixels to be generated when decompressing a JPEG image to a 256-color bitmap,
1011 if compiler optimization was enabled when libjpeg-turbo was built.  This caused
1012 the regression tests to fail when doing a release build under Visual C++ 2010
1013 and later.
1014
1015 7. Improved the accuracy and performance of the non-SIMD implementation of the
1016 floating point inverse DCT (using code borrowed from libjpeg v8a and later.)
1017 The accuracy of this implementation now matches the accuracy of the SSE/SSE2
1018 implementation.  Note, however, that the floating point DCT/IDCT algorithms are
1019 mainly a legacy feature.  They generally do not produce significantly better
1020 accuracy than the accurate integer DCT/IDCT algorithms, and they are quite a
1021 bit slower.
1022
1023 8. Added a new output colorspace (`JCS_RGB565`) to the libjpeg API that allows
1024 for decompressing JPEG images into RGB565 (16-bit) pixels.  If dithering is not
1025 used, then this code path is SIMD-accelerated on ARM platforms.
1026
1027 9. Numerous obsolete features, such as support for non-ANSI compilers and
1028 support for the MS-DOS memory model, were removed from the libjpeg code,
1029 greatly improving its readability and making it easier to maintain and extend.
1030
1031 10. Fixed a segfault that occurred when calling `output_message()` with
1032 `msg_code` set to `JMSG_COPYRIGHT`.
1033
1034 11. Fixed an issue whereby wrjpgcom was allowing comments longer than 65k
1035 characters to be passed on the command line, which was causing it to generate
1036 incorrect JPEG files.
1037
1038 12. Fixed a bug in the build system that was causing the Windows version of
1039 wrjpgcom to be built using the rdjpgcom source code.
1040
1041 13. Restored 12-bit-per-component JPEG support.  A 12-bit version of
1042 libjpeg-turbo can now be built by passing an argument of `--with-12bit` to
1043 configure (Unix) or `-DWITH_12BIT=1` to cmake (Windows.)  12-bit JPEG support
1044 is included only for convenience.  Enabling this feature disables all of the
1045 performance features in libjpeg-turbo, as well as arithmetic coding and the
1046 TurboJPEG API.  The resulting library still contains the other libjpeg-turbo
1047 features (such as the colorspace extensions), but in general, it performs no
1048 faster than libjpeg v6b.
1049
1050 14. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion
1051 and IDCT algorithms (both are used during JPEG decompression.)  For unknown
1052 reasons (probably related to clang), this code cannot currently be compiled for
1053 iOS.
1054
1055 15. Fixed an extremely rare bug (CVE-2014-9092) that could cause the Huffman
1056 encoder's local buffer to overrun when a very high-frequency MCU is compressed
1057 using quality 100 and no subsampling, and when the JPEG output buffer is being
1058 dynamically resized by the destination manager.  This issue was so rare that,
1059 even with a test program specifically designed to make the bug occur (by
1060 injecting random high-frequency YUV data into the compressor), it was
1061 reproducible only once in about every 25 million iterations.
1062
1063 16. Fixed an oversight in the TurboJPEG C wrapper:  if any of the JPEG
1064 compression functions was called repeatedly with the same
1065 automatically-allocated destination buffer, then TurboJPEG would erroneously
1066 assume that the `jpegSize` parameter was equal to the size of the buffer, when
1067 in fact that parameter was probably equal to the size of the most recently
1068 compressed JPEG image.  If the size of the previous JPEG image was not as large
1069 as the current JPEG image, then TurboJPEG would unnecessarily reallocate the
1070 destination buffer.
1071
1072
1073 1.3.1
1074 =====
1075
1076 ### Significant changes relative to 1.3.0:
1077
1078 1. On Un*x systems, `make install` now installs the libjpeg-turbo libraries
1079 into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86,
1080 and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just
1081 x86-64.  You can override this by overriding either the `prefix` or `libdir`
1082 configure variables.
1083
1084 2. The Windows installer now places a copy of the TurboJPEG DLLs in the same
1085 directory as the rest of the libjpeg-turbo binaries.  This was mainly done
1086 to support TurboVNC 1.3, which bundles the DLLs in its Windows installation.
1087 When using a 32-bit version of CMake on 64-bit Windows, it is impossible to
1088 access the c:\WINDOWS\system32 directory, which made it impossible for the
1089 TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL.
1090
1091 3. Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic
1092 entropy coding (by passing arguments of `-progressive -arithmetic` to cjpeg or
1093 jpegtran, for instance) would result in an error, `Requested feature was
1094 omitted at compile time`.
1095
1096 4. Fixed a couple of issues (CVE-2013-6629 and CVE-2013-6630) whereby malformed
1097 JPEG images would cause libjpeg-turbo to use uninitialized memory during
1098 decompression.
1099
1100 5. Fixed an error (`Buffer passed to JPEG library is too small`) that occurred
1101 when calling the TurboJPEG YUV encoding function with a very small (< 5x5)
1102 source image, and added a unit test to check for this error.
1103
1104 6. The Java classes should now build properly under Visual Studio 2010 and
1105 later.
1106
1107 7. Fixed an issue that prevented SRPMs generated using the in-tree packaging
1108 tools from being rebuilt on certain newer Linux distributions.
1109
1110 8. Numerous minor fixes to eliminate compilation and build/packaging system
1111 warnings, fix cosmetic issues, improve documentation clarity, and other general
1112 source cleanup.
1113
1114
1115 1.3.0
1116 =====
1117
1118 ### Significant changes relative to 1.3 beta1:
1119
1120 1. `make test` now works properly on FreeBSD, and it no longer requires the
1121 md5sum executable to be present on other Un*x platforms.
1122
1123 2. Overhauled the packaging system:
1124
1125      - To avoid conflict with vendor-supplied libjpeg-turbo packages, the
1126 official RPMs and DEBs for libjpeg-turbo have been renamed to
1127 "libjpeg-turbo-official".
1128      - The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the
1129 official Linux and Mac packages, to avoid conflict with vendor-supplied
1130 packages and also to streamline the packaging system.
1131      - Release packages are now created with the directory structure defined
1132 by the configure variables `prefix`, `bindir`, `libdir`, etc. (Un\*x) or by the
1133 `CMAKE_INSTALL_PREFIX` variable (Windows.)  The exception is that the docs are
1134 always located under the system default documentation directory on Un\*x and
1135 Mac systems, and on Windows, the TurboJPEG DLL is always located in the Windows
1136 system directory.
1137      - To avoid confusion, official libjpeg-turbo packages on Linux/Unix
1138 platforms (except for Mac) will always install the 32-bit libraries in
1139 /opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64.
1140      - Fixed an issue whereby, in some cases, the libjpeg-turbo executables on
1141 Un*x systems were not properly linking with the shared libraries installed by
1142 the same package.
1143      - Fixed an issue whereby building the "installer" target on Windows when
1144 `WITH_JAVA=1` would fail if the TurboJPEG JAR had not been previously built.
1145      - Building the "install" target on Windows now installs files into the
1146 same places that the installer does.
1147
1148 3. Fixed a Huffman encoder bug that prevented I/O suspension from working
1149 properly.
1150
1151
1152 1.2.90 (1.3 beta1)
1153 ==================
1154
1155 ### Significant changes relative to 1.2.1:
1156
1157 1. Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4,
1158 11/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing.  Note that the IDCT will
1159 not be SIMD-accelerated when using any of these new scaling factors.
1160
1161 2. The TurboJPEG dynamic library is now versioned.  It was not strictly
1162 necessary to do so, because TurboJPEG uses versioned symbols, and if a function
1163 changes in an ABI-incompatible way, that function is renamed and a legacy
1164 function is provided to maintain backward compatibility.  However, certain
1165 Linux distro maintainers have a policy against accepting any library that isn't
1166 versioned.
1167
1168 3. Extended the TurboJPEG Java API so that it can be used to compress a JPEG
1169 image from and decompress a JPEG image to an arbitrary position in a large
1170 image buffer.
1171
1172 4. The `tjDecompressToYUV()` function now supports the `TJFLAG_FASTDCT` flag.
1173
1174 5. The 32-bit supplementary package for amd64 Debian systems now provides
1175 symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32.
1176 This allows those libraries to be used on MultiArch-compatible systems (such as
1177 Ubuntu 11 and later) without setting the linker path.
1178
1179 6. The TurboJPEG Java wrapper should now find the JNI library on Mac systems
1180 without having to pass `-Djava.library.path=/usr/lib` to java.
1181
1182 7. TJBench has been ported to Java to provide a convenient way of validating
1183 the performance of the TurboJPEG Java API.  It can be run with
1184 `java -cp turbojpeg.jar TJBench`.
1185
1186 8. cjpeg can now be used to generate JPEG files with the RGB colorspace
1187 (feature ported from jpeg-8d.)
1188
1189 9. The width and height in the `-crop` argument passed to jpegtran can now be
1190 suffixed with `f` to indicate that, when the upper left corner of the cropping
1191 region is automatically moved to the nearest iMCU boundary, the bottom right
1192 corner should be moved by the same amount.  In other words, this feature causes
1193 jpegtran to strictly honor the specified width/height rather than the specified
1194 bottom right corner (feature ported from jpeg-8d.)
1195
1196 10. JPEG files using the RGB colorspace can now be decompressed into grayscale
1197 images (feature ported from jpeg-8d.)
1198
1199 11. Fixed a regression caused by 1.2.1[7] whereby the build would fail with
1200 multiple "Mismatch in operand sizes" errors when attempting to build the x86
1201 SIMD code with NASM 0.98.
1202
1203 12. The in-memory source/destination managers (`jpeg_mem_src()` and
1204 `jpeg_mem_dest()`) are now included by default when building libjpeg-turbo with
1205 libjpeg v6b or v7 emulation, so that programs can take advantage of these
1206 functions without requiring the use of the backward-incompatible libjpeg v8
1207 ABI.  The "age number" of the libjpeg-turbo library on Un*x systems has been
1208 incremented by 1 to reflect this.  You can disable this feature with a
1209 configure/CMake switch in order to retain strict API/ABI compatibility with the
1210 libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.)  See
1211 [README.md](README.md) for more details.
1212
1213 13. Added ARMv7s architecture to libjpeg.a and libturbojpeg.a in the official
1214 libjpeg-turbo binary package for OS X, so that those libraries can be used to
1215 build applications that leverage the faster CPUs in the iPhone 5 and iPad 4.
1216
1217
1218 1.2.1
1219 =====
1220
1221 ### Significant changes relative to 1.2.0:
1222
1223 1. Creating or decoding a JPEG file that uses the RGB colorspace should now
1224 properly work when the input or output colorspace is one of the libjpeg-turbo
1225 colorspace extensions.
1226
1227 2. When libjpeg-turbo was built without SIMD support and merged (non-fancy)
1228 upsampling was used along with an alpha-enabled colorspace during
1229 decompression, the unused byte of the decompressed pixels was not being set to
1230 0xFF.  This has been fixed.  TJUnitTest has also been extended to test for the
1231 correct behavior of the colorspace extensions when merged upsampling is used.
1232
1233 3. Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the
1234 upper 64 bits of xmm6 and xmm7 on Win64 platforms, which violated the Win64
1235 calling conventions.
1236
1237 4. Fixed a regression (CVE-2012-2806) caused by 1.2.0[6] whereby decompressing
1238 corrupt JPEG images (specifically, images in which the component count was
1239 erroneously set to a large value) would cause libjpeg-turbo to segfault.
1240
1241 5. Worked around a severe performance issue with "Bobcat" (AMD Embedded APU)
1242 processors.  The `MASKMOVDQU` instruction, which was used by the libjpeg-turbo
1243 SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and
1244 it is painfully slow on Bobcat processors in particular.  Eliminating the use
1245 of this instruction improved performance by an order of magnitude on Bobcat
1246 processors and by a small amount (typically 5%) on AMD desktop processors.
1247
1248 6. Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM
1249 platforms.  This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such
1250 platforms.
1251
1252 7. Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms
1253 running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or
1254 4:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy
1255 upsampling would produce several incorrect columns of pixels at the right-hand
1256 side of the output image if each row in the output image was not evenly
1257 divisible by 16 bytes.
1258
1259 8. Fixed an issue whereby attempting to build the SIMD extensions with Xcode
1260 4.3 on OS X platforms would cause NASM to return numerous errors of the form
1261 "'%define' expects a macro identifier".
1262
1263 9. Added flags to the TurboJPEG API that allow the caller to force the use of
1264 either the fast or the accurate DCT/IDCT algorithms in the underlying codec.
1265
1266
1267 1.2.0
1268 =====
1269
1270 ### Significant changes relative to 1.2 beta1:
1271
1272 1. Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system
1273 was not adding the current directory to the assembler include path, so YASM
1274 was not able to find jsimdcfg.inc.)
1275
1276 2. Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
1277 a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes.
1278 This was more of an annoyance than an actual bug, since it did not cause any
1279 actual run-time problems, but the issue showed up when running libjpeg-turbo in
1280 valgrind.  See <http://crbug.com/72399> for more information.
1281
1282 3. Added a compile-time macro (`LIBJPEG_TURBO_VERSION`) that can be used to
1283 check the version of libjpeg-turbo against which an application was compiled.
1284
1285 4. Added new RGBA/BGRA/ABGR/ARGB colorspace extension constants (libjpeg API)
1286 and pixel formats (TurboJPEG API), which allow applications to specify that,
1287 when decompressing to a 4-component RGB buffer, the unused byte should be set
1288 to 0xFF so that it can be interpreted as an opaque alpha channel.
1289
1290 5. Fixed regression issue whereby DevIL failed to build against libjpeg-turbo
1291 because libjpeg-turbo's distributed version of jconfig.h contained an `INLINE`
1292 macro, which conflicted with a similar macro in DevIL.  This macro is used only
1293 internally when building libjpeg-turbo, so it was moved into config.h.
1294
1295 6. libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose
1296 K component is assigned a component ID of 1 instead of 4.  Although these files
1297 are in violation of the spec, other JPEG implementations handle them
1298 correctly.
1299
1300 7. Added ARMv6 and ARMv7 architectures to libjpeg.a and libturbojpeg.a in
1301 the official libjpeg-turbo binary package for OS X, so that those libraries can
1302 be used to build both OS X and iOS applications.
1303
1304
1305 1.1.90 (1.2 beta1)
1306 ==================
1307
1308 ### Significant changes relative to 1.1.1:
1309
1310 1. Added a Java wrapper for the TurboJPEG API.  See [java/README](java/README)
1311 for more details.
1312
1313 2. The TurboJPEG API can now be used to scale down images during
1314 decompression.
1315
1316 3. Added SIMD routines for RGB-to-grayscale color conversion, which
1317 significantly improves the performance of grayscale JPEG compression from an
1318 RGB source image.
1319
1320 4. Improved the performance of the C color conversion routines, which are used
1321 on platforms for which SIMD acceleration is not available.
1322
1323 5. Added a function to the TurboJPEG API that performs lossless transforms.
1324 This function is implemented using the same back end as jpegtran, but it
1325 performs transcoding entirely in memory and allows multiple transforms and/or
1326 crop operations to be batched together, so the source coefficients only need to
1327 be read once.  This is useful when generating image tiles from a single source
1328 JPEG.
1329
1330 6. Added tests for the new TurboJPEG scaled decompression and lossless
1331 transform features to tjbench (the TurboJPEG benchmark, formerly called
1332 "jpgtest".)
1333
1334 7. Added support for 4:4:0 (transposed 4:2:2) subsampling in TurboJPEG, which
1335 was necessary in order for it to read 4:2:2 JPEG files that had been losslessly
1336 transposed or rotated 90 degrees.
1337
1338 8. All legacy VirtualGL code has been re-factored, and this has allowed
1339 libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license.
1340
1341 9. libjpeg-turbo can now be built with YASM.
1342
1343 10. Added SIMD acceleration for ARM Linux and iOS platforms that support
1344 NEON instructions.
1345
1346 11. Refactored the TurboJPEG C API and documented it using Doxygen.  The
1347 TurboJPEG 1.2 API uses pixel formats to define the size and component order of
1348 the uncompressed source/destination images, and it includes a more efficient
1349 version of `TJBUFSIZE()` that computes a worst-case JPEG size based on the
1350 level of chrominance subsampling.  The refactored implementation of the
1351 TurboJPEG API now uses the libjpeg memory source and destination managers,
1352 which allows the TurboJPEG compressor to grow the JPEG buffer as necessary.
1353
1354 12. Eliminated errors in the output of jpegtran on Windows that occurred when
1355 the application was invoked using I/O redirection
1356 (`jpegtran <input.jpg >output.jpg`.)
1357
1358 13. The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding
1359 support in libjpeg-turbo v1.1.0 introduced several new error constants in
1360 jerror.h, and these were mistakenly enabled for all emulation modes, causing
1361 the error enum in libjpeg-turbo to sometimes have different values than the
1362 same enum in libjpeg.  This represents an ABI incompatibility, and it caused
1363 problems with rare applications that took specific action based on a particular
1364 error value.  The fix was to include the new error constants conditionally
1365 based on whether libjpeg v7 or v8 emulation was enabled.
1366
1367 14. Fixed an issue whereby Windows applications that used libjpeg-turbo would
1368 fail to compile if the Windows system headers were included before jpeglib.h.
1369 This issue was caused by a conflict in the definition of the INT32 type.
1370
1371 15. Fixed 32-bit supplementary package for amd64 Debian systems, which was
1372 broken by enhancements to the packaging system in 1.1.
1373
1374 16. When decompressing a JPEG image using an output colorspace of
1375 `JCS_EXT_RGBX`, `JCS_EXT_BGRX`, `JCS_EXT_XBGR`, or `JCS_EXT_XRGB`,
1376 libjpeg-turbo will now set the unused byte to 0xFF, which allows applications
1377 to interpret that byte as an alpha channel (0xFF = opaque).
1378
1379
1380 1.1.1
1381 =====
1382
1383 ### Significant changes relative to 1.1.0:
1384
1385 1. Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated
1386 by `tjEncodeYUV()`.
1387
1388 2. libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
1389 markers found in the middle of the JPEG data stream during decompression.  It
1390 will now hand off decoding of a particular block to the unaccelerated Huffman
1391 decoder if an unexpected marker is found, so that the unaccelerated Huffman
1392 decoder can generate an appropriate warning.
1393
1394 3. Older versions of MinGW64 prefixed symbol names with underscores by
1395 default, which differed from the behavior of 64-bit Visual C++.  MinGW64 1.0
1396 has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate
1397 this, the libjpeg-turbo SIMD function names are no longer prefixed with an
1398 underscore when building with MinGW64.  This means that, when building
1399 libjpeg-turbo with older versions of MinGW64, you will now have to add
1400 `-fno-leading-underscore` to the `CFLAGS`.
1401
1402 4. Fixed a regression bug in the NSIS script that caused the Windows installer
1403 build to fail when using the Visual Studio IDE.
1404
1405 5. Fixed a bug in `jpeg_read_coefficients()` whereby it would not initialize
1406 `cinfo->image_width` and `cinfo->image_height` if libjpeg v7 or v8 emulation
1407 was enabled.  This specifically caused the jpegoptim program to fail if it was
1408 linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8
1409 emulation.
1410
1411 6. Eliminated excessive I/O overhead that occurred when reading BMP files in
1412 cjpeg.
1413
1414 7. Eliminated errors in the output of cjpeg on Windows that occurred when the
1415 application was invoked using I/O redirection (`cjpeg <inputfile >output.jpg`.)
1416
1417
1418 1.1.0
1419 =====
1420
1421 ### Significant changes relative to 1.1 beta1:
1422
1423 1. The algorithm used by the SIMD quantization function cannot produce correct
1424 results when the JPEG quality is >= 98 and the fast integer forward DCT is
1425 used.  Thus, the non-SIMD quantization function is now used for those cases,
1426 and libjpeg-turbo should now produce identical output to libjpeg v6b in all
1427 cases.
1428
1429 2. Despite the above, the fast integer forward DCT still degrades somewhat for
1430 JPEG qualities greater than 95, so the TurboJPEG wrapper will now automatically
1431 use the accurate integer forward DCT when generating JPEG images of quality 96
1432 or greater.  This reduces compression performance by as much as 15% for these
1433 high-quality images but is necessary to ensure that the images are perceptually
1434 lossless.  It also ensures that the library can avoid the performance pitfall
1435 created by [1].
1436
1437 3. Ported jpgtest.cxx to pure C to avoid the need for a C++ compiler.
1438
1439 4. Fixed visual artifacts in grayscale JPEG compression caused by a typo in
1440 the RGB-to-luminance lookup tables.
1441
1442 5. The Windows distribution packages now include the libjpeg run-time programs
1443 (cjpeg, etc.)
1444
1445 6. All packages now include jpgtest.
1446
1447 7. The TurboJPEG dynamic library now uses versioned symbols.
1448
1449 8. Added two new TurboJPEG API functions, `tjEncodeYUV()` and
1450 `tjDecompressToYUV()`, to replace the somewhat hackish `TJ_YUV` flag.
1451
1452
1453 1.0.90 (1.1 beta1)
1454 ==================
1455
1456 ### Significant changes relative to 1.0.1:
1457
1458 1. Added emulation of the libjpeg v7 and v8 APIs and ABIs.  See
1459 [README.md](README.md) for more details.  This feature was sponsored by
1460 CamTrace SAS.
1461
1462 2. Created a new CMake-based build system for the Visual C++ and MinGW builds.
1463
1464 3. Grayscale bitmaps can now be compressed from/decompressed to using the
1465 TurboJPEG API.
1466
1467 4. jpgtest can now be used to test decompression performance with existing
1468 JPEG images.
1469
1470 5. If the default install prefix (/opt/libjpeg-turbo) is used, then
1471 `make install` now creates /opt/libjpeg-turbo/lib32 and
1472 /opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary
1473 packages.
1474
1475 6. All symbols in the libjpeg-turbo dynamic library are now versioned, even
1476 when the library is built with libjpeg v6b emulation.
1477
1478 7. Added arithmetic encoding and decoding support (can be disabled with
1479 configure or CMake options)
1480
1481 8. Added a `TJ_YUV` flag to the TurboJPEG API, which causes both the compressor
1482 and decompressor to output planar YUV images.
1483
1484 9. Added an extended version of `tjDecompressHeader()` to the TurboJPEG API,
1485 which allows the caller to determine the type of subsampling used in a JPEG
1486 image.
1487
1488 10. Added further protections against invalid Huffman codes.
1489
1490
1491 1.0.1
1492 =====
1493
1494 ### Significant changes relative to 1.0.0:
1495
1496 1. The Huffman decoder will now handle erroneous Huffman codes (for instance,
1497 from a corrupt JPEG image.)  Previously, these would cause libjpeg-turbo to
1498 crash under certain circumstances.
1499
1500 2. Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to
1501 be used instead of 4:2:0 when decompressing JPEG images using SSE2 code.
1502
1503 3. The configure script will now automatically determine whether the
1504 `INCOMPLETE_TYPES_BROKEN` macro should be defined.
1505
1506
1507 1.0.0
1508 =====
1509
1510 ### Significant changes relative to 0.0.93:
1511
1512 1. 2983700: Further FreeBSD build tweaks (no longer necessary to specify
1513 `--host` when configuring on a 64-bit system)
1514
1515 2. Created symlinks in the Unix/Linux packages so that the TurboJPEG
1516 include file can always be found in /opt/libjpeg-turbo/include, the 32-bit
1517 static libraries can always be found in /opt/libjpeg-turbo/lib32, and the
1518 64-bit static libraries can always be found in /opt/libjpeg-turbo/lib64.
1519
1520 3. The Unix/Linux distribution packages now include the libjpeg run-time
1521 programs (cjpeg, etc.) and man pages.
1522
1523 4. Created a 32-bit supplementary package for amd64 Debian systems, which
1524 contains just the 32-bit libjpeg-turbo libraries.
1525
1526 5. Moved the libraries from */lib32 to */lib in the i386 Debian package.
1527
1528 6. Include distribution package for Cygwin
1529
1530 7. No longer necessary to specify `--without-simd` on non-x86 architectures,
1531 and unit tests now work on those architectures.
1532
1533
1534 0.0.93
1535 ======
1536
1537 ### Significant changes since 0.0.91:
1538
1539 1. 2982659: Fixed x86-64 build on FreeBSD systems
1540
1541 2. 2988188: Added support for Windows 64-bit systems
1542
1543
1544 0.0.91
1545 ======
1546
1547 ### Significant changes relative to 0.0.90:
1548
1549 1. Added documentation to .deb packages
1550
1551 2. 2968313: Fixed data corruption issues when decompressing large JPEG images
1552 and/or using buffered I/O with the libjpeg-turbo decompressor
1553
1554
1555 0.0.90
1556 ======
1557
1558 Initial release