summaryrefslogtreecommitdiffstats
path: root/src/3rdparty/libjpeg/src/README.md
diff options
context:
space:
mode:
authorEirik Aavitsland <eirik.aavitsland@qt.io>2021-02-23 16:38:15 +0100
committerEirik Aavitsland <eirik.aavitsland@qt.io>2021-03-04 09:04:02 +0100
commitede0082f861146d441df641d93f815dbe63a9076 (patch)
treed299acaa3d169c5d25b6d65a53021f6d6e89a5d5 /src/3rdparty/libjpeg/src/README.md
parentfe9d7bf759d116f99131d14ac8b1fb44b2bc62fd (diff)
Update bundled libjpeg-turbo to version 2.0.6
[ChangeLog][Third-Party Code] libjpeg-turbo was updated to version 2.0.6 Pick-to: 6.1 6.0 5.15 5.12 Change-Id: I3e308d241853edf3c1d616955cda203220a258d8 Reviewed-by: Liang Qi <liang.qi@qt.io>
Diffstat (limited to 'src/3rdparty/libjpeg/src/README.md')
-rw-r--r--src/3rdparty/libjpeg/src/README.md21
1 files changed, 11 insertions, 10 deletions
diff --git a/src/3rdparty/libjpeg/src/README.md b/src/3rdparty/libjpeg/src/README.md
index e7ff743a47..90a4a43ee1 100644
--- a/src/3rdparty/libjpeg/src/README.md
+++ b/src/3rdparty/libjpeg/src/README.md
@@ -2,7 +2,7 @@ Background
==========
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
+baseline JPEG compression and decompression on x86, x86-64, Arm, PowerPC, and
MIPS systems, as well as progressive JPEG compression on x86 and x86-64
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
@@ -179,8 +179,8 @@ supported and 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.
@@ -287,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
@@ -340,7 +341,7 @@ 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.