From: DRC Date: Wed, 6 Dec 2017 18:20:24 +0000 (-0600) Subject: Merge branch 'master' into dev X-Git-Tag: 1.5.90~47 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=afdd7999e4a5c072b7df8a235f97f087e8afb6aa;p=libjpeg-turbo Merge branch 'master' into dev + acknowledge 1.5.3 release --- afdd7999e4a5c072b7df8a235f97f087e8afb6aa diff --cc ChangeLog.md index ceea30d,f5fe44b..9f87a56 --- a/ChangeLog.md +++ b/ChangeLog.md @@@ -1,79 -1,9 +1,107 @@@ +1.6 pre-beta +============ + - ### Significant changes relative to 1.5.2: ++### Significant changes relative to 1.5.3: + +1. Added AVX2 SIMD implementations of the colorspace conversion, chroma +downsampling and upsampling, and integer quantization algorithms. This speeds +up the compression of RGB images by approximately 10-20% when using 64-bit code +and 8-16% when using 32-bit code, and the decompression of RGB images by +approximately 6-15% when using 64-bit code and 4-12% when using 32-bit code. +(As tested on a 3 GHz Intel Core i7. Actual mileage may vary.) + +2. Overhauled the build system to use CMake on all platforms, and removed the +autotools-based build system. This decision resulted from extensive +discussions within the libjpeg-turbo community. libjpeg-turbo traditionally +used CMake only for Windows builds, but there was an increasing amount of +demand to extend CMake support to other platforms. However, because of the +unique nature of our code base (the need to support different assemblers on +each platform, the need for Java support, etc.), providing dual build systems +as other OSS imaging libraries do (including libpng and libtiff) would have +created a maintenance burden. The use of CMake greatly simplifies some aspects +of our build system, owing to CMake's built-in support for various assemblers, +Java, and unit testing, as well as generally fewer quirks that have to be +worked around in order to implement our packaging system. Eliminating +autotools puts our project slightly at odds with the traditional practices of +the OSS community, since most "system libraries" tend to be built with +autotools, but it is believed that the benefits of this move outweigh the +risks. In addition to providing a unified build environment, switching to +CMake allows for the use of various build tools and IDEs that aren't supported +under autotools, including XCode, Ninja, and Eclipse. It also eliminates the +need to install autotools via MacPorts/Homebrew on OS X and allows +libjpeg-turbo to be configured without the use of a terminal/command prompt. +Extensive testing was conducted to ensure that all features provided by the +autotools-based build system are provided by the new build system. + +3. The libjpeg API in this version of libjpeg-turbo now includes two additional +functions, `jpeg_read_icc_profile()` and `jpeg_write_icc_profile()`, that can +be used to extract ICC profile data from a JPEG file while decompressing or to +embed ICC profile data in a JPEG file while compressing or transforming. This +eliminates the need for downstream projects, such as color management libraries +and browsers, to include their own glueware for accomplishing this. + +4. Improved error handling in the TurboJPEG API library: + + - Introduced a new function (`tjGetErrorStr2()`) in the TurboJPEG C API +that allows compression/decompression/transform error messages to be retrieved +in a thread-safe manner. Retrieving error messages from global functions, such +as `tjInitCompress()` or `tjBufSize()`, is still thread-unsafe, but since those +functions will only throw errors if passed an invalid argument or if a memory +allocation failure occurs, thread safety is not as much of a concern. + - Introduced a new function (`tjGetErrorCode()`) in the TurboJPEG C API +and a new method (`TJException.getErrorCode()`) in the TurboJPEG Java API that +can be used to determine the severity of the last +compression/decompression/transform error. This allows applications to +choose whether to ignore warnings (non-fatal errors) from the underlying +libjpeg API or to treat them as fatal. + - Introduced a new flag (`TJFLAG_STOPONWARNING` in the TurboJPEG C API and +`TJ.FLAG_STOPONWARNING` in the TurboJPEG Java API) that causes the library to +immediately halt a compression/decompression/transform operation if it +encounters a warning from the underlying libjpeg API (the default behavior is +to allow the operation to complete unless a fatal error is encountered.) + +5. Introduced a new flag in the TurboJPEG C and Java APIs (`TJFLAG_PROGRESSIVE` +and `TJ.FLAG_PROGRESSIVE`, respectively) that causes the library to use +progressive entropy coding in JPEG images generated by compression and +transform operations. Additionally, a new transform option +(`TJXOPT_PROGRESSIVE` in the C API and `TJTransform.OPT_PROGRESSIVE` in the +Java API) has been introduced, allowing progressive entropy coding to be +enabled for selected transforms in a multi-transform operation. + +6. Introduced a new transform option in the TurboJPEG API (`TJXOPT_COPYNONE` in +the C API and `TJTransform.OPT_COPYNONE` in the Java API) that allows the +copying of markers (including EXIF and ICC profile data) to be disabled for a +particular transform. + - 7. Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred ++7. Added two functions to the TurboJPEG C API (`tjLoadImage()` and ++`tjSaveImage()`) that can be used to load/save a BMP or PPM/PGM image to/from a ++memory buffer with a specified pixel format and layout. These functions ++replace the project-private (and slow) bmp API, which was previously used by ++TJBench, and they also provide a convenient way for first-time users of ++libjpeg-turbo to quickly develop a complete JPEG compression/decompression ++program. ++ ++8. The TurboJPEG C API now includes a new convenience array (`tjAlphaOffset[]`) ++that contains the alpha component index for each pixel format (or -1 if the ++pixel format lacks an alpha component.) The TurboJPEG Java API now includes a ++new method (`TJ.getAlphaOffset()`) that returns the same value. In addition, ++the `tjRedOffset[]`, `tjGreenOffset[]`, and `tjBlueOffset[]` arrays-- and the ++corresponding `TJ.getRedOffset()`, `TJ.getGreenOffset()`, and ++`TJ.getBlueOffset()` methods-- now return -1 for `TJPF_GRAY`/`TJ.PF_GRAY` ++rather than 0. This allows programs to easily determine whether a pixel format ++has red, green, blue, and alpha components. ++ ++9. Added a new example (tjexample.c) that demonstrates the basic usage of the ++TurboJPEG C API. This example mirrors the functionality of TJExample.java. ++Both files are now included in the libjpeg-turbo documentation. ++ ++ + 1.5.3 + ===== + + ### Significant changes relative to 1.5.2: + + 1. Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred when using the YUVImage constructor that creates an instance backed by separate image planes and allocates memory for the image planes.