mirror of
https://repo.dactyloidae.xyz/Dactyloidae/UXP.git
synced 2026-09-26 02:17:34 +09:00
Issue #1933 - Part 1: Update build system for libjpeg-turbo.
This commit is contained in:
Job Bautista
roytam1
parent
8ad8bfb4ba
commit
75e223e3bf
8 changed files with 350 additions and 348 deletions
|
|
@ -1,13 +1,14 @@
|
|||
Background
|
||||
==========
|
||||
|
||||
libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2,
|
||||
NEON, AltiVec) to accelerate baseline JPEG compression and decompression on
|
||||
x86, x86-64, ARM, and PowerPC systems. On such systems, libjpeg-turbo is
|
||||
generally 2-6x as fast as libjpeg, all else being equal. On other types of
|
||||
systems, libjpeg-turbo can still outperform libjpeg by a significant amount, by
|
||||
virtue of its highly-optimized Huffman coding routines. In many cases, the
|
||||
performance of libjpeg-turbo rivals that of proprietary high-speed JPEG codecs.
|
||||
libjpeg-turbo is a JPEG image codec that uses SIMD instructions to accelerate
|
||||
baseline JPEG compression and decompression on x86, x86-64, Arm, PowerPC, and
|
||||
MIPS systems, as well as progressive JPEG compression on x86, x86-64, and Arm
|
||||
systems. On such systems, libjpeg-turbo is generally 2-6x as fast as libjpeg,
|
||||
all else being equal. On other types of systems, libjpeg-turbo can still
|
||||
outperform libjpeg by a significant amount, by virtue of its highly-optimized
|
||||
Huffman coding routines. In many cases, the performance of libjpeg-turbo
|
||||
rivals that of proprietary high-speed JPEG codecs.
|
||||
|
||||
libjpeg-turbo implements both the traditional libjpeg API as well as the less
|
||||
powerful but more straightforward TurboJPEG API. libjpeg-turbo also features
|
||||
|
|
@ -42,21 +43,25 @@ Using libjpeg-turbo
|
|||
libjpeg-turbo includes two APIs that can be used to compress and decompress
|
||||
JPEG images:
|
||||
|
||||
- **TurboJPEG API**
|
||||
- **TurboJPEG API**<br>
|
||||
This API provides an easy-to-use interface for compressing and decompressing
|
||||
JPEG images in memory. It also provides some functionality that would not be
|
||||
straightforward to achieve using the underlying libjpeg API, such as
|
||||
generating planar YUV images and performing multiple simultaneous lossless
|
||||
transforms on an image. The Java interface for libjpeg-turbo is written on
|
||||
top of the TurboJPEG API.
|
||||
top of the TurboJPEG API. The TurboJPEG API is recommended for first-time
|
||||
users of libjpeg-turbo. Refer to [tjexample.c](tjexample.c) and
|
||||
[TJExample.java](java/TJExample.java) for examples of its usage and to
|
||||
<http://libjpeg-turbo.org/Documentation/Documentation> for API documentation.
|
||||
|
||||
- **libjpeg API**
|
||||
- **libjpeg API**<br>
|
||||
This is the de facto industry-standard API for compressing and decompressing
|
||||
JPEG images. It is more difficult to use than the TurboJPEG API but also
|
||||
more powerful. The libjpeg API implementation in libjpeg-turbo is both
|
||||
API/ABI-compatible and mathematically compatible with libjpeg v6b. It can
|
||||
also optionally be configured to be API/ABI-compatible with libjpeg v7 and v8
|
||||
(see below.)
|
||||
(see below.) Refer to [cjpeg.c](cjpeg.c) and [djpeg.c](djpeg.c) for examples
|
||||
of its usage and to [libjpeg.txt](libjpeg.txt) for API documentation.
|
||||
|
||||
There is no significant performance advantage to either API when both are used
|
||||
to perform similar operations.
|
||||
|
|
@ -130,28 +135,27 @@ without recompiling. libjpeg-turbo does not claim to support all of the
|
|||
libjpeg v7+ features, nor to produce identical output to libjpeg v7+ in all
|
||||
cases (see below.)
|
||||
|
||||
By passing an argument of `--with-jpeg7` or `--with-jpeg8` to `configure`, or
|
||||
an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you can build a
|
||||
version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so that
|
||||
programs that are built against libjpeg v7 or v8 can be run with libjpeg-turbo.
|
||||
The following section describes which libjpeg v7+ features are supported and
|
||||
which aren't.
|
||||
By passing an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you
|
||||
can build a version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so
|
||||
that programs that are built against libjpeg v7 or v8 can be run with
|
||||
libjpeg-turbo. The following section describes which libjpeg v7+ features are
|
||||
supported and which aren't.
|
||||
|
||||
### Support for libjpeg v7 and v8 Features
|
||||
|
||||
#### Fully supported
|
||||
|
||||
- **libjpeg: IDCT scaling extensions in decompressor**
|
||||
- **libjpeg API: IDCT scaling extensions in decompressor**<br>
|
||||
libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8,
|
||||
1/2, 5/8, 3/4, 7/8, 9/8, 5/4, 11/8, 3/2, 13/8, 7/4, 15/8, and 2/1 (only 1/4
|
||||
and 1/2 are SIMD-accelerated.)
|
||||
|
||||
- **libjpeg: Arithmetic coding**
|
||||
- **libjpeg API: Arithmetic coding**
|
||||
|
||||
- **libjpeg: In-memory source and destination managers**
|
||||
- **libjpeg API: In-memory source and destination managers**<br>
|
||||
See notes below.
|
||||
|
||||
- **cjpeg: Separate quality settings for luminance and chrominance**
|
||||
- **cjpeg: Separate quality settings for luminance and chrominance**<br>
|
||||
Note that the libpjeg v7+ API was extended to accommodate this feature only
|
||||
for convenience purposes. It has always been possible to implement this
|
||||
feature with libjpeg v6b (see rdswitch.c for an example.)
|
||||
|
|
@ -175,19 +179,19 @@ which aren't.
|
|||
|
||||
NOTE: As of this writing, extensive research has been conducted into the
|
||||
usefulness of DCT scaling as a means of data reduction and SmartScale as a
|
||||
means of quality improvement. The reader is invited to peruse the research at
|
||||
<http://www.libjpeg-turbo.org/About/SmartScale> and draw his/her own conclusions,
|
||||
means of quality improvement. Readers are invited to peruse the research at
|
||||
<http://www.libjpeg-turbo.org/About/SmartScale> and draw their own conclusions,
|
||||
but it is the general belief of our project that these features have not
|
||||
demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.
|
||||
|
||||
- **libjpeg: DCT scaling in compressor**
|
||||
- **libjpeg API: DCT scaling in compressor**<br>
|
||||
`cinfo.scale_num` and `cinfo.scale_denom` are silently ignored.
|
||||
There is no technical reason why DCT scaling could not be supported when
|
||||
emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see
|
||||
below), only scaling factors of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and
|
||||
8/9 would be available, which is of limited usefulness.
|
||||
|
||||
- **libjpeg: SmartScale**
|
||||
- **libjpeg API: SmartScale**<br>
|
||||
`cinfo.block_size` is silently ignored.
|
||||
SmartScale is an extension to the JPEG format that allows for DCT block
|
||||
sizes other than 8x8. Providing support for this new format would be
|
||||
|
|
@ -200,15 +204,15 @@ demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.
|
|||
interest in providing this feature would be as a means of supporting
|
||||
additional DCT scaling factors.
|
||||
|
||||
- **libjpeg: Fancy downsampling in compressor**
|
||||
- **libjpeg API: Fancy downsampling in compressor**<br>
|
||||
`cinfo.do_fancy_downsampling` is silently ignored.
|
||||
This requires the DCT scaling feature, which is not supported.
|
||||
|
||||
- **jpegtran: Scaling**
|
||||
- **jpegtran: Scaling**<br>
|
||||
This requires both the DCT scaling and SmartScale features, which are not
|
||||
supported.
|
||||
|
||||
- **Lossless RGB JPEG files**
|
||||
- **Lossless RGB JPEG files**<br>
|
||||
This requires the SmartScale feature, which is not supported.
|
||||
|
||||
### What About libjpeg v9?
|
||||
|
|
@ -226,7 +230,7 @@ generally accomplish anything that can't already be accomplished better with
|
|||
existing, standard lossless formats. Therefore, at this time it is our belief
|
||||
that there is not sufficient technical justification for software projects to
|
||||
upgrade from libjpeg v8 to libjpeg v9, and thus there is not sufficient
|
||||
echnical justification for us to emulate the libjpeg v9 ABI.
|
||||
technical justification for us to emulate the libjpeg v9 ABI.
|
||||
|
||||
In-Memory Source/Destination Managers
|
||||
-------------------------------------
|
||||
|
|
@ -242,15 +246,14 @@ don't, and it allows those functions to be provided in the "official"
|
|||
libjpeg-turbo binaries.
|
||||
|
||||
Those who are concerned about maintaining strict conformance with the libjpeg
|
||||
v6b or v7 API can pass an argument of `--without-mem-srcdst` to `configure` or
|
||||
an argument of `-DWITH_MEM_SRCDST=0` to `cmake` prior to building
|
||||
libjpeg-turbo. This will restore the pre-1.3 behavior, in which
|
||||
v6b or v7 API can pass an argument of `-DWITH_MEM_SRCDST=0` to `cmake` prior to
|
||||
building libjpeg-turbo. This will restore the pre-1.3 behavior, in which
|
||||
`jpeg_mem_src()` and `jpeg_mem_dest()` are only included when emulating the
|
||||
libjpeg v8 API/ABI.
|
||||
|
||||
On Un*x systems, including the in-memory source/destination managers changes
|
||||
the dynamic library version from 62.0.0 to 62.1.0 if using libjpeg v6b API/ABI
|
||||
emulation and from 7.0.0 to 7.1.0 if using libjpeg v7 API/ABI emulation.
|
||||
the dynamic library version from 62.2.0 to 62.3.0 if using libjpeg v6b API/ABI
|
||||
emulation and from 7.2.0 to 7.3.0 if using libjpeg v7 API/ABI emulation.
|
||||
|
||||
Note that, on most Un*x systems, the dynamic linker will not look for a
|
||||
function in a library until that function is actually used. Thus, if a program
|
||||
|
|
@ -284,12 +287,13 @@ following reasons:
|
|||
(and slightly faster) floating point IDCT algorithm introduced in libjpeg
|
||||
v8a as opposed to the algorithm used in libjpeg v6b. It should be noted,
|
||||
however, that this algorithm basically brings the accuracy of the floating
|
||||
point IDCT in line with the accuracy of the slow integer IDCT. The floating
|
||||
point DCT/IDCT algorithms are mainly a legacy feature, and they do not
|
||||
produce significantly more accuracy than the slow integer algorithms (to put
|
||||
numbers on this, the typical difference in PNSR between the two algorithms
|
||||
is less than 0.10 dB, whereas changing the quality level by 1 in the upper
|
||||
range of the quality scale is typically more like a 1.0 dB difference.)
|
||||
point IDCT in line with the accuracy of the accurate integer IDCT. The
|
||||
floating point DCT/IDCT algorithms are mainly a legacy feature, and they do
|
||||
not produce significantly more accuracy than the accurate integer algorithms
|
||||
(to put numbers on this, the typical difference in PNSR between the two
|
||||
algorithms is less than 0.10 dB, whereas changing the quality level by 1 in
|
||||
the upper range of the quality scale is typically more like a 1.0 dB
|
||||
difference.)
|
||||
|
||||
- If the floating point algorithms in libjpeg-turbo are not implemented using
|
||||
SIMD instructions on a particular platform, then the accuracy of the
|
||||
|
|
@ -326,7 +330,7 @@ in a way that makes the rest of the libjpeg infrastructure happy, so it is
|
|||
necessary to use the slow Huffman decoder when decompressing a JPEG image that
|
||||
has restart markers. This can cause the decompression performance to drop by
|
||||
as much as 20%, but the performance will still be much greater than that of
|
||||
libjpeg. Many consumer packages, such as PhotoShop, use restart markers when
|
||||
libjpeg. Many consumer packages, such as Photoshop, use restart markers when
|
||||
generating JPEG images, so images generated by those programs will experience
|
||||
this issue.
|
||||
|
||||
|
|
@ -337,5 +341,17 @@ The algorithm used by the SIMD-accelerated quantization function cannot produce
|
|||
correct results whenever the fast integer forward DCT is used along with a JPEG
|
||||
quality of 98-100. Thus, libjpeg-turbo must use the non-SIMD quantization
|
||||
function in those cases. This causes performance to drop by as much as 40%.
|
||||
It is therefore strongly advised that you use the slow integer forward DCT
|
||||
It is therefore strongly advised that you use the accurate integer forward DCT
|
||||
whenever encoding images with a JPEG quality of 98 or higher.
|
||||
|
||||
|
||||
Memory Debugger Pitfalls
|
||||
========================
|
||||
|
||||
Valgrind and Memory Sanitizer (MSan) can generate false positives
|
||||
(specifically, incorrect reports of uninitialized memory accesses) when used
|
||||
with libjpeg-turbo's SIMD extensions. It is generally recommended that the
|
||||
SIMD extensions be disabled, either by passing an argument of `-DWITH_SIMD=0`
|
||||
to `cmake` when configuring the build or by setting the environment variable
|
||||
`JSIMD_FORCENONE` to `1` at run time, when testing libjpeg-turbo with Valgrind,
|
||||
MSan, or other memory debuggers.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue