Markdown version of ChangeLog.txt
This will make it easier to crib ChangeLog information into release
notes, since both SourceForge and GitHub support MD.
diff --git a/ChangeLog.md b/ChangeLog.md
index 29352e4..4fbcc0a 100644
--- a/ChangeLog.md
+++ b/ChangeLog.md
@@ -1,53 +1,58 @@
1.5.0
=====
-[1] Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast
+### Significant changes relative to 1.5 beta1:
+
+1. Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast
path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory.
1.4.90 (1.5 beta1)
==================
-[1] Added full SIMD acceleration for PowerPC platforms using AltiVec VMX
+### Significant changes relative to 1.4.2:
+
+1. Added full SIMD acceleration for PowerPC platforms using AltiVec VMX
(128-bit SIMD) instructions. Although the performance of libjpeg-turbo on
PowerPC was already good, due to the increased number of registers available
to the compiler vs. x86, it was still possible to speed up compression by about
3-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the
use of AltiVec instructions.
-[2] Added two new libjpeg API functions (jpeg_skip_scanlines() and
-jpeg_crop_scanline()) that can be used to partially decode a JPEG image. See
-libjpeg.txt for more details.
+2. Added two new libjpeg API functions (`jpeg_skip_scanlines()` and
+`jpeg_crop_scanline()`) that can be used to partially decode a JPEG image. See
+[libjpeg.txt](libjpeg.txt) for more details.
-[3] The TJCompressor and TJDecompressor classes in the TurboJPEG Java API now
+3. The TJCompressor and TJDecompressor classes in the TurboJPEG Java API now
implement the Closeable interface, so those classes can be used with a
try-with-resources statement.
-[4] The TurboJPEG Java classes now throw unchecked idiomatic exceptions
+4. The TurboJPEG Java classes now throw unchecked idiomatic exceptions
(IllegalArgumentException, IllegalStateException) for unrecoverable errors
caused by incorrect API usage, and those classes throw a new checked exception
type (TJException) for errors that are passed through from the C library.
-[5] Source buffers for the TurboJPEG C API functions, as well as the
-jpeg_mem_src() function in the libjpeg API, are now declared as const pointers.
-This facilitates passing read-only buffers to those functions and ensures the
-caller that the source buffer will not be modified. This should not create any
-backward API or ABI incompatibilities with prior libjpeg-turbo releases.
+5. Source buffers for the TurboJPEG C API functions, as well as the
+`jpeg_mem_src()` function in the libjpeg API, are now declared as const
+pointers. This facilitates passing read-only buffers to those functions and
+ensures the caller that the source buffer will not be modified. This should
+not create any backward API or ABI incompatibilities with prior libjpeg-turbo
+releases.
-[6] The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1
+6. The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1
FPUs.
-[7] Fixed additional negative left shifts and other issues reported by the GCC
+7. Fixed additional negative left shifts and other issues reported by the GCC
and Clang undefined behavior sanitizers. Most of these issues affected only
32-bit code, and none of them was known to pose a security threat, but removing
the warnings makes it easier to detect actual security issues, should they
arise in the future.
-[8] Removed the unnecessary .arch directive from the ARM64 NEON SIMD code.
+8. Removed the unnecessary `.arch` directive from the ARM64 NEON SIMD code.
This directive was preventing the code from assembling using the clang
integrated assembler.
-[9] Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit
+9. Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit
libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora
distributions. This was due to the addition of a macro in jconfig.h that
allows the Huffman codec to determine the word size at compile time. Since
@@ -56,62 +61,63 @@
are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.)
Since the macro is used only internally, it has been moved into jconfigint.h.
-[10] The x86-64 SIMD code can now be disabled at run time by setting the
-JSIMD_FORCENONE environment variable to 1 (the other SIMD implementations
+10. The x86-64 SIMD code can now be disabled at run time by setting the
+`JSIMD_FORCENONE` environment variable to `1` (the other SIMD implementations
already had this capability.)
-[11] Added a new command-line argument to TJBench (-nowrite) that prevents the
+11. Added a new command-line argument to TJBench (`-nowrite`) that prevents the
benchmark from outputting any images. This removes any potential operating
system overhead that might be caused by lazy writes to disk and thus improves
the consistency of the performance measurements.
-[12] Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and
-x86-64 platforms. This speeds up the compression of full-color JPEGs by about
-10-15% on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and
-AMD CPUs. Additionally, this works around an issue in the clang optimizer that
+12. Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and x86-64
+platforms. This speeds up the compression of full-color JPEGs by about 10-15%
+on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and AMD
+CPUs. Additionally, this works around an issue in the clang optimizer that
prevents it (as of this writing) from achieving the same performance as GCC
when compiling the C version of the Huffman encoder
-(https://llvm.org/bugs/show_bug.cgi?id=16035). For the purposes of benchmarking
-or regression testing, SIMD-accelerated Huffman encoding can be disabled by
-setting the JSIMD_NOHUFFENC environment variable to 1.
+(<https://llvm.org/bugs/show_bug.cgi?id=16035>). For the purposes of
+benchmarking or regression testing, SIMD-accelerated Huffman encoding can be
+disabled by setting the `JSIMD_NOHUFFENC` environment variable to `1`.
-[13] Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used
+13. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used
compression algorithms (including the slow integer forward DCT and h2v2 & h2v1
downsampling algorithms, which are not accelerated in the 32-bit NEON
implementation.) This speeds up the compression of full-color JPEGs by about
75% on average on a Cavium ThunderX processor and by about 2-2.5x on average on
Cortex-A53 and Cortex-A57 cores.
-[14] Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit
+14. Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit
and 64-bit platforms.
-For 32-bit code, this speeds up the compression of full-color JPEGs by about
-30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by about 6-7%
-on average on a typical Android device (Nexus 5X, Cortex-A53 and Cortex-A57),
-relative to libjpeg-turbo 1.4.x. Note that the larger speedup under iOS is due
-to the fact that iOS builds use LLVM, which does not optimize the C Huffman
-encoder as well as GCC does.
+ For 32-bit code, this speeds up the compression of full-color JPEGs by
+about 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by
+about 6-7% on average on a typical Android device (Nexus 5X, Cortex-A53 and
+Cortex-A57), relative to libjpeg-turbo 1.4.x. Note that the larger speedup
+under iOS is due to the fact that iOS builds use LLVM, which does not optimize
+the C Huffman encoder as well as GCC does.
-For 64-bit code, NEON-accelerated Huffman encoding speeds up the compression of
-full-color JPEGs by about 40% on average on a typical iOS device (iPhone 5S,
-Apple A7) and by about 7-8% on average on a typical Android device (Nexus 5X,
-Cortex-A53 and Cortex-A57), in addition to the speedup described in [13] above.
+ For 64-bit code, NEON-accelerated Huffman encoding speeds up the
+compression of full-color JPEGs by about 40% on average on a typical iOS device
+(iPhone 5S, Apple A7) and by about 7-8% on average on a typical Android device
+(Nexus 5X, Cortex-A53 and Cortex-A57), in addition to the speedup described in
+[13] above.
-For the purposes of benchmarking or regression testing, SIMD-accelerated
-Huffman encoding can be disabled by setting the JSIMD_NOHUFFENC environment
-variable to 1.
+ For the purposes of benchmarking or regression testing, SIMD-accelerated
+Huffman encoding can be disabled by setting the `JSIMD_NOHUFFENC` environment
+variable to `1`.
-[15] pkg-config (.pc) scripts are now included for both the libjpeg and
+15. pkg-config (.pc) scripts are now included for both the libjpeg and
TurboJPEG API libraries on Un*x systems. Note that if a project's build system
relies on these scripts, then it will not be possible to build that project
with libjpeg or with a prior version of libjpeg-turbo.
-[16] Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to
+16. Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to
improve performance on CPUs with in-order pipelines. This speeds up the
decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX
processor and by about 15% on average on a Cortex-A53 core.
-[17] Fixed an issue in the accelerated Huffman decoder that could have caused
+17. Fixed an issue in the accelerated Huffman decoder that could have caused
the decoder to read past the end of the input buffer when a malformed,
specially-crafted JPEG image was being decompressed. In prior versions of
libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only
@@ -120,41 +126,43 @@
long, so this version of libjpeg-turbo activates the accelerated Huffman
decoder only if there are > 512 bytes of data in the input buffer.
-[18] Fixed a memory leak in tjunittest encountered when running the program
-with the -yuv option.
+18. Fixed a memory leak in tjunittest encountered when running the program
+with the `-yuv` option.
1.4.2
=====
-[1] Fixed an issue whereby cjpeg would segfault if a Windows bitmap with a
+### Significant changes relative to 1.4.1:
+
+1. Fixed an issue whereby cjpeg would segfault if a Windows bitmap with a
negative width or height was used as an input image (Windows bitmaps can have
a negative height if they are stored in top-down order, but such files are
rare and not supported by libjpeg-turbo.)
-[2] Fixed an issue whereby, under certain circumstances, libjpeg-turbo would
+2. Fixed an issue whereby, under certain circumstances, libjpeg-turbo would
incorrectly encode certain JPEG images when quality=100 and the fast integer
-forward DCT were used. This was known to cause 'make test' to fail when the
-library was built with '-march=haswell' on x86 systems.
+forward DCT were used. This was known to cause `make test` to fail when the
+library was built with `-march=haswell` on x86 systems.
-[3] Fixed an issue whereby libjpeg-turbo would crash when built with the latest
+3. Fixed an issue whereby libjpeg-turbo would crash when built with the latest
& greatest development version of the Clang/LLVM compiler. This was caused by
an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD
-routines. Those routines were incorrectly using a 64-bit mov instruction to
+routines. Those routines were incorrectly using a 64-bit `mov` instruction to
transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper
(unused) 32 bits of a 32-bit argument's register to be undefined. The new
Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit
structure members into a single 64-bit register, and this exposed the ABI
conformance issue.
-[4] Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged)
+4. Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged)
upsampling routine that caused a buffer overflow (and subsequent segfault) when
decompressing a 4:2:0 JPEG image whose scaled output width was less than 16
pixels. The "plain" upsampling routines are normally only used when
decompressing a non-YCbCr JPEG image, but they are also used when decompressing
a JPEG image whose scaled output height is 1.
-[5] Fixed various negative left shifts and other issues reported by the GCC and
+5. Fixed various negative left shifts and other issues reported by the GCC and
Clang undefined behavior sanitizers. None of these was known to pose a
security threat, but removing the warnings makes it easier to detect actual
security issues, should they arise in the future.
@@ -163,59 +171,62 @@
1.4.1
=====
-[1] tjbench now properly handles CMYK/YCCK JPEG files. Passing an argument of
--cmyk (instead of, for instance, -rgb) will cause tjbench to internally convert
-the source bitmap to CMYK prior to compression, to generate YCCK JPEG files,
-and to internally convert the decompressed CMYK pixels back to RGB after
+### Significant changes relative to 1.4.0:
+
+1. tjbench now properly handles CMYK/YCCK JPEG files. Passing an argument of
+`-cmyk` (instead of, for instance, `-rgb`) will cause tjbench to internally
+convert the source bitmap to CMYK prior to compression, to generate YCCK JPEG
+files, and to internally convert the decompressed CMYK pixels back to RGB after
decompression (the latter is done automatically if a CMYK or YCCK JPEG is
passed to tjbench as a source image.) The CMYK<->RGB conversion operation is
not benchmarked. NOTE: The quick & dirty CMYK<->RGB conversions that tjbench
uses are suitable for testing only. Proper conversion between CMYK and RGB
requires a color management system.
-[2] 'make test' now performs additional bitwise regression tests using tjbench,
+2. `make test` now performs additional bitwise regression tests using tjbench,
mainly for the purpose of testing compression from/decompression to a subregion
of a larger image buffer.
-[3] 'make test' no longer tests the regression of the floating point DCT/IDCT
+3. `make test` no longer tests the regression of the floating point DCT/IDCT
by default, since the results of those tests can vary if the algorithms in
question are not implemented using SIMD instructions on a particular platform.
-See the comments in Makefile.am for information on how to re-enable the tests
-and to specify an expected result for them based on the particulars of your
-platform.
+See the comments in [Makefile.am](Makefile.am) for information on how to
+re-enable the tests and to specify an expected result for them based on the
+particulars of your platform.
-[4] The NULL color conversion routines have been significantly optimized,
+4. The NULL color conversion routines have been significantly optimized,
which speeds up the compression of RGB and CMYK JPEGs by 5-20% when using
64-bit code and 0-3% when using 32-bit code, and the decompression of those
images by 10-30% when using 64-bit code and 3-12% when using 32-bit code.
-[5] Fixed an "illegal instruction" error that occurred when djpeg from a
-SIMD-enabled libjpeg-turbo MIPS build was executed with the -nosmooth option on
-a MIPS machine that lacked DSPr2 support. The MIPS SIMD routines for h2v1 and
-h2v2 merged upsampling were not properly checking for the existence of DSPr2.
+5. Fixed an "illegal instruction" error that occurred when djpeg from a
+SIMD-enabled libjpeg-turbo MIPS build was executed with the `-nosmooth` option
+on a MIPS machine that lacked DSPr2 support. The MIPS SIMD routines for h2v1
+and h2v2 merged upsampling were not properly checking for the existence of
+DSPr2.
-[6] Performance has been improved significantly on 64-bit non-Linux and
+6. Performance has been improved significantly on 64-bit non-Linux and
non-Windows platforms (generally 10-20% faster compression and 5-10% faster
decompression.) Due to an oversight, the 64-bit version of the accelerated
Huffman codec was not being compiled in when libjpeg-turbo was built on
platforms other than Windows or Linux. Oops.
-[7] Fixed an extremely rare bug in the Huffman encoder that caused 64-bit
+7. Fixed an extremely rare bug in the Huffman encoder that caused 64-bit
builds of libjpeg-turbo to incorrectly encode a few specific test images when
quality=98, an optimized Huffman table, and the slow integer forward DCT were
used.
-[8] The Windows (CMake) build system now supports building only static or only
-shared libraries. This is accomplished by adding either -DENABLE_STATIC=0 or
--DENABLE_SHARED=0 to the CMake command line.
+8. The Windows (CMake) build system now supports building only static or only
+shared libraries. This is accomplished by adding either `-DENABLE_STATIC=0` or
+`-DENABLE_SHARED=0` to the CMake command line.
-[9] TurboJPEG API functions will now return an error code if a warning is
+9. TurboJPEG API functions will now return an error code if a warning is
triggered in the underlying libjpeg API. For instance, if a JPEG file is
corrupt, the TurboJPEG decompression functions will attempt to decompress
as much of the image as possible, but those functions will now return -1 to
indicate that the decompression was not entirely successful.
-[10] Fixed a bug in the MIPS DSPr2 4:2:2 fancy upsampling routine that caused a
+10. Fixed a bug in the MIPS DSPr2 4:2:2 fancy upsampling routine that caused a
buffer overflow (and subsequent segfault) when decompressing a 4:2:2 JPEG image
in which the right-most MCU was 5 or 6 pixels wide.
@@ -223,41 +234,43 @@
1.4.0
=====
-[1] Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build
-because OS X does not provide the le32toh() and htole32() functions.)
+### Significant changes relative to 1.4 beta1:
-[2] The non-SIMD RGB565 color conversion code did not work correctly on big
+1. Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build
+because OS X does not provide the `le32toh()` and `htole32()` functions.)
+
+2. The non-SIMD RGB565 color conversion code did not work correctly on big
endian machines. This has been fixed.
-[3] Fixed an issue in tjPlaneSizeYUV() whereby it would erroneously return 1
-instead of -1 if componentID was > 0 and subsamp was TJSAMP_GRAY.
+3. Fixed an issue in `tjPlaneSizeYUV()` whereby it would erroneously return 1
+instead of -1 if `componentID` was > 0 and `subsamp` was `TJSAMP_GRAY`.
-[3] Fixed an issue in tjBufSizeYUV2() whereby it would erroneously return 0
-instead of -1 if width was < 1.
+3. Fixed an issue in `tjBufSizeYUV2()` whereby it would erroneously return 0
+instead of -1 if `width` was < 1.
-[5] The Huffman encoder now uses clz and bsr instructions for bit counting on
-ARM64 platforms (see 1.4 beta1 [5].)
+5. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting
+on ARM64 platforms (see 1.4 beta1[5].)
-[6] The close() method in the TJCompressor and TJDecompressor Java classes is
-now idempotent. Previously, that method would call the native tjDestroy()
+6. The `close()` method in the TJCompressor and TJDecompressor Java classes is
+now idempotent. Previously, that method would call the native `tjDestroy()`
function even if the TurboJPEG instance had already been destroyed. This
-caused an exception to be thrown during finalization, if the close() method had
-already been called. The exception was caught, but it was still an expensive
-operation.
+caused an exception to be thrown during finalization, if the `close()` method
+had already been called. The exception was caught, but it was still an
+expensive operation.
-[7] The TurboJPEG API previously generated an error ("Could not determine
-subsampling type for JPEG image") when attempting to decompress grayscale JPEG
+7. The TurboJPEG API previously generated an error (`Could not determine
+subsampling type for JPEG image`) when attempting to decompress grayscale JPEG
images that were compressed with a sampling factor other than 1 (for instance,
-with 'cjpeg -grayscale -sample 2x2'). Subsampling technically has no meaning
+with `cjpeg -grayscale -sample 2x2`). Subsampling technically has no meaning
with grayscale JPEGs, and thus the horizontal and vertical sampling factors
for such images are ignored by the decompressor. However, the TurboJPEG API
was being too rigid and was expecting the sampling factors to be equal to 1
before it treated the image as a grayscale JPEG.
-[8] cjpeg, djpeg, and jpegtran now accept an argument of -version, which will
+8. cjpeg, djpeg, and jpegtran now accept an argument of `-version`, which will
print the library version and exit.
-[9] Referring to 1.4 beta1 [15], another extremely rare circumstance was
+9. Referring to 1.4 beta1[15], another extremely rare circumstance was
discovered under which the Huffman encoder's local buffer can be overrun
when a buffered destination manager is being used and an
extremely-high-frequency block (basically junk image data) is being encoded.
@@ -269,23 +282,23 @@
size of the unencoded blocks. Thus, the Huffman local buffer was increased to
256 bytes, which should prevent any such issue from re-occurring in the future.
-[10] The new tjPlaneSizeYUV(), tjPlaneWidth(), and tjPlaneHeight() functions
-were not actually usable on any platform except OS X and Windows, because
-those functions were not included in the libturbojpeg mapfile. This has been
-fixed.
+10. The new `tjPlaneSizeYUV()`, `tjPlaneWidth()`, and `tjPlaneHeight()`
+functions were not actually usable on any platform except OS X and Windows,
+because those functions were not included in the libturbojpeg mapfile. This
+has been fixed.
-[11] Restored the JPP(), JMETHOD(), and FAR macros in the libjpeg-turbo header
-files. The JPP() and JMETHOD() macros were originally implemented in libjpeg
-as a way of supporting non-ANSI compilers that lacked support for prototype
-parameters. libjpeg-turbo has never supported such compilers, but some
-software packages still use the macros to define their own prototypes.
+11. Restored the `JPP()`, `JMETHOD()`, and `FAR` macros in the libjpeg-turbo
+header files. The `JPP()` and `JMETHOD()` macros were originally implemented
+in libjpeg as a way of supporting non-ANSI compilers that lacked support for
+prototype parameters. libjpeg-turbo has never supported such compilers, but
+some software packages still use the macros to define their own prototypes.
Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that
-have far symbols, but some software packages still use the FAR macro. A pretty
-good argument can be made that this is a bad practice on the part of the
+have far symbols, but some software packages still use the `FAR` macro. A
+pretty good argument can be made that this is a bad practice on the part of the
software in question, but since this affects more than one package, it's just
easier to fix it here.
-[12] Fixed issues that were preventing the ARM 64-bit SIMD code from compiling
+12. Fixed issues that were preventing the ARM 64-bit SIMD code from compiling
for iOS, and included an ARMv8 architecture in all of the binaries installed by
the "official" libjpeg-turbo SDK for OS X.
@@ -293,36 +306,39 @@
1.3.90 (1.4 beta1)
==================
-[1] New features in the TurboJPEG API:
--- YUV planar images can now be generated with an arbitrary line padding
+### Significant changes relative to 1.3.1:
+
+1. New features in the TurboJPEG API:
+ - YUV planar images can now be generated with an arbitrary line padding
(previously only 4-byte padding, which was compatible with X Video, was
supported.)
--- The decompress-to-YUV function has been extended to support image scaling.
--- JPEG images can now be compressed from YUV planar source images.
--- YUV planar images can now be decoded into RGB or grayscale images.
--- 4:1:1 subsampling is now supported. This is mainly included for
+ - The decompress-to-YUV function has been extended to support image
+scaling.
+ - JPEG images can now be compressed from YUV planar source images.
+ - YUV planar images can now be decoded into RGB or grayscale images.
+ - 4:1:1 subsampling is now supported. This is mainly included for
compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no
significant advantages relative to 4:2:0.
--- CMYK images are now supported. This feature allows CMYK source images to be
-compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to CMYK
-destination images. Conversion between CMYK/YCCK and RGB or YUV images is not
-supported. Such conversion requires a color management system and is thus out
-of scope for a codec library.
--- The handling of YUV images in the Java API has been significantly refactored
-and should now be much more intuitive.
--- The Java API now supports encoding a YUV image from an arbitrary position in
-a large image buffer.
--- All of the YUV functions now have a corresponding function that operates on
-separate image planes instead of a unified image buffer. This allows for
+ - CMYK images are now supported. This feature allows CMYK source images
+to be compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to
+CMYK destination images. Conversion between CMYK/YCCK and RGB or YUV images is
+not supported. Such conversion requires a color management system and is thus
+out of scope for a codec library.
+ - The handling of YUV images in the Java API has been significantly
+refactored and should now be much more intuitive.
+ - The Java API now supports encoding a YUV image from an arbitrary
+position in a large image buffer.
+ - All of the YUV functions now have a corresponding function that operates
+on separate image planes instead of a unified image buffer. This allows for
compressing/decoding from or decompressing/encoding to a subregion of a larger
YUV image. It also allows for handling YUV formats that swap the order of the
U and V planes.
-[2] Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up
+2. Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up
the compression of full-color JPEGs by 70-80% on such platforms and
decompression by 25-35%.
-[3] If an application attempts to decompress a Huffman-coded JPEG image whose
+3. If an application attempts to decompress a Huffman-coded JPEG image whose
header does not contain Huffman tables, libjpeg-turbo will now insert the
default Huffman tables. In order to save space, many motion JPEG video frames
are encoded without the default Huffman tables, so these frames can now be
@@ -330,14 +346,14 @@
of the application. An application can still override the Huffman tables, for
instance to re-use tables from a previous frame of the same video.
-[4] The Mac packaging system now uses pkgbuild and productbuild rather than
+4. The Mac packaging system now uses pkgbuild and productbuild rather than
PackageMaker (which is obsolete and no longer supported.) This means that
OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo,
although the packages produced can be installed on OS X 10.5 "Leopard" or
later. OS X 10.4 "Tiger" is no longer supported.
-[5] The Huffman encoder now uses clz and bsr instructions for bit counting on
-ARM platforms rather than a lookup table. This reduces the memory footprint
+5. The Huffman encoder now uses `clz` and `bsr` instructions for bit counting
+on ARM platforms rather than a lookup table. This reduces the memory footprint
by 64k, which may be important for some mobile applications. Out of four
Android devices that were tested, two demonstrated a small overall performance
loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with
@@ -345,13 +361,13 @@
demonstrated a significant overall performance gain with both ARMv6 and ARMv7
code (~10-20%) when enabling the feature. Actual mileage may vary.
-[6] Worked around an issue with Visual C++ 2010 and later that caused incorrect
+6. Worked around an issue with Visual C++ 2010 and later that caused incorrect
pixels to be generated when decompressing a JPEG image to a 256-color bitmap,
if compiler optimization was enabled when libjpeg-turbo was built. This caused
the regression tests to fail when doing a release build under Visual C++ 2010
and later.
-[7] Improved the accuracy and performance of the non-SIMD implementation of the
+7. Improved the accuracy and performance of the non-SIMD implementation of the
floating point inverse DCT (using code borrowed from libjpeg v8a and later.)
The accuracy of this implementation now matches the accuracy of the SSE/SSE2
implementation. Note, however, that the floating point DCT/IDCT algorithms are
@@ -359,39 +375,39 @@
accuracy than the slow integer DCT/IDCT algorithms, and they are quite a bit
slower.
-[8] Added a new output colorspace (JCS_RGB565) to the libjpeg API that allows
+8. Added a new output colorspace (`JCS_RGB565`) to the libjpeg API that allows
for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not
used, then this code path is SIMD-accelerated on ARM platforms.
-[9] Numerous obsolete features, such as support for non-ANSI compilers and
+9. Numerous obsolete features, such as support for non-ANSI compilers and
support for the MS-DOS memory model, were removed from the libjpeg code,
greatly improving its readability and making it easier to maintain and extend.
-[10] Fixed a segfault that occurred when calling output_message() with msg_code
-set to JMSG_COPYRIGHT.
+10. Fixed a segfault that occurred when calling `output_message()` with
+`msg_code` set to `JMSG_COPYRIGHT`.
-[11] Fixed an issue whereby wrjpgcom was allowing comments longer than 65k
+11. Fixed an issue whereby wrjpgcom was allowing comments longer than 65k
characters to be passed on the command line, which was causing it to generate
incorrect JPEG files.
-[12] Fixed a bug in the build system that was causing the Windows version of
+12. Fixed a bug in the build system that was causing the Windows version of
wrjpgcom to be built using the rdjpgcom source code.
-[13] Restored 12-bit-per-component JPEG support. A 12-bit version of
-libjpeg-turbo can now be built by passing an argument of --with-12bit to
-configure (Unix) or -DWITH_12BIT=1 to cmake (Windows.) 12-bit JPEG support is
-included only for convenience. Enabling this feature disables all of the
+13. Restored 12-bit-per-component JPEG support. A 12-bit version of
+libjpeg-turbo can now be built by passing an argument of `--with-12bit` to
+configure (Unix) or `-DWITH_12BIT=1` to cmake (Windows.) 12-bit JPEG support
+is included only for convenience. Enabling this feature disables all of the
performance features in libjpeg-turbo, as well as arithmetic coding and the
TurboJPEG API. The resulting library still contains the other libjpeg-turbo
features (such as the colorspace extensions), but in general, it performs no
faster than libjpeg v6b.
-[14] Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion
+14. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion
and IDCT algorithms (both are used during JPEG decompression.) For unknown
reasons (probably related to clang), this code cannot currently be compiled for
iOS.
-[15] Fixed an extremely rare bug that could cause the Huffman encoder's local
+15. Fixed an extremely rare bug that could cause the Huffman encoder's local
buffer to overrun when a very high-frequency MCU is compressed using quality
100 and no subsampling, and when the JPEG output buffer is being dynamically
resized by the destination manager. This issue was so rare that, even with a
@@ -399,11 +415,11 @@
high-frequency YUV data into the compressor), it was reproducible only once in
about every 25 million iterations.
-[16] Fixed an oversight in the TurboJPEG C wrapper: if any of the JPEG
+16. Fixed an oversight in the TurboJPEG C wrapper: if any of the JPEG
compression functions was called repeatedly with the same
automatically-allocated destination buffer, then TurboJPEG would erroneously
-assume that the jpegSize parameter was equal to the size of the buffer, when in
-fact that parameter was probably equal to the size of the most recently
+assume that the `jpegSize` parameter was equal to the size of the buffer, when
+in fact that parameter was probably equal to the size of the most recently
compressed JPEG image. If the size of the previous JPEG image was not as large
as the current JPEG image, then TurboJPEG would unnecessarily reallocate the
destination buffer.
@@ -412,38 +428,40 @@
1.3.1
=====
-[1] On Un*x systems, 'make install' now installs the libjpeg-turbo libraries
+### Significant changes relative to 1.3.0:
+
+1. On Un*x systems, `make install` now installs the libjpeg-turbo libraries
into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86,
and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just
-x86-64. You can override this by overriding either the 'prefix' or 'libdir'
+x86-64. You can override this by overriding either the `prefix` or `libdir`
configure variables.
-[2] The Windows installer now places a copy of the TurboJPEG DLLs in the same
+2. The Windows installer now places a copy of the TurboJPEG DLLs in the same
directory as the rest of the libjpeg-turbo binaries. This was mainly done
to support TurboVNC 1.3, which bundles the DLLs in its Windows installation.
When using a 32-bit version of CMake on 64-bit Windows, it is impossible to
access the c:\WINDOWS\system32 directory, which made it impossible for the
TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL.
-[3] Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic
-entropy coding (by passing arguments of -progressive -arithmetic to cjpeg or
-jpegtran, for instance) would result in an error, "Requested feature was
-omitted at compile time".
+3. Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic
+entropy coding (by passing arguments of `-progressive -arithmetic` to cjpeg or
+jpegtran, for instance) would result in an error, `Requested feature was
+omitted at compile time`.
-[4] Fixed a couple of issues whereby malformed JPEG images would cause
+4. Fixed a couple of issues whereby malformed JPEG images would cause
libjpeg-turbo to use uninitialized memory during decompression.
-[5] Fixed an error ("Buffer passed to JPEG library is too small") that occurred
+5. Fixed an error (`Buffer passed to JPEG library is too small`) that occurred
when calling the TurboJPEG YUV encoding function with a very small (< 5x5)
source image, and added a unit test to check for this error.
-[6] The Java classes should now build properly under Visual Studio 2010 and
+6. The Java classes should now build properly under Visual Studio 2010 and
later.
-[7] Fixed an issue that prevented SRPMs generated using the in-tree packaging
+7. Fixed an issue that prevented SRPMs generated using the in-tree packaging
tools from being rebuilt on certain newer Linux distributions.
-[8] Numerous minor fixes to eliminate compilation and build/packaging system
+8. Numerous minor fixes to eliminate compilation and build/packaging system
warnings, fix cosmetic issues, improve documentation clarity, and other general
source cleanup.
@@ -451,97 +469,101 @@
1.3.0
=====
-[1] 'make test' now works properly on FreeBSD, and it no longer requires the
+### Significant changes relative to 1.3 beta1:
+
+1. `make test` now works properly on FreeBSD, and it no longer requires the
md5sum executable to be present on other Un*x platforms.
-[2] Overhauled the packaging system:
--- To avoid conflict with vendor-supplied libjpeg-turbo packages, the
+2. Overhauled the packaging system:
+ - To avoid conflict with vendor-supplied libjpeg-turbo packages, the
official RPMs and DEBs for libjpeg-turbo have been renamed to
"libjpeg-turbo-official".
--- The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the
+ - The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the
official Linux and Mac packages, to avoid conflict with vendor-supplied
packages and also to streamline the packaging system.
--- Release packages are now created with the directory structure defined
-by the configure variables "prefix", "bindir", "libdir", etc. (Un*x) or by the
-CMAKE_INSTALL_PREFIX variable (Windows.) The exception is that the docs are
-always located under the system default documentation directory on Un*x and Mac
-systems, and on Windows, the TurboJPEG DLL is always located in the Windows
+ - Release packages are now created with the directory structure defined
+by the configure variables `prefix`, `bindir`, `libdir`, etc. (Un\*x) or by the
+`CMAKE_INSTALL_PREFIX` variable (Windows.) The exception is that the docs are
+always located under the system default documentation directory on Un\*x and
+Mac systems, and on Windows, the TurboJPEG DLL is always located in the Windows
system directory.
--- To avoid confusion, official libjpeg-turbo packages on Linux/Unix platforms
-(except for Mac) will always install the 32-bit libraries in
+ - To avoid confusion, official libjpeg-turbo packages on Linux/Unix
+platforms (except for Mac) will always install the 32-bit libraries in
/opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64.
--- Fixed an issue whereby, in some cases, the libjpeg-turbo executables on Un*x
-systems were not properly linking with the shared libraries installed by the
-same package.
--- Fixed an issue whereby building the "installer" target on Windows when
-WITH_JAVA=1 would fail if the TurboJPEG JAR had not been previously built.
--- Building the "install" target on Windows now installs files into the same
-places that the installer does.
+ - Fixed an issue whereby, in some cases, the libjpeg-turbo executables on
+Un*x systems were not properly linking with the shared libraries installed by
+the same package.
+ - Fixed an issue whereby building the "installer" target on Windows when
+`WITH_JAVA=1` would fail if the TurboJPEG JAR had not been previously built.
+ - Building the "install" target on Windows now installs files into the
+same places that the installer does.
-[3] Fixed a Huffman encoder bug that prevented I/O suspension from working
+3. Fixed a Huffman encoder bug that prevented I/O suspension from working
properly.
1.2.90 (1.3 beta1)
==================
-[1] Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4,
+### Significant changes relative to 1.2.1:
+
+1. Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4,
11/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing. Note that the IDCT will
not be SIMD-accelerated when using any of these new scaling factors.
-[2] The TurboJPEG dynamic library is now versioned. It was not strictly
+2. The TurboJPEG dynamic library is now versioned. It was not strictly
necessary to do so, because TurboJPEG uses versioned symbols, and if a function
changes in an ABI-incompatible way, that function is renamed and a legacy
function is provided to maintain backward compatibility. However, certain
Linux distro maintainers have a policy against accepting any library that isn't
versioned.
-[3] Extended the TurboJPEG Java API so that it can be used to compress a JPEG
+3. Extended the TurboJPEG Java API so that it can be used to compress a JPEG
image from and decompress a JPEG image to an arbitrary position in a large
image buffer.
-[4] The tjDecompressToYUV() function now supports the TJFLAG_FASTDCT flag.
+4. The `tjDecompressToYUV()` function now supports the `TJFLAG_FASTDCT` flag.
-[5] The 32-bit supplementary package for amd64 Debian systems now provides
+5. The 32-bit supplementary package for amd64 Debian systems now provides
symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32.
This allows those libraries to be used on MultiArch-compatible systems (such as
Ubuntu 11 and later) without setting the linker path.
-[6] The TurboJPEG Java wrapper should now find the JNI library on Mac systems
-without having to pass -Djava.library.path=/usr/lib to java.
+6. The TurboJPEG Java wrapper should now find the JNI library on Mac systems
+without having to pass `-Djava.library.path=/usr/lib` to java.
-[7] TJBench has been ported to Java to provide a convenient way of validating
+7. TJBench has been ported to Java to provide a convenient way of validating
the performance of the TurboJPEG Java API. It can be run with
-'java -cp turbojpeg.jar TJBench'.
+`java -cp turbojpeg.jar TJBench`.
-[8] cjpeg can now be used to generate JPEG files with the RGB colorspace
+8. cjpeg can now be used to generate JPEG files with the RGB colorspace
(feature ported from jpeg-8d.)
-[9] The width and height in the -crop argument passed to jpegtran can now be
-suffixed with "f" to indicate that, when the upper left corner of the cropping
+9. The width and height in the `-crop` argument passed to jpegtran can now be
+suffixed with `f` to indicate that, when the upper left corner of the cropping
region is automatically moved to the nearest iMCU boundary, the bottom right
corner should be moved by the same amount. In other words, this feature causes
jpegtran to strictly honor the specified width/height rather than the specified
bottom right corner (feature ported from jpeg-8d.)
-[10] JPEG files using the RGB colorspace can now be decompressed into grayscale
+10. JPEG files using the RGB colorspace can now be decompressed into grayscale
images (feature ported from jpeg-8d.)
-[11] Fixed a regression caused by 1.2.1[7] whereby the build would fail with
+11. Fixed a regression caused by 1.2.1[7] whereby the build would fail with
multiple "Mismatch in operand sizes" errors when attempting to build the x86
SIMD code with NASM 0.98.
-[12] The in-memory source/destination managers (jpeg_mem_src() and
-jpeg_mem_dest()) are now included by default when building libjpeg-turbo with
+12. The in-memory source/destination managers (`jpeg_mem_src()` and
+`jpeg_mem_dest()`) are now included by default when building libjpeg-turbo with
libjpeg v6b or v7 emulation, so that programs can take advantage of these
functions without requiring the use of the backward-incompatible libjpeg v8
ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been
incremented by 1 to reflect this. You can disable this feature with a
configure/CMake switch in order to retain strict API/ABI compatibility with the
libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See
-README.md for more details.
+[README.md](README.md) for more details.
-[13] Added ARMv7s architecture to libjpeg.a and libturbojpeg.a in the official
+13. Added ARMv7s architecture to libjpeg.a and libturbojpeg.a in the official
libjpeg-turbo binary package for OS X, so that those libraries can be used to
build applications that leverage the faster CPUs in the iPhone 5 and iPad 4.
@@ -549,82 +571,86 @@
1.2.1
=====
-[1] Creating or decoding a JPEG file that uses the RGB colorspace should now
+### Significant changes relative to 1.2.0:
+
+1. Creating or decoding a JPEG file that uses the RGB colorspace should now
properly work when the input or output colorspace is one of the libjpeg-turbo
colorspace extensions.
-[2] When libjpeg-turbo was built without SIMD support and merged (non-fancy)
+2. When libjpeg-turbo was built without SIMD support and merged (non-fancy)
upsampling was used along with an alpha-enabled colorspace during
decompression, the unused byte of the decompressed pixels was not being set to
0xFF. This has been fixed. TJUnitTest has also been extended to test for the
correct behavior of the colorspace extensions when merged upsampling is used.
-[3] Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the
+3. Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the
upper 64 bits of xmm6 and xmm7 on Win64 platforms, which violated the Win64
calling conventions.
-[4] Fixed a regression caused by 1.2.0[6] whereby decompressing corrupt JPEG
+4. Fixed a regression caused by 1.2.0[6] whereby decompressing corrupt JPEG
images (specifically, images in which the component count was erroneously set
to a large value) would cause libjpeg-turbo to segfault.
-[5] Worked around a severe performance issue with "Bobcat" (AMD Embedded APU)
-processors. The MASKMOVDQU instruction, which was used by the libjpeg-turbo
+5. Worked around a severe performance issue with "Bobcat" (AMD Embedded APU)
+processors. The `MASKMOVDQU` instruction, which was used by the libjpeg-turbo
SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and
it is painfully slow on Bobcat processors in particular. Eliminating the use
of this instruction improved performance by an order of magnitude on Bobcat
processors and by a small amount (typically 5%) on AMD desktop processors.
-[6] Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM
+6. Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM
platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such
platforms.
-[7] Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms
+7. Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms
running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or
4:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy
upsampling would produce several incorrect columns of pixels at the right-hand
side of the output image if each row in the output image was not evenly
divisible by 16 bytes.
-[8] Fixed an issue whereby attempting to build the SIMD extensions with Xcode
+8. Fixed an issue whereby attempting to build the SIMD extensions with Xcode
4.3 on OS X platforms would cause NASM to return numerous errors of the form
"'%define' expects a macro identifier".
-[9] Added flags to the TurboJPEG API that allow the caller to force the use of
+9. Added flags to the TurboJPEG API that allow the caller to force the use of
either the fast or the accurate DCT/IDCT algorithms in the underlying codec.
1.2.0
=====
-[1] Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system
+### Significant changes relative to 1.2 beta1:
+
+1. Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system
was not adding the current directory to the assembler include path, so YASM
was not able to find jsimdcfg.inc.)
-[2] Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
+2. Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes.
This was more of an annoyance than an actual bug, since it did not cause any
actual run-time problems, but the issue showed up when running libjpeg-turbo in
-valgrind. See http://crbug.com/72399 for more information.
+valgrind. See <http://crbug.com/72399> for more information.
-[3] Added a compile-time macro (LIBJPEG_TURBO_VERSION) that can be used to
+3. Added a compile-time macro (`LIBJPEG_TURBO_VERSION`) that can be used to
check the version of libjpeg-turbo against which an application was compiled.
-[4] Added new RGBA/BGRA/ABGR/ARGB colorspace extension constants (libjpeg API)
+4. Added new RGBA/BGRA/ABGR/ARGB colorspace extension constants (libjpeg API)
and pixel formats (TurboJPEG API), which allow applications to specify that,
when decompressing to a 4-component RGB buffer, the unused byte should be set
to 0xFF so that it can be interpreted as an opaque alpha channel.
-[5] Fixed regression issue whereby DevIL failed to build against libjpeg-turbo
-because libjpeg-turbo's distributed version of jconfig.h contained an INLINE
+5. Fixed regression issue whereby DevIL failed to build against libjpeg-turbo
+because libjpeg-turbo's distributed version of jconfig.h contained an `INLINE`
macro, which conflicted with a similar macro in DevIL. This macro is used only
internally when building libjpeg-turbo, so it was moved into config.h.
-[6] libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose
+6. libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose
K component is assigned a component ID of 1 instead of 4. Although these files
are in violation of the spec, other JPEG implementations handle them
correctly.
-[7] Added ARMv6 and ARMv7 architectures to libjpeg.a and libturbojpeg.a in
+7. Added ARMv6 and ARMv7 architectures to libjpeg.a and libturbojpeg.a in
the official libjpeg-turbo binary package for OS X, so that those libraries can
be used to build both OS X and iOS applications.
@@ -632,55 +658,57 @@
1.1.90 (1.2 beta1)
==================
-[1] Added a Java wrapper for the TurboJPEG API. See java/README for more
-details.
+### Significant changes relative to 1.1.1:
-[2] The TurboJPEG API can now be used to scale down images during
+1. Added a Java wrapper for the TurboJPEG API. See [java/README](java/README)
+for more details.
+
+2. The TurboJPEG API can now be used to scale down images during
decompression.
-[3] Added SIMD routines for RGB-to-grayscale color conversion, which
+3. Added SIMD routines for RGB-to-grayscale color conversion, which
significantly improves the performance of grayscale JPEG compression from an
RGB source image.
-[4] Improved the performance of the C color conversion routines, which are used
+4. Improved the performance of the C color conversion routines, which are used
on platforms for which SIMD acceleration is not available.
-[5] Added a function to the TurboJPEG API that performs lossless transforms.
+5. Added a function to the TurboJPEG API that performs lossless transforms.
This function is implemented using the same back end as jpegtran, but it
performs transcoding entirely in memory and allows multiple transforms and/or
crop operations to be batched together, so the source coefficients only need to
be read once. This is useful when generating image tiles from a single source
JPEG.
-[6] Added tests for the new TurboJPEG scaled decompression and lossless
+6. Added tests for the new TurboJPEG scaled decompression and lossless
transform features to tjbench (the TurboJPEG benchmark, formerly called
"jpgtest".)
-[7] Added support for 4:4:0 (transposed 4:2:2) subsampling in TurboJPEG, which
+7. Added support for 4:4:0 (transposed 4:2:2) subsampling in TurboJPEG, which
was necessary in order for it to read 4:2:2 JPEG files that had been losslessly
transposed or rotated 90 degrees.
-[8] All legacy VirtualGL code has been re-factored, and this has allowed
+8. All legacy VirtualGL code has been re-factored, and this has allowed
libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license.
-[9] libjpeg-turbo can now be built with YASM.
+9. libjpeg-turbo can now be built with YASM.
-[10] Added SIMD acceleration for ARM Linux and iOS platforms that support
+10. Added SIMD acceleration for ARM Linux and iOS platforms that support
NEON instructions.
-[11] Refactored the TurboJPEG C API and documented it using Doxygen. The
+11. Refactored the TurboJPEG C API and documented it using Doxygen. The
TurboJPEG 1.2 API uses pixel formats to define the size and component order of
the uncompressed source/destination images, and it includes a more efficient
-version of TJBUFSIZE() that computes a worst-case JPEG size based on the level
-of chrominance subsampling. The refactored implementation of the TurboJPEG API
-now uses the libjpeg memory source and destination managers, which allows the
-TurboJPEG compressor to grow the JPEG buffer as necessary.
+version of `TJBUFSIZE()` that computes a worst-case JPEG size based on the
+level of chrominance subsampling. The refactored implementation of the
+TurboJPEG API now uses the libjpeg memory source and destination managers,
+which allows the TurboJPEG compressor to grow the JPEG buffer as necessary.
-[12] Eliminated errors in the output of jpegtran on Windows that occurred when
+12. Eliminated errors in the output of jpegtran on Windows that occurred when
the application was invoked using I/O redirection
-(jpegtran <input.jpg >output.jpg).
+(`jpegtran <input.jpg >output.jpg`.)
-[13] The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding
+13. The inclusion of libjpeg v7 and v8 emulation as well as arithmetic coding
support in libjpeg-turbo v1.1.0 introduced several new error constants in
jerror.h, and these were mistakenly enabled for all emulation modes, causing
the error enum in libjpeg-turbo to sometimes have different values than the
@@ -689,65 +717,69 @@
error value. The fix was to include the new error constants conditionally
based on whether libjpeg v7 or v8 emulation was enabled.
-[14] Fixed an issue whereby Windows applications that used libjpeg-turbo would
+14. Fixed an issue whereby Windows applications that used libjpeg-turbo would
fail to compile if the Windows system headers were included before jpeglib.h.
This issue was caused by a conflict in the definition of the INT32 type.
-[15] Fixed 32-bit supplementary package for amd64 Debian systems, which was
+15. Fixed 32-bit supplementary package for amd64 Debian systems, which was
broken by enhancements to the packaging system in 1.1.
-[16] When decompressing a JPEG image using an output colorspace of
-JCS_EXT_RGBX, JCS_EXT_BGRX, JCS_EXT_XBGR, or JCS_EXT_XRGB, libjpeg-turbo will
-now set the unused byte to 0xFF, which allows applications to interpret that
-byte as an alpha channel (0xFF = opaque).
+16. When decompressing a JPEG image using an output colorspace of
+`JCS_EXT_RGBX`, `JCS_EXT_BGRX`, `JCS_EXT_XBGR`, or `JCS_EXT_XRGB`,
+libjpeg-turbo will now set the unused byte to 0xFF, which allows applications
+to interpret that byte as an alpha channel (0xFF = opaque).
1.1.1
=====
-[1] Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated
-by tjEncodeYUV().
+### Significant changes relative to 1.1.0:
-[2] libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
+1. Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated
+by `tjEncodeYUV()`.
+
+2. libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
markers found in the middle of the JPEG data stream during decompression. It
will now hand off decoding of a particular block to the unaccelerated Huffman
decoder if an unexpected marker is found, so that the unaccelerated Huffman
decoder can generate an appropriate warning.
-[3] Older versions of MinGW64 prefixed symbol names with underscores by
+3. Older versions of MinGW64 prefixed symbol names with underscores by
default, which differed from the behavior of 64-bit Visual C++. MinGW64 1.0
has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate
this, the libjpeg-turbo SIMD function names are no longer prefixed with an
underscore when building with MinGW64. This means that, when building
libjpeg-turbo with older versions of MinGW64, you will now have to add
--fno-leading-underscore to the CFLAGS.
+`-fno-leading-underscore` to the `CFLAGS`.
-[4] Fixed a regression bug in the NSIS script that caused the Windows installer
+4. Fixed a regression bug in the NSIS script that caused the Windows installer
build to fail when using the Visual Studio IDE.
-[5] Fixed a bug in jpeg_read_coefficients() whereby it would not initialize
-cinfo->image_width and cinfo->image_height if libjpeg v7 or v8 emulation was
-enabled. This specifically caused the jpegoptim program to fail if it was
+5. Fixed a bug in `jpeg_read_coefficients()` whereby it would not initialize
+`cinfo->image_width` and `cinfo->image_height` if libjpeg v7 or v8 emulation
+was enabled. This specifically caused the jpegoptim program to fail if it was
linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8
emulation.
-[6] Eliminated excessive I/O overhead that occurred when reading BMP files in
+6. Eliminated excessive I/O overhead that occurred when reading BMP files in
cjpeg.
-[7] Eliminated errors in the output of cjpeg on Windows that occurred when the
-application was invoked using I/O redirection (cjpeg <inputfile >output.jpg).
+7. Eliminated errors in the output of cjpeg on Windows that occurred when the
+application was invoked using I/O redirection (`cjpeg <inputfile >output.jpg`.)
1.1.0
=====
-[1] The algorithm used by the SIMD quantization function cannot produce correct
+### Significant changes relative to 1.1 beta1:
+
+1. The algorithm used by the SIMD quantization function cannot produce correct
results when the JPEG quality is >= 98 and the fast integer forward DCT is
used. Thus, the non-SIMD quantization function is now used for those cases,
and libjpeg-turbo should now produce identical output to libjpeg v6b in all
cases.
-[2] Despite the above, the fast integer forward DCT still degrades somewhat for
+2. Despite the above, the fast integer forward DCT still degrades somewhat for
JPEG qualities greater than 95, so the TurboJPEG wrapper will now automatically
use the slow integer forward DCT when generating JPEG images of quality 96 or
greater. This reduces compression performance by as much as 15% for these
@@ -755,110 +787,121 @@
lossless. It also ensures that the library can avoid the performance pitfall
created by [1].
-[3] Ported jpgtest.cxx to pure C to avoid the need for a C++ compiler.
+3. Ported jpgtest.cxx to pure C to avoid the need for a C++ compiler.
-[4] Fixed visual artifacts in grayscale JPEG compression caused by a typo in
+4. Fixed visual artifacts in grayscale JPEG compression caused by a typo in
the RGB-to-luminance lookup tables.
-[5] The Windows distribution packages now include the libjpeg run-time programs
+5. The Windows distribution packages now include the libjpeg run-time programs
(cjpeg, etc.)
-[6] All packages now include jpgtest.
+6. All packages now include jpgtest.
-[7] The TurboJPEG dynamic library now uses versioned symbols.
+7. The TurboJPEG dynamic library now uses versioned symbols.
-[8] Added two new TurboJPEG API functions, tjEncodeYUV() and
-tjDecompressToYUV(), to replace the somewhat hackish TJ_YUV flag.
+8. Added two new TurboJPEG API functions, `tjEncodeYUV()` and
+`tjDecompressToYUV()`, to replace the somewhat hackish `TJ_YUV` flag.
1.0.90 (1.1 beta1)
==================
-[1] Added emulation of the libjpeg v7 and v8 APIs and ABIs. See
-README.md for more details. This feature was sponsored by CamTrace SAS.
+### Significant changes relative to 1.0.1:
-[2] Created a new CMake-based build system for the Visual C++ and MinGW builds.
+1. Added emulation of the libjpeg v7 and v8 APIs and ABIs. See
+[README.md](README.md) for more details. This feature was sponsored by
+CamTrace SAS.
-[3] Grayscale bitmaps can now be compressed from/decompressed to using the
+2. Created a new CMake-based build system for the Visual C++ and MinGW builds.
+
+3. Grayscale bitmaps can now be compressed from/decompressed to using the
TurboJPEG API.
-[4] jpgtest can now be used to test decompression performance with existing
+4. jpgtest can now be used to test decompression performance with existing
JPEG images.
-[5] If the default install prefix (/opt/libjpeg-turbo) is used, then
-'make install' now creates /opt/libjpeg-turbo/lib32 and
+5. If the default install prefix (/opt/libjpeg-turbo) is used, then
+`make install` now creates /opt/libjpeg-turbo/lib32 and
/opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary
packages.
-[6] All symbols in the libjpeg-turbo dynamic library are now versioned, even
+6. All symbols in the libjpeg-turbo dynamic library are now versioned, even
when the library is built with libjpeg v6b emulation.
-[7] Added arithmetic encoding and decoding support (can be disabled with
+7. Added arithmetic encoding and decoding support (can be disabled with
configure or CMake options)
-[8] Added a TJ_YUV flag to the TurboJPEG API, which causes both the compressor
+8. Added a `TJ_YUV` flag to the TurboJPEG API, which causes both the compressor
and decompressor to output planar YUV images.
-[9] Added an extended version of tjDecompressHeader() to the TurboJPEG API,
+9. Added an extended version of `tjDecompressHeader()` to the TurboJPEG API,
which allows the caller to determine the type of subsampling used in a JPEG
image.
-[10] Added further protections against invalid Huffman codes.
+10. Added further protections against invalid Huffman codes.
1.0.1
=====
-[1] The Huffman decoder will now handle erroneous Huffman codes (for instance,
+### Significant changes relative to 1.0.0:
+
+1. The Huffman decoder will now handle erroneous Huffman codes (for instance,
from a corrupt JPEG image.) Previously, these would cause libjpeg-turbo to
crash under certain circumstances.
-[2] Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to
+2. Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to
be used instead of 4:2:0 when decompressing JPEG images using SSE2 code.
-[3] configure script will now automatically determine whether the
-INCOMPLETE_TYPES_BROKEN macro should be defined.
+3. The configure script will now automatically determine whether the
+`INCOMPLETE_TYPES_BROKEN` macro should be defined.
1.0.0
=====
-[1] 2983700: Further FreeBSD build tweaks (no longer necessary to specify
---host when configuring on a 64-bit system)
+### Significant changes relative to 0.0.93:
-[2] Created symlinks in the Unix/Linux packages so that the TurboJPEG
+1. 2983700: Further FreeBSD build tweaks (no longer necessary to specify
+`--host` when configuring on a 64-bit system)
+
+2. Created symlinks in the Unix/Linux packages so that the TurboJPEG
include file can always be found in /opt/libjpeg-turbo/include, the 32-bit
static libraries can always be found in /opt/libjpeg-turbo/lib32, and the
64-bit static libraries can always be found in /opt/libjpeg-turbo/lib64.
-[3] The Unix/Linux distribution packages now include the libjpeg run-time
+3. The Unix/Linux distribution packages now include the libjpeg run-time
programs (cjpeg, etc.) and man pages.
-[4] Created a 32-bit supplementary package for amd64 Debian systems, which
+4. Created a 32-bit supplementary package for amd64 Debian systems, which
contains just the 32-bit libjpeg-turbo libraries.
-[5] Moved the libraries from */lib32 to */lib in the i386 Debian package.
+5. Moved the libraries from */lib32 to */lib in the i386 Debian package.
-[6] Include distribution package for Cygwin
+6. Include distribution package for Cygwin
-[7] No longer necessary to specify --without-simd on non-x86 architectures, and
-unit tests now work on those architectures.
+7. No longer necessary to specify `--without-simd` on non-x86 architectures,
+and unit tests now work on those architectures.
0.0.93
======
-[1] 2982659, Fixed x86-64 build on FreeBSD systems
+### Significant changes since 0.0.91:
-[2] 2988188: Added support for Windows 64-bit systems
+1. 2982659: Fixed x86-64 build on FreeBSD systems
+
+2. 2988188: Added support for Windows 64-bit systems
0.0.91
======
-[1] Added documentation to .deb packages
+### Significant changes relative to 0.0.90:
-[2] 2968313: Fixed data corruption issues when decompressing large JPEG images
+1. Added documentation to .deb packages
+
+2. 2968313: Fixed data corruption issues when decompressing large JPEG images
and/or using buffered I/O with the libjpeg-turbo decompressor
