Merge branch 'master' into dev
This commit is contained in:
@@ -1289,6 +1289,8 @@ if(WITH_TURBOJPEG)
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest -yuv -alloc
|
||||
COMMAND echo tjbenchtest -progressive
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest -progressive
|
||||
COMMAND echo tjbenchtest -progressive -yuv
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest -progressive -yuv
|
||||
COMMAND echo tjexampletest
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjexampletest
|
||||
COMMAND echo tjbenchtest.java
|
||||
@@ -1297,6 +1299,9 @@ if(WITH_TURBOJPEG)
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest.java -yuv
|
||||
COMMAND echo tjbenchtest.java -progressive
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest.java -progressive
|
||||
COMMAND echo tjexampletest.java -progressive -yuv
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest.java
|
||||
-progressive -yuv
|
||||
COMMAND echo tjexampletest.java
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjexampletest.java
|
||||
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest
|
||||
@@ -1312,6 +1317,10 @@ if(WITH_TURBOJPEG)
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest -yuv
|
||||
COMMAND echo tjbenchtest -yuv -alloc
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest -yuv -alloc
|
||||
COMMAND echo tjbenchtest -progressive
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest -progressive
|
||||
COMMAND echo tjbenchtest -progressive -yuv
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest -progressive -yuv
|
||||
COMMAND echo tjexampletest
|
||||
COMMAND ${BASH} ${CMAKE_CURRENT_BINARY_DIR}/tjexampletest
|
||||
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/tjbenchtest)
|
||||
|
||||
@@ -73,6 +73,11 @@ generate a progressive JPEG image on an SSE2-capable CPU using a scan script
|
||||
containing one or more scans with lengths divisible by 16 would result in an
|
||||
error ("Missing Huffman code table entry") and an invalid JPEG image.
|
||||
|
||||
6. Fixed an issue whereby `tjDecodeYUV()` and `tjDecodeYUVPlanes()` would throw
|
||||
an error ("Invalid progressive parameters") or a warning ("Inconsistent
|
||||
progression sequence") if passed a TurboJPEG instance that was previously used
|
||||
to decompress a progressive JPEG image.
|
||||
|
||||
|
||||
2.0.2
|
||||
=====
|
||||
|
||||
28
README.md
28
README.md
@@ -135,12 +135,11 @@ 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
|
||||
|
||||
@@ -247,9 +246,8 @@ 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.
|
||||
|
||||
@@ -344,3 +342,15 @@ 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
|
||||
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.
|
||||
|
||||
@@ -1432,6 +1432,9 @@ DLLEXPORT int tjDecodeYUVPlanes(tjhandle handle,
|
||||
else if (flags & TJFLAG_FORCESSE2) putenv("JSIMD_FORCESSE2=1");
|
||||
#endif
|
||||
|
||||
dinfo->progressive_mode = dinfo->inputctl->has_multiple_scans = FALSE;
|
||||
dinfo->Ss = dinfo->Ah = dinfo->Al = 0;
|
||||
dinfo->Se = DCTSIZE2 - 1;
|
||||
if (setDecodeDefaults(dinfo, pixelFormat, subsamp, flags) == -1) {
|
||||
retval = -1; goto bailout;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user