From: DRC <information@libjpeg-turbo.org>
Date: Sat, 16 Dec 2017 15:34:28 +0000 (-0600)
Subject: Merge branch 'master' into dev
X-Git-Tag: 1.5.90~46
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=bd544e284ba7d385bdab743148c94cb76f09a49c;p=libjpeg-turbo

Merge branch 'master' into dev
---

bd544e284ba7d385bdab743148c94cb76f09a49c
diff --cc BUILDING.md
index c9f6468,42aadf2..eeb36be
--- a/BUILDING.md
+++ b/BUILDING.md
@@@ -535,21 -387,25 +535,24 @@@ needs
      # It should not be necessary to modify the rest
      HOST=arm-linux-androideabi
      SYSROOT=${NDK_PATH}/platforms/android-${ANDROID_VERSION}/arch-arm
-     export CFLAGS="-march=armv7-a -mfloat-abi=softfp -fprefetch-loop-arrays --sysroot=${SYSROOT}"
 -    ANDROID_CFLAGS="-march=armv7-a -mfloat-abi=softfp -fprefetch-loop-arrays \
++    export CFLAGS="-march=armv7-a -mfloat-abi=softfp -fprefetch-loop-arrays \
+       -D__ANDROID_API__=${ANDROID_VERSION} --sysroot=${SYSROOT} \
+       -isystem ${NDK_PATH}/sysroot/usr/include \
+       -isystem ${NDK_PATH}/sysroot/usr/include/${HOST}"
 -
 +    export LDFLAGS=-pie
      TOOLCHAIN=${NDK_PATH}/toolchains/${HOST}-${TOOLCHAIN_VERSION}/prebuilt/${BUILD_PLATFORM}
 -    export CPP=${TOOLCHAIN}/bin/${HOST}-cpp
 -    export AR=${TOOLCHAIN}/bin/${HOST}-ar
 -    export NM=${TOOLCHAIN}/bin/${HOST}-nm
 -    export CC=${TOOLCHAIN}/bin/${HOST}-gcc
 -    export LD=${TOOLCHAIN}/bin/${HOST}-ld
 -    export RANLIB=${TOOLCHAIN}/bin/${HOST}-ranlib
 -    export OBJDUMP=${TOOLCHAIN}/bin/${HOST}-objdump
 -    export STRIP=${TOOLCHAIN}/bin/${HOST}-strip
 +
 +    cat <<EOF >toolchain.cmake
 +    set(CMAKE_SYSTEM_NAME Linux)
 +    set(CMAKE_SYSTEM_PROCESSOR arm)
 +    set(CMAKE_C_COMPILER ${TOOLCHAIN}/bin/${HOST}-gcc)
 +    set(CMAKE_FIND_ROOT_PATH ${TOOLCHAIN}/${HOST})
 +    EOF
 +
      cd {build_directory}
 -    sh {source_directory}/configure --host=${HOST} \
 -      CFLAGS="${ANDROID_CFLAGS} -O3 -fPIE" \
 -      CPPFLAGS="${ANDROID_CFLAGS}" \
 -      LDFLAGS="${ANDROID_CFLAGS} -pie" --with-simd ${1+"$@"}
 +    cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
 +      -DCMAKE_POSITION_INDEPENDENT_CODE=1 \
 +      [additional CMake flags] {source_directory}
      make
  
  
@@@ -570,21 -426,24 +573,23 @@@ needs
      # It should not be necessary to modify the rest
      HOST=aarch64-linux-android
      SYSROOT=${NDK_PATH}/platforms/android-${ANDROID_VERSION}/arch-arm64
