Age | Commit message (Collapse) | Author |
|
|
|
|
|
https://codereview.chromium.org/1271803002/
"jpeg_skip_scanlines() API, a subset decoding optimization
aimed at Android, was submitted upstream r1582. Pull that
change, and sundry fixes, into the Chromium repo.
This new API is targetted at Android devices, not Chrome,
and should have no affect on JPEG decode behavior or perf
of Chrome.
Chrome uses suspending data source JPEG decoding, and the
new API does not support such sources. Adding support for
suspending data sources is a future TODO, should the need
arise (refer to skbug.com/4036)."
BUG=515694
BUG=468914
R=agable@chromium.org
Review URL: https://codereview.chromium.org/1291463002 .
|
|
It was submitted upstream at libjpeg_turbo as r1295 plus
sundry fixes and SIMD optimizations (r1385, r1386, r1398,
and r1402). Now cherry pick the change into
third_party/libjpeg-turbo.
At this time, this new capability is intended for Android
devices, not Chrome, and should have no affect on JPEG
decode behavior or perf of Chrome.
BUG=516761
R=noel@chromium.org
Review URL: https://codereview.chromium.org/1270213002 .
|
|
NASM 2.11.08 has a bug that prevents it from properly assembling a
macho64 version of libjpeg-turbo (the resulting binary generates corrupt
images.) 2.11.09 works properly. YASM also works properly and has been
a supported alternative since libjpeg-turbo 1.2.
|
|
NASM 2.11.08 has a bug that prevents it from properly assembling a
macho64 version of libjpeg-turbo (the resulting binary generates corrupt
images.) 2.11.09 works properly. YASM also works properly and has been
a supported alternative since libjpeg-turbo 1.2.
|
|
NASM 2.11.08 has a bug that prevents it from properly assembling a
macho64 version of libjpeg-turbo (the resulting binary generates corrupt
images.) 2.11.09 works properly. YASM also works properly and has been
a supported alternative since libjpeg-turbo 1.2.
|
|
|
|
jpeg_skip_scanlines() API, a subset decoding optimization
aimed at Android, was submitted upstream r1582. Pull that
change, and sundry fixes, into the Chromium repo.
This new API is targetted at Android devices, not Chrome,
and should have no affect on JPEG decode behavior or perf
of Chrome.
Chrome uses suspending data source JPEG decoding, and the
new API does not support such sources. Adding support for
suspending data sources is a future TODO, should the need
arise (refer to skbug.com/4036).
BUG=515694
BUG=468914
patch from issue 256280043 at patchset 50001 (http://crrev.com/256280043#ps50001)
R=agable@chromium.org
Review URL: https://codereview.chromium.org/1271803002 .
|
|
Under very rare circumstances, decompressing specific corrupt JPEG
images would create a situation whereby GET_BITS(1) was invoked
from within HUFF_DECODE_FAST() when bits_left=0. This produced a right
shift by a negative number of bits, which is undefined in C.
|
|
Under very rare circumstances, decompressing specific corrupt JPEG
images would create a situation whereby GET_BITS(1) was invoked
from within HUFF_DECODE_FAST() when bits_left=0. This produced a right
shift by a negative number of bits, which is undefined in C.
|
|
Under very rare circumstances, decompressing specific corrupt JPEG
images would create a situation whereby GET_BITS(1) was invoked
from within HUFF_DECODE_FAST() when bits_left=0. This produced a right
shift by a negative number of bits, which is undefined in C.
|
|
reproducible
|
|
|
|
|
|
|
|
|
|
|
|
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1597 632fc199-4ca6-4c93-a231-07263d6284db
|
|
already defined it (code borrowed from libjpeg v8.) This isn't necessary when using the libjpeg-turbo build system on Windows, because the CMake generated jconfig.h defines INT32 and then defines XMD_H to trick jmorecfg.h into not redefining it. However, some projects build libjpeg-turbo using their own build systems.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1593 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TurboJPEG, which currently only supports 8-bit samples), and tabs-->spaces
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1584 632fc199-4ca6-4c93-a231-07263d6284db
|
|
v4.7.x-v4.9.x do not perform as well as v4.2.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1572 632fc199-4ca6-4c93-a231-07263d6284db
|
|
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1570 632fc199-4ca6-4c93-a231-07263d6284db
|
|
buffer.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1567 632fc199-4ca6-4c93-a231-07263d6284db
|
|
This project is now hosted directly in Git, rather than being a subdirectory
of the svn chrome/trunk/deps project. This codereview.settings file will
ensure that it continues to be reviewed correctly.
BUG=chromium:492230
|
|
On Android, we produce an ARM build with optional NEON code paths.
Fix compilation issues when producing a NEON-only builds on ARM -
in such builds NEON is not optional.
Patch prepared by fdegans@chromium.org
BUG=451035
R=fdegans@chromium.org
Review URL: https://codereview.appspot.com/245180043
git-svn-id: http://src.chromium.org/svn/trunk/deps/third_party/libjpeg_turbo@295576 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
|
|
"Invalid SOS parameters for sequential JPEG" warning surfaced in tjDecodeYUV*(). This was caused by the Se member of jpeg_decompress_struct being set to 0 (it is normally set to a non-zero value when the start-of-scan markers are read, but there are no SOS markers in this case, because we're not actually decompressing a JPEG file.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1564 632fc199-4ca6-4c93-a231-07263d6284db
|
|
downsampled_width==3. Because the DSPr2 code unrolls the loop for the middle columns (refer to jdsample.c), it has the effect of performing two column iterations, and that only works properly if the number of columns (minus the first and last) is >= 2. For the specific case of downsampled_width==3, this patch skips to the second iteration of the unrolled column loop.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1562 632fc199-4ca6-4c93-a231-07263d6284db
|
|
underlying libjpeg API, make sure that the TurboJPEG API function returns -1. Unlike errors, however, libjpeg warnings do not make the TurboJPEG functions abort.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1561 632fc199-4ca6-4c93-a231-07263d6284db
|
|
issue. It just replaced an undefined _putenv$UNIX2003 symbol with an undefined _setenv$UNIX2003 symbol. The correct solution seems to be to use -D_NONSTD_SOURCE when generating our official builds.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1557 632fc199-4ca6-4c93-a231-07263d6284db
|
|
because Windows doesn't have setenv(). We could use _putenv_s(), but older versions of MinGW don't have that either. Fortunately, since all of the environment values we're setting in turbojpeg.c are static, we can just map setenv() to putenv() using a macro. NOTE: we still have to use _putenv_s() in turbojpeg-jni.c, but at least people who may need to build with an older version of MinGW can still do so by disabling the Java build.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1555 632fc199-4ca6-4c93-a231-07263d6284db
|
|
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1553 632fc199-4ca6-4c93-a231-07263d6284db
|