Merge branch 'master' into dev

This commit is contained in:
DRC
2019-09-04 18:58:12 -05:00
4 changed files with 36 additions and 9 deletions

View File

@@ -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)

View File

@@ -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
=====

View File

@@ -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.

View File

@@ -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;
}