# 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
# 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
# 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
# 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
-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
=====
projects / libjpeg-turbo / commitdiff