- ### Significant changes relative to 1.5.2:
+1.6 pre-beta
+============
+
- 7. Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred
++### 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. 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.
projects / libjpeg-turbo / commitdiff