roytam1/UXP
1
0
Fork 0
mirror of https://github.com/roytam1/UXP.git synced 2026-05-26 13:58:49 +00:00
Code Issues Projects Releases Wiki Activity

Issue #1933 - Part 1: Update build system for libjpeg-turbo.

Browse Source
This commit is contained in:
Job Bautista
2022-06-24 22:33:06 +08:00
committed by roytam1
parent 8ad8bfb4ba
commit 75e223e3bf
8 changed files with 346 additions and 344 deletions
Download Patch File Download Diff File Expand all files Collapse all files
media/libjpeg/1050342.diff
-121
View File
@@ -1,121 +0,0 @@
Bug 1050342. Fix a case where the fast huffman decoder in libjpeg-turbo can produce different results depending on how data is fed to it.
This change comes from the blink repo https://codereview.appspot.com/229430043/ and is unlikely to be accepted upstream into libjpeg-turbo.
diff --git jdhuff.c jdhuff.c
--- jdhuff.c
+++ jdhuff.c
@@ -664,17 +664,17 @@ decode_mcu_fast (j_decompress_ptr cinfo,
ASSIGN_STATE(state, entropy->saved);
for (blkn = 0; blkn < cinfo->blocks_in_MCU; blkn++) {
JBLOCKROW block = MCU_data ? MCU_data[blkn] : NULL;
d_derived_tbl *dctbl = entropy->dc_cur_tbls[blkn];
d_derived_tbl *actbl = entropy->ac_cur_tbls[blkn];
register int s, k, r, l;
- HUFF_DECODE_FAST(s, l, dctbl);
+ HUFF_DECODE_FAST(s, l, dctbl, slow_decode_mcu);
if (s) {
FILL_BIT_BUFFER_FAST
r = GET_BITS(s);
s = HUFF_EXTEND(r, s);
}
if (entropy->dc_needed[blkn]) {
int ci = cinfo->MCU_membership[blkn];
@@ -682,17 +682,17 @@ decode_mcu_fast (j_decompress_ptr cinfo,
state.last_dc_val[ci] = s;
if (block)
(*block)[0] = (JCOEF) s;
}
if (entropy->ac_needed[blkn] && block) {
for (k = 1; k < DCTSIZE2; k++) {
- HUFF_DECODE_FAST(s, l, actbl);
+ HUFF_DECODE_FAST(s, l, actbl, slow_decode_mcu);
r = s >> 4;
s &= 15;
if (s) {
k += r;
FILL_BIT_BUFFER_FAST
r = GET_BITS(s);
s = HUFF_EXTEND(r, s);
@@ -701,33 +701,34 @@ decode_mcu_fast (j_decompress_ptr cinfo,
if (r != 15) break;
k += 15;
}
}
} else {
for (k = 1; k < DCTSIZE2; k++) {
- HUFF_DECODE_FAST(s, l, actbl);
+ HUFF_DECODE_FAST(s, l, actbl, slow_decode_mcu);
r = s >> 4;
s &= 15;
if (s) {
k += r;
FILL_BIT_BUFFER_FAST
DROP_BITS(s);
} else {
if (r != 15) break;
k += 15;
}
}
}
}
if (cinfo->unread_marker != 0) {
+slow_decode_mcu:
cinfo->unread_marker = 0;
return FALSE;
}
br_state.bytes_in_buffer -= (buffer - br_state.next_input_byte);
br_state.next_input_byte = buffer;
BITREAD_SAVE_STATE(cinfo,entropy->bitstate);
ASSIGN_STATE(entropy->saved, state);
diff --git jdhuff.h jdhuff.h
--- jdhuff.h
+++ jdhuff.h
@@ -203,32 +203,34 @@ EXTERN(boolean) jpeg_fill_bit_buffer
} else { \
slowlabel: \
if ((result=jpeg_huff_decode(&state,get_buffer,bits_left,htbl,nb)) < 0) \
{ failaction; } \
get_buffer = state.get_buffer; bits_left = state.bits_left; \
} \
}
-#define HUFF_DECODE_FAST(s,nb,htbl) \
+#define HUFF_DECODE_FAST(s,nb,htbl,slowlabel) \
FILL_BIT_BUFFER_FAST; \
s = PEEK_BITS(HUFF_LOOKAHEAD); \
s = htbl->lookup[s]; \
nb = s >> HUFF_LOOKAHEAD; \
/* Pre-execute the common case of nb <= HUFF_LOOKAHEAD */ \
DROP_BITS(nb); \
s = s & ((1 << HUFF_LOOKAHEAD) - 1); \
if (nb > HUFF_LOOKAHEAD) { \
/* Equivalent of jpeg_huff_decode() */ \
/* Don't use GET_BITS() here because we don't want to modify bits_left */ \
s = (get_buffer >> bits_left) & ((1 << (nb)) - 1); \
while (s > htbl->maxcode[nb]) { \
s <<= 1; \
s |= GET_BITS(1); \
nb++; \
} \
- s = htbl->pub->huffval[ (int) (s + htbl->valoffset[nb]) & 0xFF ]; \
+ if (nb > 16) \
+ goto slowlabel; \
+ s = htbl->pub->huffval[ (int) (s + htbl->valoffset[nb]) ]; \
}
/* Out-of-line case for Huffman code fetching */
EXTERN(int) jpeg_huff_decode
(bitread_working_state *state, register bit_buf_type get_buffer,
register int bits_left, d_derived_tbl *htbl, int min_bits);
media/libjpeg/LICENSE.md
+49 -5
View File
@@ -9,12 +9,12 @@ libjpeg-turbo is covered by three compatible BSD-style open source licenses:
This license applies to the libjpeg API library and associated programs
(any code inherited from libjpeg, and any modifications to that code.)
- The Modified (3-clause) BSD License, which is listed in
[turbojpeg.c](turbojpeg.c)
- The Modified (3-clause) BSD License, which is listed below
This license covers the TurboJPEG API library and associated programs.
This license covers the TurboJPEG API library and associated programs, as
well as the build system.
- The zlib License, which is listed in [simd/jsimdext.inc](simd/jsimdext.inc)
- The [zlib License](https://opensource.org/licenses/Zlib)
This license is a subset of the other two, and it covers the libjpeg-turbo
SIMD extensions.
@@ -66,7 +66,7 @@ best of our understanding.
2. If your binary distribution includes or uses the TurboJPEG API, then
your product documentation must include the text of the Modified BSD
License.
License (see below.)
**Origin**
- Clause 2 of the Modified BSD License
@@ -86,3 +86,47 @@ best of our understanding.
- IJG License
- Modified BSD License
- zlib License
The Modified (3-clause) BSD License
===================================
Copyright (C)2009-2022 D. R. Commander. All Rights Reserved.<br>
Copyright (C)2015 Viktor Szathmáry. All Rights Reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
- Neither the name of the libjpeg-turbo Project nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS",
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
Why Three Licenses?
===================
The zlib License could have been used instead of the Modified (3-clause) BSD
License, and since the IJG License effectively subsumes the distribution
conditions of the zlib License, this would have effectively placed
libjpeg-turbo binary distributions under the IJG License. However, the IJG
License specifically refers to the Independent JPEG Group and does not extend
attribution and endorsement protections to other entities. Thus, it was
desirable to choose a license that granted us the same protections for new code
that were granted to the IJG for code derived from their software.
media/libjpeg/MOZCHANGES
+28
View File
@@ -48,6 +48,34 @@ To upgrade to a new revision of libjpeg-turbo, do the following:
$ hg addremove
== February 28, 2022 (libjpeg-turbo v2.1.3 c5f269eb9665435271c05fbcaf8721fa58e9eafa 2022-02-25) ==
* Updated to v2.1.3 release.
== September 9, 2021 (libjpeg-turbo v2.1.1 0a9b9721782d3a60a5c16c8c9a7abf3d4b1ecd42 2020-08-10) ==
* Updated to v2.1.1 release.
== November 19, 2020 (libjpeg-turbo v2.0.6 10ba6ed3365615ed5c2995fe2d240cb2d5000173 2020-11-16) ==
* Updated to v2.0.6 release.
== January 6, 2020 (libjpeg-turbo v2.0.4 166e34213e4f4e2363ce058a7bcc69fd03e38b76 2019-12-31) ==
* Updated to v2.0.4 release.
== September 5, 2019 (libjpeg-turbo v2.0.3 5db6a6819d0f904e0b58f34ae928fea234adb1a0 2019-09-04) ==
* Updated to v2.0.3 release.
== October 4, 2018 (libjpeg-turbo v2.0.0 574f3a772c96dc9db2c98ef24706feb3f6dbda9a 2018-06-27) ==
* Updated to v2.0.0 release.
== July 13, 2017 (libjpeg-turbo v1.5.2 e5c1613ccdfeffcd060fd94248b7c8ac7c0cfb0f 2017-08-09) ==
* Updated to v1.5.2 release.
== September 22, 2016 (libjpeg-turbo v1.5.1 cb88e5da8003afcdc443b787fdcb77285e5a8a02 2016-09-20) ==
* Updated to v1.5.1 release.
media/libjpeg/README.ijg
+35 -56
View File
@@ -43,7 +43,7 @@ User documentation:
change.log Version-to-version change highlights.
Programmer and internal documentation:
libjpeg.txt How to use the JPEG library in your own programs.
example.c Sample code for calling the JPEG library.
example.txt Sample code for calling the JPEG library.
structure.txt Overview of the JPEG library's internal structure.
coderules.txt Coding style rules --- please read if you contribute code.
@@ -128,7 +128,7 @@ with respect to this software, its quality, accuracy, merchantability, or
fitness for a particular purpose. This software is provided "AS IS", and you,
its user, assume the entire risk as to its quality and accuracy.
This software is copyright (C) 1991-2016, Thomas G. Lane, Guido Vollbeding.
This software is copyright (C) 1991-2020, Thomas G. Lane, Guido Vollbeding.
All Rights Reserved except as specified below.
Permission is hereby granted to use, copy, modify, and distribute this
@@ -159,25 +159,6 @@ commercial products, provided that all warranty or liability claims are
assumed by the product vendor.
The Unix configuration script "configure" was produced with GNU Autoconf.
It is copyright by the Free Software Foundation but is freely distributable.
The same holds for its supporting scripts (config.guess, config.sub,
ltmain.sh). Another support script, install-sh, is copyright by X Consortium
but is also freely distributable.
The IJG distribution formerly included code to read and write GIF files.
To avoid entanglement with the Unisys LZW patent (now expired), GIF reading
support has been removed altogether, and the GIF writer has been simplified
to produce "uncompressed GIFs". This technique does not use the LZW
algorithm; the resulting GIF files are larger than usual, but are readable
by all standard GIF decoders.
We are required to state that
"The Graphics Interchange Format(c) is the Copyright property of
CompuServe Incorporated. GIF(sm) is a Service Mark property of
CompuServe Incorporated."
REFERENCES
==========
@@ -185,8 +166,8 @@ We recommend reading one or more of these references before trying to
understand the innards of the JPEG software.
The best short technical introduction to the JPEG compression algorithm is
Wallace, Gregory K. "The JPEG Still Picture Compression Standard",
Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
Wallace, Gregory K. "The JPEG Still Picture Compression Standard",
Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
(Adjacent articles in that issue discuss MPEG motion picture compression,
applications of JPEG, and related topics.) If you don't have the CACM issue
handy, a PDF file containing a revised version of Wallace's article is
@@ -220,21 +201,21 @@ Continuous-tone Still Images, Part 2: Compliance testing" and has document
numbers ISO/IEC IS 10918-2, ITU-T T.83.
The JPEG standard does not specify all details of an interchangeable file
format. For the omitted details we follow the "JFIF" conventions, revision
1.02. JFIF 1.02 has been adopted as an Ecma International Technical Report
and thus received a formal publication status. It is available as a free
download in PDF format from
http://www.ecma-international.org/publications/techreports/E-TR-098.htm.
A PostScript version of the JFIF document is available at
http://www.ijg.org/files/jfif.ps.gz. There is also a plain text version at
http://www.ijg.org/files/jfif.txt.gz, but it is missing the figures.
format. For the omitted details, we follow the "JFIF" conventions, revision
1.02. JFIF version 1 has been adopted as ISO/IEC 10918-5 (05/2013) and
Recommendation ITU-T T.871 (05/2011): Information technology - Digital
compression and coding of continuous-tone still images: JPEG File Interchange
Format (JFIF). It is available as a free download in PDF file format from
https://www.iso.org/standard/54989.html and http://www.itu.int/rec/T-REC-T.871.
A PDF file of the older JFIF 1.02 specification is available at
http://www.w3.org/Graphics/JPEG/jfif3.pdf.
The TIFF 6.0 file format specification can be obtained by FTP from
ftp://ftp.sgi.com/graphics/tiff/TIFF6.ps.gz. The JPEG incorporation scheme
found in the TIFF 6.0 spec of 3-June-92 has a number of serious problems.
IJG does not recommend use of the TIFF 6.0 design (TIFF Compression tag 6).
Instead, we recommend the JPEG design proposed by TIFF Technical Note #2
(Compression tag 7). Copies of this Note can be obtained from
The TIFF 6.0 file format specification can be obtained from
http://mirrors.ctan.org/graphics/tiff/TIFF6.ps.gz. The JPEG incorporation
scheme found in the TIFF 6.0 spec of 3-June-92 has a number of serious
problems. IJG does not recommend use of the TIFF 6.0 design (TIFF Compression
tag 6). Instead, we recommend the JPEG design proposed by TIFF Technical Note
#2 (Compression tag 7). Copies of this Note can be obtained from
http://www.ijg.org/files/. It is expected that the next revision
of the TIFF spec will replace the 6.0 JPEG design with the Note's design.
Although IJG's own code does not support TIFF/JPEG, the free libtiff library
@@ -249,28 +230,26 @@ The most recent released version can always be found there in
directory "files".
The JPEG FAQ (Frequently Asked Questions) article is a source of some
general information about JPEG.
It is available on the World Wide Web at http://www.faqs.org/faqs/jpeg-faq/
and other news.answers archive sites, including the official news.answers
archive at rtfm.mit.edu: ftp://rtfm.mit.edu/pub/usenet/news.answers/jpeg-faq/.
If you don't have Web or FTP access, send e-mail to mail-server@rtfm.mit.edu
with body
send usenet/news.answers/jpeg-faq/part1
send usenet/news.answers/jpeg-faq/part2
general information about JPEG. It is available at
http://www.faqs.org/faqs/jpeg-faq.
FILE FORMAT WARS
================
FILE FORMAT COMPATIBILITY
=========================
The ISO/IEC JTC1/SC29/WG1 standards committee (also known as JPEG, together
with ITU-T SG16) currently promotes different formats containing the name
"JPEG" which are incompatible with original DCT-based JPEG. IJG therefore does
not support these formats (see REFERENCES). Indeed, one of the original
reasons for developing this free software was to help force convergence on
common, interoperable format standards for JPEG files.
Don't use an incompatible file format!
(In any case, our decoder will remain capable of reading existing JPEG
image files indefinitely.)
This software implements ITU T.81 | ISO/IEC 10918 with some extensions from
ITU T.871 | ISO/IEC 10918-5 (JPEG File Interchange Format-- see REFERENCES).
Informally, the term "JPEG image" or "JPEG file" most often refers to JFIF or
a subset thereof, but there are other formats containing the name "JPEG" that
are incompatible with the DCT-based JPEG standard or with JFIF (for instance,
JPEG 2000 and JPEG XR). This software therefore does not support these
formats. Indeed, one of the original reasons for developing this free software
was to help force convergence on a common, interoperable format standard for
JPEG files.
JFIF is a minimal or "low end" representation. TIFF/JPEG (TIFF revision 6.0 as
modified by TIFF Technical Note #2) can be used for "high end" applications
that need to record a lot of additional data about an image.
TO DO
media/libjpeg/README.md
+58 -42
View File
@@ -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.
media/libjpeg/moz.build
+167 -56
View File
@@ -1,4 +1,5 @@
# -*- Mode: python; indent-tabs-mode: nil; tab-width: 40 -*-
# vim: set filetype=python:
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
@@ -22,6 +23,7 @@ SOURCES += [
'jdcolor.c',
'jddctmgr.c',
'jdhuff.c',
'jdicc.c',
'jdinput.c',
'jdmainct.c',
'jdmarker.c',
@@ -54,6 +56,7 @@ SOURCES += [
'jccolor.c',
'jcdctmgr.c',
'jchuff.c',
'jcicc.c',
'jcinit.c',
'jcmainct.c',
'jcmarker.c',
@@ -70,85 +73,193 @@ if CONFIG['LIBJPEG_TURBO_USE_YASM']:
if CONFIG['LIBJPEG_TURBO_ASFLAGS']:
if CONFIG['CPU_ARCH'] == 'arm':
LOCAL_INCLUDES += [
'/media/libjpeg/simd/arm',
'/media/libjpeg/simd/arm/aarch32',
]
SOURCES += [
'simd/jsimd_arm.c',
'simd/jsimd_arm_neon.S',
'simd/arm/aarch32/jchuff-neon.c',
'simd/arm/aarch32/jsimd.c',
'simd/arm/aarch32/jsimd_neon.S',
'simd/arm/jcgray-neon.c',
'simd/arm/jcphuff-neon.c',
'simd/arm/jcsample-neon.c',
'simd/arm/jdcolor-neon.c',
'simd/arm/jdmerge-neon.c',
'simd/arm/jdsample-neon.c',
'simd/arm/jfdctfst-neon.c',
'simd/arm/jfdctint-neon.c',
'simd/arm/jidctred-neon.c',
'simd/arm/jquanti-neon.c',
]
elif CONFIG['CPU_ARCH'] == 'aarch64':
SOURCES += [
'simd/jsimd_arm64.c',
'simd/jsimd_arm64_neon.S',
]
elif CONFIG['CPU_ARCH'] == 'mips':
elif CONFIG['CPU_ARCH'] == 'aarch64':
LOCAL_INCLUDES += [
'/media/libjpeg/simd/arm',
'/media/libjpeg/simd/arm/aarch64',
]
SOURCES += [
'simd/arm/aarch64/jsimd.c',
'simd/arm/aarch64/jsimd_neon.S',
'simd/arm/jcgray-neon.c',
'simd/arm/jcphuff-neon.c',
'simd/arm/jcsample-neon.c',
'simd/arm/jdmerge-neon.c',
'simd/arm/jdsample-neon.c',
'simd/arm/jfdctfst-neon.c',
'simd/arm/jidctfst-neon.c',
'simd/arm/jidctred-neon.c',
'simd/arm/jquanti-neon.c',
]
elif CONFIG['CPU_ARCH'] == 'mips32':
SOURCES += [
'simd/jsimd_mips.c',
'simd/jsimd_mips_dspr2.S',
]
if CONFIG['CC_TYPE'] == 'clang':
SOURCES['simd/mips/jsimd_dspr2.S'].flags += [
'-fno-integrated-as',
]
elif CONFIG['CPU_ARCH'] == 'mips64':
LOCAL_INCLUDES += ['/media/libjpeg/simd/mips64']
SOURCES += [
'simd/mips64/jccolor-mmi.c',
'simd/mips64/jcgray-mmi.c',
'simd/mips64/jcsample-mmi.c',
'simd/mips64/jdcolor-mmi.c',
'simd/mips64/jdmerge-mmi.c',
'simd/mips64/jdsample-mmi.c',
'simd/mips64/jfdctfst-mmi.c',
'simd/mips64/jfdctint-mmi.c',
'simd/mips64/jidctfst-mmi.c',
'simd/mips64/jidctint-mmi.c',
'simd/mips64/jquanti-mmi.c',
'simd/mips64/jsimd.c',
]
elif CONFIG['CPU_ARCH'] == 'x86_64':
SOURCES += [
'simd/jccolor-sse2-64.asm',
'simd/jcgray-sse2-64.asm',
'simd/jchuff-sse2-64.asm',
'simd/jcsample-sse2-64.asm',
'simd/jdcolor-sse2-64.asm',
'simd/jdmerge-sse2-64.asm',
'simd/jdsample-sse2-64.asm',
'simd/jfdctflt-sse-64.asm',
'simd/jfdctfst-sse2-64.asm',
'simd/jfdctint-sse2-64.asm',
'simd/jidctflt-sse2-64.asm',
'simd/jidctfst-sse2-64.asm',
'simd/jidctint-sse2-64.asm',
'simd/jidctred-sse2-64.asm',
'simd/jquantf-sse2-64.asm',
'simd/jquanti-sse2-64.asm',
'simd/jsimd_x86_64.c',
'simd/x86_64/jccolor-avx2.asm',
'simd/x86_64/jccolor-sse2.asm',
'simd/x86_64/jcgray-avx2.asm',
'simd/x86_64/jcgray-sse2.asm',
'simd/x86_64/jchuff-sse2.asm',
'simd/x86_64/jcphuff-sse2.asm',
'simd/x86_64/jcsample-avx2.asm',
'simd/x86_64/jcsample-sse2.asm',
'simd/x86_64/jdcolor-avx2.asm',
'simd/x86_64/jdcolor-sse2.asm',
'simd/x86_64/jdmerge-avx2.asm',
'simd/x86_64/jdmerge-sse2.asm',
'simd/x86_64/jdsample-avx2.asm',
'simd/x86_64/jdsample-sse2.asm',
'simd/x86_64/jfdctflt-sse.asm',
'simd/x86_64/jfdctfst-sse2.asm',
'simd/x86_64/jfdctint-avx2.asm',
'simd/x86_64/jfdctint-sse2.asm',
'simd/x86_64/jidctflt-sse2.asm',
'simd/x86_64/jidctfst-sse2.asm',
'simd/x86_64/jidctint-avx2.asm',
'simd/x86_64/jidctint-sse2.asm',
'simd/x86_64/jidctred-sse2.asm',
'simd/x86_64/jquantf-sse2.asm',
'simd/x86_64/jquanti-avx2.asm',
'simd/x86_64/jquanti-sse2.asm',
'simd/x86_64/jsimd.c',
'simd/x86_64/jsimdcpu.asm',
]
elif CONFIG['CPU_ARCH'] == 'x86':
SOURCES += [
'simd/jccolor-mmx.asm',
'simd/jccolor-sse2.asm',
'simd/jcgray-mmx.asm',
'simd/jcgray-sse2.asm',
'simd/jchuff-sse2.asm',
'simd/jcsample-mmx.asm',
'simd/jcsample-sse2.asm',
'simd/jdcolor-mmx.asm',
'simd/jdcolor-sse2.asm',
'simd/jdmerge-mmx.asm',
'simd/jdmerge-sse2.asm',
'simd/jdsample-mmx.asm',
'simd/jdsample-sse2.asm',
'simd/jfdctflt-3dn.asm',
'simd/jfdctflt-sse.asm',
'simd/jfdctfst-mmx.asm',
'simd/jfdctfst-sse2.asm',
'simd/jfdctint-mmx.asm',
'simd/jfdctint-sse2.asm',
'simd/jidctflt-3dn.asm',
'simd/jidctflt-sse.asm',
'simd/jidctflt-sse2.asm',
'simd/jidctfst-mmx.asm',
'simd/jidctfst-sse2.asm',
'simd/jidctint-mmx.asm',
'simd/jidctint-sse2.asm',
'simd/jidctred-mmx.asm',
'simd/jidctred-sse2.asm',
'simd/jquant-3dn.asm',
'simd/jquant-mmx.asm',
'simd/jquant-sse.asm',
'simd/jquantf-sse2.asm',
'simd/jquanti-sse2.asm',
'simd/jsimd_i386.c',
'simd/jsimdcpu.asm',
'simd/i386/jccolor-avx2.asm',
'simd/i386/jccolor-mmx.asm',
'simd/i386/jccolor-sse2.asm',
'simd/i386/jcgray-avx2.asm',
'simd/i386/jcgray-mmx.asm',
'simd/i386/jcgray-sse2.asm',
'simd/i386/jchuff-sse2.asm',
'simd/i386/jcphuff-sse2.asm',
'simd/i386/jcsample-avx2.asm',
'simd/i386/jcsample-mmx.asm',
'simd/i386/jcsample-sse2.asm',
'simd/i386/jdcolor-avx2.asm',
'simd/i386/jdcolor-mmx.asm',
'simd/i386/jdcolor-sse2.asm',
'simd/i386/jdmerge-avx2.asm',
'simd/i386/jdmerge-mmx.asm',
'simd/i386/jdmerge-sse2.asm',
'simd/i386/jdsample-avx2.asm',
'simd/i386/jdsample-mmx.asm',
'simd/i386/jdsample-sse2.asm',
'simd/i386/jfdctflt-3dn.asm',
'simd/i386/jfdctflt-sse.asm',
'simd/i386/jfdctfst-mmx.asm',
'simd/i386/jfdctfst-sse2.asm',
'simd/i386/jfdctint-avx2.asm',
'simd/i386/jfdctint-mmx.asm',
'simd/i386/jfdctint-sse2.asm',
'simd/i386/jidctflt-3dn.asm',
'simd/i386/jidctflt-sse.asm',
'simd/i386/jidctflt-sse2.asm',
'simd/i386/jidctfst-mmx.asm',
'simd/i386/jidctfst-sse2.asm',
'simd/i386/jidctint-avx2.asm',
'simd/i386/jidctint-mmx.asm',
'simd/i386/jidctint-sse2.asm',
'simd/i386/jidctred-mmx.asm',
'simd/i386/jidctred-sse2.asm',
'simd/i386/jquant-3dn.asm',
'simd/i386/jquant-mmx.asm',
'simd/i386/jquant-sse.asm',
'simd/i386/jquantf-sse2.asm',
'simd/i386/jquanti-avx2.asm',
'simd/i386/jquanti-sse2.asm',
'simd/i386/jsimd.c',
'simd/i386/jsimdcpu.asm',
]
elif CONFIG['CPU_ARCH'].startswith('ppc'):
# PowerPC has no assembly files, but still needs its own headers.
LOCAL_INCLUDES += ['/media/libjpeg/simd/powerpc']
# For libjpeg's internal runtime detection to work, jsimd.c must NOT
# be compiled with -maltivec (otherwise it gets statically set),
# but everything else should be. If -maltivec was already
# specified in .mozconfig, though, then this won't harm anything.
ppc_vmx_sources = [
'simd/powerpc/jccolor-altivec.c',
'simd/powerpc/jcgray-altivec.c',
'simd/powerpc/jcsample-altivec.c',
'simd/powerpc/jdcolor-altivec.c',
'simd/powerpc/jdmerge-altivec.c',
'simd/powerpc/jdsample-altivec.c',
'simd/powerpc/jfdctfst-altivec.c',
'simd/powerpc/jfdctint-altivec.c',
'simd/powerpc/jidctfst-altivec.c',
'simd/powerpc/jidctint-altivec.c',
'simd/powerpc/jquanti-altivec.c',
]
SOURCES += ppc_vmx_sources
SOURCES += [
'simd/powerpc/jsimd.c',
]
for srcfile in ppc_vmx_sources:
SOURCES[srcfile].flags += CONFIG['PPC_VMX_FLAGS']
else: # No SIMD support?
SOURCES += [
'jsimd_none.c',
]
ASFLAGS += CONFIG['LIBJPEG_TURBO_ASFLAGS']
ASFLAGS += ['-I%s/media/libjpeg/simd/' % TOPSRCDIR]
# Make sure the x86 & x86-64 ASM files can see the necessary includes.
if CONFIG['CPU_ARCH'] == 'x86':
ASFLAGS += ['-I%s/media/libjpeg/simd/nasm/' % TOPSRCDIR]
ASFLAGS += ['-I%s/media/libjpeg/simd/i386/' % TOPSRCDIR]
if CONFIG['CPU_ARCH'] == 'x86_64':
ASFLAGS += ['-I%s/media/libjpeg/simd/nasm/' % TOPSRCDIR]
ASFLAGS += ['-I%s/media/libjpeg/simd/x86_64/' % TOPSRCDIR]
# We allow warnings for third-party code that can be updated from upstream.
ALLOW_COMPILER_WARNINGS = True
media/libjpeg/mozilla.diff
+7 -60
View File
@@ -1,32 +1,7 @@
diff --git jmemmgr.c jmemmgr.c
--- jmemmgr.c
+++ jmemmgr.c
@@ -28,16 +28,17 @@
*/
#define JPEG_INTERNALS
#define AM_MEMORY_MANAGER /* we define jvirt_Xarray_control structs */
#include "jinclude.h"
#include "jpeglib.h"
#include "jmemsys.h" /* import the system-dependent declarations */
#include <stdint.h>
+#include <limits.h> /* some NDKs define SIZE_MAX in limits.h */
#ifndef NO_GETENV
#ifndef HAVE_STDLIB_H /* <stdlib.h> should declare getenv() */
extern char *getenv (const char *name);
#endif
#endif
diff --git jmorecfg.h jmorecfg.h
--- jmorecfg.h
+++ jmorecfg.h
@@ -9,16 +9,17 @@
* For conditions of distribution and use, see the accompanying README.ijg
* file.
*
* This file contains additional configuration options that customize the
@@ -13,8 +13,9 @@
* JPEG software for special applications or support machine-dependent
* optimizations. Most users will not need to touch this file.
*/
@@ -35,29 +10,13 @@ diff --git jmorecfg.h jmorecfg.h
/*
* Maximum number of components (color channels) allowed in JPEG image.
* To meet the letter of the JPEG spec, set this to 255. However, darn
* few applications need more than 4 channels (maybe 5 for CMYK + alpha
* mask). We recommend 10 as a reasonable compromise; use 4 if you are
* really short on memory. (Each allowed component costs a hundred or so
* bytes of storage, whether actually used in an image or not.)
@@ -118,39 +119,25 @@ typedef char JOCTET;
* They must be at least as wide as specified; but making them too big
* won't cost a huge amount of memory, so we don't provide special
* extraction code like we did for JSAMPLE. (In other words, these
* typedefs live at a different point on the speed/space tradeoff curve.)
* To meet the letter of Rec. ITU-T T.81 | ISO/IEC 10918-1, set this to 255.
@@ -95,23 +96,17 @@ typedef unsigned char JOCTET;
*/
/* UINT8 must hold at least the values 0..255. */
-#ifdef HAVE_UNSIGNED_CHAR
-typedef unsigned char UINT8;
-#else /* not HAVE_UNSIGNED_CHAR */
-#ifdef __CHAR_UNSIGNED__
-typedef char UINT8;
-#else /* not __CHAR_UNSIGNED__ */
-typedef short UINT8;
-#endif /* __CHAR_UNSIGNED__ */
-#endif /* HAVE_UNSIGNED_CHAR */
+typedef uint8_t UINT8;
/* UINT16 must hold at least the values 0..65535. */
@@ -79,23 +38,15 @@ diff --git jmorecfg.h jmorecfg.h
/* INT32 must hold at least signed 32-bit values.
*
* NOTE: The INT32 typedef dates back to libjpeg v5 (1994.) Integers were
* sometimes 16-bit back then (MS-DOS), which is why INT32 is typedef'd to
* long. It also wasn't common (or at least as common) in 1994 for INT32 to be
* defined by platform headers. Since then, however, INT32 is defined in
* several other common places:
@@ -167,25 +154,17 @@ typedef short INT16;
* This is a recipe for conflict, since "long" and "int" aren't always
* compatible types. Since the definition of INT32 has technically been part
* of the libjpeg API for more than 20 years, we can't remove it, but we do not
* use it internally any longer. We instead define a separate type (JLONG)
@@ -136,17 +131,9 @@ typedef short INT16;
* for internal use, which ensures that internal behavior will always be the
* same regardless of any external headers that may be included.
*/
-#ifndef XMD_H /* X11/xmd.h correctly defines INT32 */
-#ifndef _BASETSD_H_ /* Microsoft defines it in basetsd.h */
-#ifndef _BASETSD_H /* MinGW is slightly different */
-#ifndef QGLOBAL_H /* Qt defines it in qglobal.h */
-#ifndef _BASETSD_H_ /* Microsoft defines it in basetsd.h */
-#ifndef _BASETSD_H /* MinGW is slightly different */
-#ifndef QGLOBAL_H /* Qt defines it in qglobal.h */
-typedef long INT32;
-#endif
-#endif
@@ -106,7 +57,3 @@ diff --git jmorecfg.h jmorecfg.h
/* Datatype used for image dimensions. The JPEG standard only supports
* images up to 64K*64K due to 16-bit fields in SOF markers. Therefore
* "unsigned int" is sufficient on all machines. However, if you need to
* handle larger images and you don't mind deviating from the spec, you
* can change this datatype. (Note that changing this datatype will
* potentially require modifying the SIMD code. The x86-64 SIMD extensions,
* in particular, assume a 32-bit JDIMENSION.)
media/update-libjpeg.sh
+2 -4
View File
@@ -17,14 +17,12 @@ tag=${2-HEAD}
(cd $repo; git archive --prefix=media/libjpeg/ $tag) | (cd $srcdir/..; tar xf -)
cd $srcdir/libjpeg
cp win/jsimdcfg.inc simd/
revert_files="1050342.diff jconfig.h jconfigint.h moz.build MOZCHANGES mozilla.diff simd/jsimdcfg.inc"
revert_files="jconfig.h jconfigint.h moz.build MOZCHANGES mozilla.diff"
if test -d ${topsrcdir}/.hg; then
hg revert --no-backup $revert_files
elif test -d ${topsrcdir}/.git; then
elif test -e ${topsrcdir}/.git; then
git checkout HEAD -- $revert_files
fi
patch -p0 -i mozilla.diff
patch -p0 -i 1050342.diff