-     export CFLAGS="--sysroot=${SYSROOT}"
 -    ANDROID_CFLAGS="-D__ANDROID_API__=${ANDROID_VERSION} --sysroot=${SYSROOT} \
++    export CFLAGS="-D__ANDROID_API__=${ANDROID_VERSION} --sysroot=${SYSROOT} \
+       -isystem ${NDK_PATH}/sysroot/usr/include \
+       -isystem ${NDK_PATH}/sysroot/usr/include/${HOST}"
 -
 +    export LDFLAGS=-pie
      TOOLCHAIN=${NDK_PATH}/toolchains/${HOST}-${TOOLCHAIN_VERSION}/prebuilt/${BUILD_PLATFORM}
 -    export CPP=${TOOLCHAIN}/bin/${HOST}-cpp
 -    export AR=${TOOLCHAIN}/bin/${HOST}-ar
 -    export NM=${TOOLCHAIN}/bin/${HOST}-nm
 -    export CC=${TOOLCHAIN}/bin/${HOST}-gcc
 -    export LD=${TOOLCHAIN}/bin/${HOST}-ld
 -    export RANLIB=${TOOLCHAIN}/bin/${HOST}-ranlib
 -    export OBJDUMP=${TOOLCHAIN}/bin/${HOST}-objdump
 -    export STRIP=${TOOLCHAIN}/bin/${HOST}-strip
 +
 +    cat <<EOF >toolchain.cmake
 +    set(CMAKE_SYSTEM_NAME Linux)
 +    set(CMAKE_SYSTEM_PROCESSOR aarch64)
 +    set(CMAKE_C_COMPILER ${TOOLCHAIN}/bin/${HOST}-gcc)
 +    set(CMAKE_FIND_ROOT_PATH ${TOOLCHAIN}/${HOST})
 +    EOF
 +
      cd {build_directory}
 -    sh {source_directory}/configure --host=${HOST} \
 -      CFLAGS="${ANDROID_CFLAGS} -O3 -fPIE" \
 -      CPPFLAGS="${ANDROID_CFLAGS}" \
 -      LDFLAGS="${ANDROID_CFLAGS} -pie" --with-simd ${1+"$@"}
 +    cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
 +      -DCMAKE_POSITION_INDEPENDENT_CODE=1 \
 +      [additional CMake flags] {source_directory}
      make
  
  
@@@ -605,21 -464,24 +610,23 @@@ needs
      # It should not be necessary to modify the rest
      HOST=i686-linux-android
      SYSROOT=${NDK_PATH}/platforms/android-${ANDROID_VERSION}/arch-x86
-     export CFLAGS="--sysroot=${SYSROOT}"
 -    ANDROID_CFLAGS="-D__ANDROID_API__=${ANDROID_VERSION} --sysroot=${SYSROOT} \
++    export CFLAGS="-D__ANDROID_API__=${ANDROID_VERSION} --sysroot=${SYSROOT} \
+       -isystem ${NDK_PATH}/sysroot/usr/include \
+       -isystem ${NDK_PATH}/sysroot/usr/include/${HOST}"
 -
 +    export LDFLAGS=-pie
      TOOLCHAIN=${NDK_PATH}/toolchains/x86-${TOOLCHAIN_VERSION}/prebuilt/${BUILD_PLATFORM}
 -    export CPP=${TOOLCHAIN}/bin/${HOST}-cpp
 -    export AR=${TOOLCHAIN}/bin/${HOST}-ar
 -    export NM=${TOOLCHAIN}/bin/${HOST}-nm
 -    export CC=${TOOLCHAIN}/bin/${HOST}-gcc
 -    export LD=${TOOLCHAIN}/bin/${HOST}-ld
 -    export RANLIB=${TOOLCHAIN}/bin/${HOST}-ranlib
 -    export OBJDUMP=${TOOLCHAIN}/bin/${HOST}-objdump
 -    export STRIP=${TOOLCHAIN}/bin/${HOST}-strip
 +
 +    cat <<EOF >toolchain.cmake
 +    set(CMAKE_SYSTEM_NAME Linux)
 +    set(CMAKE_SYSTEM_PROCESSOR i386)
 +    set(CMAKE_C_COMPILER ${TOOLCHAIN}/bin/${HOST}-gcc)
 +    set(CMAKE_FIND_ROOT_PATH ${TOOLCHAIN}/${HOST})
 +    EOF
 +
      cd {build_directory}
 -    sh {source_directory}/configure --host=${HOST} \
 -      CFLAGS="${ANDROID_CFLAGS} -O3 -fPIE" \
 -      CPPFLAGS="${ANDROID_CFLAGS}" \
 -      LDFLAGS="${ANDROID_CFLAGS} -pie" --with-simd ${1+"$@"}
 +    cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
 +      -DCMAKE_POSITION_INDEPENDENT_CODE=1 \
 +      [additional CMake flags] {source_directory}
      make
  
  
