#10576: libjpeg-turbo-1.5.90
-------------------------+-----------------------
Reporter: bdubbs | Owner: bdubbs
Type: enhancement | Status: assigned
Priority: normal | Milestone: 8.3
Component: BOOK | Version: SVN
Severity: normal | Resolution:
Keywords: |
-------------------------+-----------------------
Comment (by bdubbs):
Note -- Changing to cmake with removal of autotools. I expect the next
stable version to be either 1.6 or 2.0.
It is beta1. Will defer until a stable release. Release notes so far:
1. Added AVX2 SIMD implementations of the colorspace conversion, chroma
downsampling and upsampling, integer quantization and sample conversion,
and
slow integer DCT/IDCT algorithms. When using the slow integer DCT/IDCT
algorithms on AVX2-equipped CPUs, the compression of RGB images is
approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x)
with
64-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the
decompression of RGB images is approximately 9-35% (avg. 17%) faster with
64-bit code and 7-17% (avg. 12%) faster with 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.
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.
11. Fixed a bug in the merged 4:2:0 upsampling/dithered RGB565 color
conversion
algorithm that caused incorrect dithering in the output image. This
algorithm
now produces bitwise-identical results to the unmerged algorithms.
12. The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64]
(if
libjpeg-turbo is built with YASM), and iOS/ARM[64] builds are now private.
This prevents those symbols from being exposed in applications or shared
libraries that link statically with libjpeg-turbo.
13. Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and
YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy
chroma upsampling, integer quantization, and slow integer DCT/IDCT
algorithms.
When using the slow integer DCT/IDCT, this speeds up the compression of
RGB
images by approximately 70-100% and the decompression of RGB images by
approximately 2-3.5x.
14. Fixed a build error when building with older MinGW releases
(regression
caused by 1.5.1[7].)
15. Added SIMD acceleration for progressive Huffman encoding on
SSE2-capable
x86 and x86-64 platforms. This speeds up the compression of full-color
progressive JPEGs by about 85-90% on average (relative to libjpeg-turbo
1.5.x)
when using modern Intel and AMD CPUs.
--
Ticket URL: <http://wiki.linuxfromscratch.org/blfs/ticket/10576#comment:2>
BLFS Trac <http://wiki.linuxfromscratch.org/blfs>
Beyond Linux From Scratch
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