@@@ -640,45 -502,320 +647,47 @@@ needs
      # It should not be necessary to modify the rest
      HOST=x86_64-linux-android
      SYSROOT=${NDK_PATH}/platforms/android-${ANDROID_VERSION}/arch-x86_64
-     export CFLAGS="--sysroot=${SYSROOT}"
 -    ANDROID_CFLAGS="-D__ANDROID_API__=${ANDROID_VERSION} --sysroot=${SYSROOT} \
++    export CFLAGS="-D__ANDROID_API__=${ANDROID_VERSION} --sysroot=${SYSROOT} \
+       -isystem ${NDK_PATH}/sysroot/usr/include \
+       -isystem ${NDK_PATH}/sysroot/usr/include/${HOST}"
 -
 +    export LDFLAGS=-pie
      TOOLCHAIN=${NDK_PATH}/toolchains/x86_64-${TOOLCHAIN_VERSION}/prebuilt/${BUILD_PLATFORM}
 -    export CPP=${TOOLCHAIN}/bin/${HOST}-cpp
 -    export AR=${TOOLCHAIN}/bin/${HOST}-ar
 -    export NM=${TOOLCHAIN}/bin/${HOST}-nm
 -    export CC=${TOOLCHAIN}/bin/${HOST}-gcc
 -    export LD=${TOOLCHAIN}/bin/${HOST}-ld
 -    export RANLIB=${TOOLCHAIN}/bin/${HOST}-ranlib
 -    export OBJDUMP=${TOOLCHAIN}/bin/${HOST}-objdump
 -    export STRIP=${TOOLCHAIN}/bin/${HOST}-strip
 -    cd {build_directory}
 -    sh {source_directory}/configure --host=${HOST} \
 -      CFLAGS="${ANDROID_CFLAGS} -O3 -fPIE" \
 -      CPPFLAGS="${ANDROID_CFLAGS}" \
 -      LDFLAGS="${ANDROID_CFLAGS} -pie" --with-simd ${1+"$@"}
 -    make
 -
 -
 -If building for Android 4.0.x (API level < 16) or earlier, remove `-fPIE` from
 -`CFLAGS` and `-pie` from `LDFLAGS`.
 -
 -
 -Installing libjpeg-turbo
 -------------------------
 -
 -To install libjpeg-turbo after it is built, replace `make` in the build
 -instructions with `make install`.
 -
 -The `--prefix` argument to configure (or the `prefix` configure variable) can
 -be used to specify an installation directory of your choosing.  If you don't
 -specify an installation directory, then the default is to install libjpeg-turbo
 -under **/opt/libjpeg-turbo** and to place the libraries in
 -**/opt/libjpeg-turbo/lib32** (32-bit) or **/opt/libjpeg-turbo/lib64** (64-bit.)
 -
 -The `bindir`, `datadir`, `docdir`, `includedir`, `libdir`, and `mandir`
 -configure variables allow a finer degree of control over where specific files in
 -the libjpeg-turbo distribution should be installed.  These variables can either
 -be specified at configure time or passed as arguments to `make install`.
 -
 -
 -Windows (Visual C++ or MinGW)
 -=============================
 -
 -
 -Build Requirements
 -------------------
 -
 -- [CMake](http://www.cmake.org) v2.8.11 or later
 -
 -- [NASM](http://www.nasm.us) or [YASM](http://yasm.tortall.net)
 -  * If using NASM, 0.98 or later is required for an x86 build.
 -  * If using NASM, 2.05 or later is required for an x86-64 build.
 -  * **nasm.exe**/**yasm.exe** should be in your `PATH`.
 -
 -- Microsoft Visual C++ 2005 or later
 -
 -  If you don't already have Visual C++, then the easiest way to get it is by
 -  installing the
 -  [Windows SDK](http://msdn.microsoft.com/en-us/windows/bb980924.aspx).
 -  The Windows SDK includes both 32-bit and 64-bit Visual C++ compilers and
 -  everything necessary to build libjpeg-turbo.
 -
 -  * You can also use Microsoft Visual Studio Express/Community Edition, which
 -    is a free download.  (NOTE: versions prior to 2012 can only be used to
 -    build 32-bit code.)
 -  * If you intend to build libjpeg-turbo from the command line, then add the
 -    appropriate compiler and SDK directories to the `INCLUDE`, `LIB`, and
 -    `PATH` environment variables.  This is generally accomplished by
 -    executing `vcvars32.bat` or `vcvars64.bat` and `SetEnv.cmd`.
 -    `vcvars32.bat` and `vcvars64.bat` are part of Visual C++ and are located in
 -    the same directory as the compiler.  `SetEnv.cmd` is part of the Windows
 -    SDK.  You can pass optional arguments to `SetEnv.cmd` to specify a 32-bit
 -    or 64-bit build environment.
 -
 -   ... OR ...
 -
 -- MinGW
 -
 -  [MSYS2](http://msys2.github.io/) or [tdm-gcc](http://tdm-gcc.tdragon.net/)
 -  recommended if building on a Windows machine.  Both distributions install a
 -  Start Menu link that can be used to launch a command prompt with the
 -  appropriate compiler paths automatically set.
 -
 -- If building the TurboJPEG Java wrapper, JDK 1.5 or later is required.  This
 -  can be downloaded from <http://www.java.com>.
 -
 -
 -Out-of-Tree Builds
 -------------------
 -
 -Binary objects, libraries, and executables are generated in the directory from
 -which CMake is executed (the "binary directory"), and this directory need not
 -necessarily be the same as the libjpeg-turbo source directory.  You can create
 -multiple independent binary directories, in which different versions of
 -libjpeg-turbo can be built from the same source tree using different compilers
 -or settings.  In the sections below, *{build_directory}* refers to the binary
 -directory, whereas *{source_directory}* refers to the libjpeg-turbo source
 -directory.  For in-tree builds, these directories are the same.
 -
 -
 -Build Procedure
 ----------------
 -
 -NOTE: The build procedures below assume that CMake is invoked from the command
 -line, but all of these procedures can be adapted to the CMake GUI as
 -well.
 -
 -
 -### Visual C++ (Command Line)
 -
 -    cd {build_directory}
 -    cmake -G"NMake Makefiles" -DCMAKE_BUILD_TYPE=Release [additional CMake flags] {source_directory}
 -    nmake
 -
 -This will build either a 32-bit or a 64-bit version of libjpeg-turbo, depending
 -on which version of **cl.exe** is in the `PATH`.
 -
 -The following files will be generated under *{build_directory}*:
  
 -**jpeg-static.lib**<br>
 -Static link library for the libjpeg API
 -
 -**sharedlib/jpeg{version}.dll**<br>
 -DLL for the libjpeg API
 -
 -**sharedlib/jpeg.lib**<br>
 -Import library for the libjpeg API
 -
 -**turbojpeg-static.lib**<br>
 -Static link library for the TurboJPEG API
 -
 -**turbojpeg.dll**<br>
 -DLL for the TurboJPEG API
 -
 -**turbojpeg.lib**<br>
 -Import library for the TurboJPEG API
 -
 -*{version}* is 62, 7, or 8, depending on whether libjpeg v6b (default), v7, or
 -v8 emulation is enabled.
 -
 -
 -### Visual C++ (IDE)
 -
 -Choose the appropriate CMake generator option for your version of Visual Studio
 -(run `cmake` with no arguments for a list of available generators.)  For
 -instance:
 +    cat <<EOF >toolchain.cmake
 +    set(CMAKE_SYSTEM_NAME Linux)
 +    set(CMAKE_SYSTEM_PROCESSOR x86_64)
 +    set(CMAKE_C_COMPILER ${TOOLCHAIN}/bin/${HOST}-gcc)
 +    set(CMAKE_FIND_ROOT_PATH ${TOOLCHAIN}/${HOST})
 +    EOF
  
      cd {build_directory}
 -    cmake -G"Visual Studio 10" [additional CMake flags] {source_directory}
 -
 -NOTE: Add "Win64" to the generator name (for example, "Visual Studio 10
 -Win64") to build a 64-bit version of libjpeg-turbo.  A separate build directory
 -must be used for 32-bit and 64-bit builds.
 -
 -You can then open **ALL_BUILD.vcproj** in Visual Studio and build one of the
 -configurations in that project ("Debug", "Release", etc.) to generate a full
 -build of libjpeg-turbo.
 -
 -This will generate the following files under *{build_directory}*:
 -
 -**{configuration}/jpeg-static.lib**<br>
 -Static link library for the libjpeg API
 -
 -**sharedlib/{configuration}/jpeg{version}.dll**<br>
 -DLL for the libjpeg API
 -
 -**sharedlib/{configuration}/jpeg.lib**<br>
 -Import library for the libjpeg API
 -
 -**{configuration}/turbojpeg-static.lib**<br>
 -Static link library for the TurboJPEG API
 -
 -**{configuration}/turbojpeg.dll**<br>
 -DLL for the TurboJPEG API
 -
 -**{configuration}/turbojpeg.lib**<br>
 -Import library for the TurboJPEG API
 -
 -*{configuration}* is Debug, Release, RelWithDebInfo, or MinSizeRel, depending
 -on the configuration you built in the IDE, and *{version}* is 62, 7, or 8,
 -depending on whether libjpeg v6b (default), v7, or v8 emulation is enabled.
 -
 -
 -### MinGW
 -
 -NOTE: This assumes that you are building on a Windows machine using the MSYS
 -environment.  If you are cross-compiling on a Un*x platform (including Mac and
 -Cygwin), then see "Build Recipes" below.
 -
 -    cd {build_directory}
 -    cmake -G"MSYS Makefiles" [additional CMake flags] {source_directory}
 +    cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
 +      -DCMAKE_POSITION_INDEPENDENT_CODE=1 \
 +      [additional CMake flags] {source_directory}
      make
  
 -This will generate the following files under *{build_directory}*:
 -
 -**libjpeg.a**<br>
 -Static link library for the libjpeg API
 -
 -**sharedlib/libjpeg-{version}.dll**<br>
 -DLL for the libjpeg API
 -
 -**sharedlib/libjpeg.dll.a**<br>
 -Import library for the libjpeg API
 -
 -**libturbojpeg.a**<br>
 -Static link library for the TurboJPEG API
 -
 -**libturbojpeg.dll**<br>
 -DLL for the TurboJPEG API
 -
 -**libturbojpeg.dll.a**<br>
 -Import library for the TurboJPEG API
 -
 -*{version}* is 62, 7, or 8, depending on whether libjpeg v6b (default), v7, or
 -v8 emulation is enabled.
 -
  
 -### Debug Build
 +If building for Android 4.0.x (API level < 16) or earlier, remove
 +`-DCMAKE_POSITION_INDEPENDENT_CODE=1` from the CMake arguments and `-pie` from
 +`LDFLAGS`.
  
 -Add `-DCMAKE_BUILD_TYPE=Debug` to the CMake command line.  Or, if building
 -with NMake, remove `-DCMAKE_BUILD_TYPE=Release` (Debug builds are the default
 -with NMake.)
  
 +Advanced CMake Options
 +----------------------
  
 -### libjpeg v7 or v8 API/ABI Emulation
 +To list and configure other CMake options not specifically mentioned in this
 +guide, run
  
 -Add `-DWITH_JPEG7=1` to the CMake command line to build a version of
 -libjpeg-turbo that is API/ABI-compatible with libjpeg v7.  Add `-DWITH_JPEG8=1`
 -to the CMake command line to build a version of libjpeg-turbo that is
 -API/ABI-compatible with libjpeg v8.  See [README.md](README.md) for more
 -information about libjpeg v7 and v8 emulation.
 +    ccmake {source_directory}
  
 +or
  
 -### In-Memory Source/Destination Managers
 -
 -When using libjpeg v6b or v7 API/ABI emulation, add `-DWITH_MEM_SRCDST=0` to
 -the CMake command line to build a version of libjpeg-turbo that lacks the
 -`jpeg_mem_src()` and `jpeg_mem_dest()` functions.  These functions were not
 -part of the original libjpeg v6b and v7 APIs, so removing them ensures strict
 -conformance with those APIs.  See [README.md](README.md) for more information.
 +    cmake-gui {source_directory}
  
 -
 -### Arithmetic Coding Support
 -
 -Since the patent on arithmetic coding has expired, this functionality has been
 -included in this release of libjpeg-turbo.  libjpeg-turbo's implementation is
 -based on the implementation in libjpeg v8, but it works when emulating libjpeg
 -v7 or v6b as well.  The default is to enable both arithmetic encoding and
 -decoding, but those who have philosophical objections to arithmetic coding can
 -add `-DWITH_ARITH_ENC=0` or `-DWITH_ARITH_DEC=0` to the CMake command line to
 -disable encoding or decoding (respectively.)
 -
 -
 -### TurboJPEG Java Wrapper
 -
 -Add `-DWITH_JAVA=1` to the CMake command line to incorporate an optional Java
 -Native Interface (JNI) wrapper into the TurboJPEG shared library and build the
 -Java front-end classes to support it.  This allows the TurboJPEG shared library
 -to be used directly from Java applications.  See [java/README](java/README) for
 -more details.
 -
 -If Java is not in your `PATH`, or if you wish to use an alternate JDK to
 -build/test libjpeg-turbo, then (prior to running CMake) set the `JAVA_HOME`
 -environment variable to the location of the JDK that you wish to use.  The
 -`Java_JAVAC_EXECUTABLE`, `Java_JAVA_EXECUTABLE`, and `Java_JAR_EXECUTABLE`
 -CMake variables can also be used to specify alternate commands or locations for
 -javac, jar, and java (respectively.)  You can also set the `JAVACFLAGS` CMake
 -variable to specify arguments that should be passed to the Java compiler when
 -building the TurboJPEG classes.
 -
 -
 -Build Recipes
 --------------
 -
 -
 -### 32-bit MinGW Build on Un*x (including Mac and Cygwin)
 -
 -Create a file called **toolchain.cmake** under *{build_directory}*, with the
 -following contents:
 -
 -    set(CMAKE_SYSTEM_NAME Windows)
 -    set(CMAKE_SYSTEM_PROCESSOR X86)
 -    set(CMAKE_C_COMPILER {mingw_binary_path}/i686-w64-mingw32-gcc)
 -    set(CMAKE_RC_COMPILER {mingw_binary_path}/i686-w64-mingw32-windres)
 -
 -*{mingw\_binary\_path}* is the directory under which the MinGW binaries are
 -located (usually **/usr/bin**.)  Next, execute the following commands:
 -
 -    cd {build_directory}
 -    cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
 -      [additional CMake flags] {source_directory}
 -    make
 -
 -
 -### 64-bit MinGW Build on Un*x (including Mac and Cygwin)
 -
 -Create a file called **toolchain.cmake** under *{build_directory}*, with the
 -following contents:
 -
 -    set(CMAKE_SYSTEM_NAME Windows)
 -    set(CMAKE_SYSTEM_PROCESSOR AMD64)
 -    set(CMAKE_C_COMPILER {mingw_binary_path}/x86_64-w64-mingw32-gcc)
 -    set(CMAKE_RC_COMPILER {mingw_binary_path}/x86_64-w64-mingw32-windres)
 -
 -*{mingw\_binary\_path}* is the directory under which the MinGW binaries are
 -located (usually **/usr/bin**.)  Next, execute the following commands:
 -
 -    cd {build_directory}
 -    cmake -G"Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake \
 -      [additional CMake flags] {source_directory}
 -    make
 +from the build directory after initially configuring the build.  CCMake is a
 +text-based interactive version of CMake, and CMake-GUI is a GUI version.  Both
 +will display all variables that are relevant to the libjpeg-turbo build, their
 +current values, and a help string describing what they do.
  
  
  Installing libjpeg-turbo
diff --cc ChangeLog.md
index 9f87a56,e44ddc8..28ace13
--- a/ChangeLog.md
+++ b/ChangeLog.md
@@@ -1,100 -1,12 +1,106 @@@
 -1.5.4
 -=====
 +1.6 pre-beta
 +============
 +
 +### 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. Fixed two signed integer overflows in the arithmetic decoder, detected by
++10. Fixed two signed integer overflows in the arithmetic decoder, detected by
+ the Clang undefined behavior sanitizer, that could be triggered by attempting
+ to decompress a specially-crafted malformed JPEG image.  These issues did not
+ pose a security threat, but removing the warnings makes it easier to detect
+ actual security issues, should they arise in the future.
+ 
  
  1.5.3
  =====