|
32eaeeac
|
2018-02-24T18:00:51
|
|
Fix BUILDING.md buglet ("--mfloat-abi=softfp")
(Introduced with the build system overhaul)
Closes #215
|
|
|
4c4dc614
|
2018-02-24T12:07:34
|
|
Fix Win64 ABI conformance issue in AVX2 ISLOW IDCT
xmm8-xmm11 must be saved and restored, since the function uses
ymm8-ymm11.
Closes #211
|
|
|
feaec37d
|
2018-02-24T14:20:59
|
|
Fix build with YASM
vinserti128 requires all operands to be specified
|
|
|
b6909ab3
|
2018-02-24T00:02:27
|
|
Make SIMD symbols private for MIPS ELF builds
Closes #210
|
|
|
9bef5df7
|
2018-02-23T23:31:02
|
|
Make SIMD symbols private for iOS ARM/ARM64 builds
|
|
|
88421563
|
2018-02-23T21:56:32
|
|
Make SIMD symbols private for x86[-64] ELF builds
|
|
9cdec16c
|
2018-02-23T13:58:24
|
|
32-bit AVX2 implementation of slow int inverse DCT
|
|
|
845fe8bf
|
2018-02-23T12:24:10
|
|
32-bit AVX2 buglet: IS_ALIGNED_SSE=IS_ALIGNED_AVX
|
|
|
de9e9db6
|
2018-02-23T11:50:11
|
|
64-bit AVX2 implementation of slow int inverse DCT
|
|
|
715b7c38
|
2018-02-17T22:15:58
|
|
32-bit AVX2 implementation of int sample conv.
|
|
|
ca387e7f
|
2018-02-17T20:31:30
|
|
32-bit AVX2 implementation of slow int forward DCT
|
|
|
39e9e65c
|
2018-02-17T19:39:53
|
|
64-bit AVX2 implementation of int sample conv.
|
|
|
264dd42a
|
2018-02-17T17:32:25
|
|
64-bit AVX2 implementation of slow int forward DCT
|
|
|
ff392d81
|
2018-02-17T17:29:38
|
|
AVX2: Introduce YMMBLOCK macro for readability
|
|
|
37bae1a0
|
2018-02-14T17:22:00
|
|
Prog Huff enc: bit count/branchless abs val opts
Ported from baseline Huffman encoder. This improves overall compression
performance by ~3-9% in my testing.
|
|
|
985ef4f9
|
2018-02-14T14:50:04
|
|
Merge branch 'master' into dev
|
|
700de8aa
|
2018-02-14T15:41:36
|
|
README.md: Fix permissions
|
|
|
4e240795
|
2018-02-13T16:34:21
|
|
Merge branch 'master' into dev
|
|
|
d4859558
|
2018-02-13T16:14:03
|
|
Fix dithering bug in merged 4:2:0/RGB565 algorithm
d0 should always be used for the first row, and d1 should always be used
for the second row.
Addresses concerns raised in #95, #81.
|
|
|
289014d4
|
2018-01-05T12:05:43
|
|
Merge branch 'master' into dev
|
|
3847f911
|
2018-01-03T07:56:12
|
|
Travis/OS X: Use 'brew bundle' + Brewfile
This ensures that the build script will not fail if the Homebrew
dependencies are already installed.
|
|
|
bd544e28
|
2017-12-16T09:34:28
|
|
Merge branch 'master' into dev
|
|
|
0e2bca07
|
2017-12-15T20:37:02
|
|
jdarith.c: Fix two signed integer overflows
I guess I have to fix these, or Google Autofuzz is going to keep bugging
me about them.
Fixes #171
Fixes #197
Fixes #198
|
|
|
0fba3c19
|
2017-12-15T20:05:58
|
|
Bump version to 1.5.4 to prepare for new commits
|
|
|
7d3feda7
|
2017-12-15T16:45:25
|
|
BUILDING.md: Adjust Android recipes for NDK r16+
NDK r16b moved some things around, so modify the Android build recipes
to take that into account while preserving compatibility with previous
NDK releases.
NOTE: the GCC 4.9 NDK toolchain is deprecated, so we will need to
develop new Android build recipes for libjpeg-turbo 1.6 that use the
Clang toolchain.
Closes #196
|
|
|
bf6c7743
|
2017-12-07T19:29:42
|
|
Fix whitespace errors
|
|
|
afdd7999
|
2017-12-06T12:20:24
|
|
Merge branch 'master' into dev
+ acknowledge 1.5.3 release
|
|
|
c308d434
|
2017-12-06T11:59:04
|
|
jpeg_crop_scanlines: Handle gray images w/ samp!=1
Since the sampling factor has no meaning for single-component images,
the decompressor ignores it, and jpeg_crop_scanlines() should as well.
Fixes #195
|
|
|
773040f9
|
2017-12-05T15:27:34
|
|
Fix lib state when skipping to end of 1-scan image
If jpeg_skip_scanlines() is used to skip to the end of a single-scan
image, then we need to change the library state such that subsequent
calls to jpeg_consume_input() will return JPEG_REACHED_EOI rather than
JPEG_SUSPENDED. (NOTE: not necessary for multi-scan images, since the
scans are processed prior to any call to jpeg_skip_scanlines().)
Unless I miss my guess, using jpeg_skip_scanlines() in this manner
will prevent any markers at the end of the JPEG image from being
read, but I don't think there is any way around that without actually
reading the data, which would defeat the purpose of
jpeg_skip_scanlines().
Fixes #194
|
|
|
c05d1249
|
2017-11-29T14:36:39
|
|
Merge branch 'master' into dev
|
|
|
a831b5a9
|
2017-11-29T14:23:31
|
|
Travis: Work around xcode7.3 image bug
Refer to travis-ci/travis-ci#8552. This was supposed to be fixed on
November 15, then on November 28. Travis blew through both deadlines,
so I have no confidence that the issue will be fixed as promised in a
timely manner. Adding 'brew update' to .travis.yml slows the OS X
build, but there is no choice at the moment.
|
|
|
9f1f86bf
|
2017-11-19T09:18:36
|
|
tjLoadImage(): Fix OOB array access w/TJPF_UNKNOWN
Because the previous commit added a test for TJPF_UNKNOWN to tjunittest,
the ASAN CI build detected this issue.
|
|
|
e817c077
|
2017-11-19T08:43:07
|
|
tjLoadImage(): return TJPF_GRAY for grayscale BMPs
... if *pixelFormat=TJPF_UNKNOWN is passed to the function.
|
|
|
479fa1d8
|
2017-11-18T11:33:05
|
|
tjLoadImage(): Don't convert RGB to grayscale
Loading RGB image files into a grayscale buffer isn't a particularly
useful feature, given that libjpeg-turbo can perform this conversion
much more optimally (with SIMD acceleration on some platforms) during
the compression process. Also, the RGB2GRAY() macro was not producing
deterministic cross-platform results because of variations in the
round-off behavior of various floating point implementations, so
`tjunittest -bmp` was failing in i386 builds.
|
|
|
8c40ac8a
|
2017-11-16T18:46:01
|
|
Add TurboJPEG C example and clean up Java example
Also rename example.c --> example.txt and add a disclaimer to that file
so people will stop trying to compile it.
|
|
|
dc4b9002
|
2017-11-16T20:43:12
|
|
TurboJPEG: Add alpha offset array/method
Also, set the red/green/blue offsets for TJPF_GRAY to -1 rather than 0.
It was undefined behavior for an application to use those arrays/methods
with TJPF_GRAY anyhow, and this makes it easier for applications to
programmatically detect whether a given pixel format has red, green, and
blue components.
|
|
|
aa745905
|
2017-11-16T18:09:07
|
|
TurboJPEG C API: Add BMP/PPM load/save functions
The main justification for this is to provide new libjpeg-turbo users
with a quick & easy way of developing a complete JPEG
compression/decompression program without requiring them to build
libjpeg-turbo from source (which was necessary in order to use the
project-private bmp API) or to use external libraries. These new
functions build upon significant enhancements to rdbmp.c, wrbmp.c,
rdppm.c, and wrppm.c which allow those engines to convert directly
between the native pixel format of the file and a pixel format
("colorspace" in libjpeg parlance) specified by the calling program.
rdbmp.c and wrbmp.c have also been modified such that the calling
program can choose to read or write image rows in the native (bottom-up)
order of the file format, thus eliminating the need to use an inversion
array. tjLoadImage() and tjSaveImage() leverage these new underlying
features in order to significantly improve upon the performance of the
old bmp API.
Because these new functions cannot work without the libjpeg-turbo
colorspace extensions, the libjpeg-compatible code in turbojpeg.c has
been removed. That code was only there to serve as an example of how
to use the TurboJPEG API on top of libjpeg, but more specific, buildable
examples now exist in the https://github.com/libjpeg-turbo/ijg
repository.
|
|
|
087ec126
|
2017-11-15T20:50:53
|
|
tjbenchtest: Test new TurboJPEG progressive flag
|
|
|
cd8a1258
|
2017-11-15T09:19:27
|
|
Build: Fix 'tjtest' target on Windows
tjbenchtest and its Java derivatives are useful for rooting out hidden
problems with the more esoteric TJBench and TurboJPEG features. For
instance, on Windows, running tjbenchtest uncovered
5fce2e942136cb70e5a30ff15a2d58b07947aa84.
This commit also causes tjbenchtest and tjbenchtest.java to append -yuv
and -alloc to their log file names, depending on the arguments passed,
and it causes the build system to clean up those log files when the
'testclean' target is built.
|
|
|
4893e5d8
|
2017-11-17T19:00:53
|
|
Merge branch 'master' into dev
|
|
|
19b393b6
|
2017-11-17T18:45:08
|
|
TJExample: Fix array index OOB w/ 4:1:1 JPEG input
|
|
|
9d9d8fe6
|
2017-11-17T18:15:42
|
|
Code formatting tweaks
|
|
|
78e97e38
|
2017-11-15T19:39:45
|
|
Uniquify tjbenchtest log file names based on args
+ clean up log files when 'make testclean' is invoked
+ fix 'tjbenchtest -yuv -alloc'
+ fix tjexampletest so that it creates images under /tmp
+ clean up tjexampletest
|
|
|
468f2fed
|
2017-11-15T19:33:06
|
|
TJExample.java: Don't ignore mistyped args
|
|
|
5abf2536
|
2017-11-14T16:12:13
|
|
Doc tweak: TJFLAG_ACCURATEDCT is the first flag
|
|
|
5fce2e94
|
2017-11-14T15:30:06
|
|
tjbench.exe: Fix decompression access violation
The program crashed when a JPEG image was passed on the command line,
because we were mixing our metaphors vis-a-vis malloc()/free() and
tjAlloc()/tjFree() (malloc()/free() uses the tjbench.exe heap,
whereas tjAlloc()/tjFree() uses the turbojpeg.dll heap.)
|
|
|
907dd683
|
2017-11-13T21:46:07
|
|
ChangeLog.md: buglet
|
|
|
f008876c
|
2017-11-13T21:24:05
|
|
Build: Fix `make dist`
Broken by previous commit
|
|
|
5bc43c78
|
2017-11-13T21:01:53
|
|
Further partial image decompression fixes
- Referring to 073b0e88a192adebbb479ee2456beb089d8b5de7 and #185, the
reason why BMP and RLE didn't (and won't) work with partial image
decompression is that the output engines for both formats maintain a
whole-image buffer, which is used to reverse the order of scanlines.
However, it was straightforward to add -crop support for GIF and
Targa, which is useful for testing partial image decompression along
with color quantization.
- Such testing reproduced a bug reported by Mozilla (refer to PR #182)
whereby jpeg_skip_scanlines() would segfault if color quantization was
enabled. To fix this issue, read_and_discard_scanlines() now sets up
a dummy quantize function in the same manner that it sets up a dummy
color conversion function.
Closes #182
|
|
|
f3ad13e3
|
2017-11-13T16:00:35
|
|
TJBench/TJUnitTest: Don't ignore mistyped args
|
|
|
94e152b1
|
2017-11-13T08:15:50
|
|
TurboJPEG C: Code formatting tweaks
|
|
|
073b0e88
|
2017-11-08T21:01:57
|
|
djpeg -crop: Exit gracefully with non-PPM formats
... and document that only PPM/PGM output images are supported with the
-crop option for the moment.
I investigated the possibility of supporting -crop with -bmp, but even
after resetting the buffer dimensions, I still kept getting virtual
array access errors. It seems that doing this the "right way" would
require creating a re-initialization function for each image format's
destination manager. I'm disinclined to do that right now, given that
this feature was Google's baby (developed as a prerequisite for
including libjpeg-turbo in Android), and the -crop option in djpeg is
intended only as an example of how to use the partial image
decompression API. Real-world applications would need to handle this
in their own destination managers.
It would probably be possible to make this work with Targa by employing
a similar hack to the one we used with PPM, but Targa isn't popular
enough to bother.
Fixes #185
|
|
|
616b4e2d
|
2017-09-20T19:55:54
|
|
TurboJPEG C: Compiler warnings
Introduced in b9ab64d8dbee2db829e59357d335c151680f44f0.
|
|
|
3d72522a
|
2017-09-20T18:11:03
|
|
SRPM build: Define _libdir based on build arch
Setting _libdir to CMAKE_INSTALL_FULL_LIBDIR only works when doing an
in-tree RPM build. SRPMs are architecture-agnostic, so the spec needs
to compute_libdir at the time the SRPM is rebuilt, not at the time it
is generated.
This is a regression introduced when implementing the new CMake-based
cross-platform build system.
|
|
|
f0dd80f2
|
2017-09-20T17:13:46
|
|
Merge branch 'master' into dev
|
|
|
1b385f37
|
2017-09-20T16:52:48
|
|
Prevent "unmappable character" error in Java build
This was causing the build to fail when rebuilding libjpeg-turbo from
a source RPM.
|
|
|
fd778bba
|
2017-09-19T20:01:34
|
|
Fix PowerPC 32-bit RPM build
|
|
|
8d403aeb
|
2017-09-19T13:03:49
|
|
Fix 32-bit RPM build w/ newer RHEL/Fedora releases
The version of RPM on RHEL 5 and older platforms defines _libdir
as %{_exec_prefix}/%{_lib}, so defining _lib in the spec file redefined
_libdir. However, newer versions of RPM (probably >= 4.6, since that
was the version that introduced the ISA macros) define _libdir as either
%{_prefix}/lib or %{_prefix}/lib64. Thus, we need to explicitly
override _libdir in our spec file.
|
|
|
01b74c10
|
2017-09-11T10:06:22
|
|
Packaging: Use parallel make when rebuilding SRPM
|
|
|
db0dec3c
|
2017-09-11T09:48:33
|
|
Travis: Limit parallel make jobs to # of CPU cores
This tends to be faster than 'make -j', since it is making more wise
use of the available resources.
|
|
ba6e9d8a
|
2017-09-05T18:23:04
|
|
wrjpgcom: Fix comment typo
Comment was copied/pasted from skip_variable() without making the
necessary modifications.
|
|
|
7106ffe5
|
2017-09-02T04:20:03
|
|
Merge branch 'master' into dev
|
|
|
5426a4cb
|
2017-09-02T04:08:06
|
|
TJUnitTest: Usage formatting tweaks
|
|
|
d0bac69a
|
2017-09-02T03:40:46
|
|
Java: Fix TJUnitTest on big endian platforms
It is necessary for the C code to be aware of the machine's endianness,
which is why the TurboJPEG Java wrapper sets a different pixel format
for integer BufferedImages depending on ByteOrder.nativeOrder().
However, it isn't necessary to handle endianness in pure Java code such
as TJUnitTest (d'oh!) This was a product of porting the C version of
TJUnitTest too literally, and of insufficient testing (historically,
the big endian systems I had available for testing didn't have Java.)
|
|
|
59322e09
|
2017-09-01T21:57:48
|
|
Build: Change ppc64le DEB arch to ppc64el
This is the convention among Debian-based distros.
|
|
|
51cc89fa
|
2017-09-01T09:02:55
|
|
Merge branch 'master' into dev
|
|
|
4ded4dfa
|
2017-09-01T09:01:00
|
|
Build: Fix AltiVec detection on OS X Leopard
The ability to directly access elements of an AltiVec vector is
apparently a more recent thing.
|
|
|
1d935416
|
2017-09-01T13:52:21
|
|
Build: Use -maltivec when testing AltiVec support
Doesn't seem to be necessary with recent Linux/GCC configurations, but
it is definitely necessary with OS X.
|
|
|
c0f3512d
|
2017-08-31T20:57:19
|
|
Merge branch 'master' into dev
|
|
|
02fa8f24
|
2017-09-01T01:10:08
|
|
Fix build on PowerPC SPE systems
SPE systems don't support AltiVec instructions.
Fixes #172
|
|
|
32120054
|
2017-08-14T10:54:27
|
|
Java: Fix NullPointerException in YUVImage
planes == null is a valid argument to setBuf() if alloc == true, so we
need to make sure that planes is non-null before validating its length.
We also need to allocate one dimension of the planes array if it's null.
Fixes #168
|
|
|
14783612
|
2017-08-14T11:18:35
|
|
Bump version to 1.5.3 to prepare for new commits
|
|
|
e5c1613c
|
2017-07-07T15:15:19
|
|
x86: Fix "short jump is out of range" w/ NASM<2.04
|
|
|
c9453121
|
2017-06-29T16:49:09
|
|
TJBench: Recover from non-fatal errors if possible
Previously, -stoponwarning only had an effect on the underlying
TurboJPEG C functions, but TJBench still aborted if a non-fatal error
occurred. This commit modifies the C version of TJBench such that it
always recovers from a non-fatal error unless -stoponwarning is
specified. Furthermore, the benchmark stores the details of the last
non-fatal error and does not print any subsequent non-fatal error
messages unless they differ from the last one.
Due to limitations in the Java API (specifically, the fact that it
cannot communicate errors, fatal or otherwise, to the calling program
without throwing a TJException), it was only possible to make
decompression operations fully recoverable within TJBench. With other
operations, -stoponwarning still has an effect on the underlying C
library but has no effect at the Java level.
The Java API documentation has been amended to reflect that only certain
methods are truly recoverable, regardless of the state of
TJ.FLAG_STOPONWARNING.
|
|
|
9baef107
|
2017-06-29T12:08:02
|
|
TurboJPEG: Don't make STOPONWARNING persistent
Due to an oversight in d4092f6b4dd94c64864662987b070d517c399490,
the state of TJFLAG_STOPONWARNING persisted beyond the function it
was passed to.
|
|
|
dadebcd7
|
2017-06-28T11:43:08
|
|
TurboJPEG: Add "copy none", progressive xform opts
Allow progressive entropy coding to be enabled on a
transform-by-transform basis, and implement a new transform option for
disabling the copying of markers.
Closes #153
|
|
|
dedce66e
|
2017-06-28T15:30:41
|
|
Merge branch 'master' into dev
|
|
|
b0971e47
|
2017-06-28T14:47:45
|
|
TurboJPEG: Document xform issue w/ big marker data
If the source image for a transform operation has a lot of EXIF or ICC
data embedded in it, then it may cause the output image size to exceed
the worst-case size returned by tjBufSize() (because tjTransform()
transfers all markers to the output image.) This is only a problem if
TJFLAG_NOREALLOC is passed to the function. Since the TurboJPEG C API
doesn't require the destination image size to be set in this case, it
makes the documented assumption that the calling program has allocated
the destination buffer to exactly the size returned by tjBufSize().
Changing this assumption would change the API behavior and necessitate
a new function name (tjTransform2().) At the moment, it's easier to
just document this as a known issue, since it's easy to work around in
the C API.
The Java API is unfortunately a different story, since it must always
use TJFLAG_NOREALLOC (because, when using the TurboJPEG Java API, all
buffers are allocated on the Java heap, and thus they can't be
reallocated by the C code.) There is no easy way to work around this
without changing the C API as discussed above, because if the source
image contains large amounts of marker data, it's virtually impossible
to determine how big the output image will be.
|
|
|
e248d430
|
2017-06-28T14:40:35
|
|
Java TJBench: Fix parsing of -warmup argument
Due to an oversight, this wasn't included in
1db1ce45da2e78d87ff05119b674c71d630926aa.
|
|
|
acb63493
|
2017-06-27T19:45:35
|
|
Build: Disable warmup in TJBench regression tests
Fixes slow-down in 'make test' caused by previous commit.
|
|
|
1db1ce45
|
2017-06-27T14:22:39
|
|
TJBench: Improve consistency of results
Given that libjpeg-turbo can often process hundreds of megapixels/second
on modern hardware, the default of one warmup iteration was essentially
meaningless. Furthermore, the -warmup option was a bit clunky, since
it required some foreknowledge of how fast the benchmarks were going to
execute.
This commit introduces a 1-second warmup interval for each benchmark by
default, and the -warmup option has been retasked to control the length
of that interval.
|
|
|
aba6ae59
|
2017-06-27T13:24:08
|
|
TurboJPEG: Opt. enable progressive entropy coding
Fulfills part of the feature request in #153. Also paves the way for
SIMD-accelerated progressive Huffman coding (refer to #46.)
|
|
|
596e3965
|
2017-06-27T11:51:34
|
|
Merge branch 'master' into dev
|
|
|
d0c3aa90
|
2017-06-27T11:36:25
|
|
TurboJPEG: C API documentation buglet
TJFLAG_NOREALLOC, tjAlloc(), and tjFree() apply to all TurboJPEG
compression functions, not just tjCompress2().
|
|
|
d4092f6b
|
2017-06-27T10:54:21
|
|
TurboJPEG: Improve error handling
- Provide a new C API function and TJException method that allows
calling programs to query the severity of a compression/decompression/
transform error.
- Provide a new flag that instructs the library to immediately stop
compressing/decompressing/transforming if a warning is encountered.
Fixes #151
|
|
|
42e1e2d8
|
2017-06-26T19:19:44
|
|
Build: Custom target for generating JNI headers
|
|
|
25c912c1
|
2017-05-11T21:29:07
|
|
Build: Add custom target for generating Java docs
|
|
|
178796e7
|
2017-05-11T21:23:45
|
|
Build: Fix buglet in java/CMakeLists.txt (MSYS)
CMAKE_HOST_SYSTEM_NAME should be restored with the value of
CMAKE_HOST_SYSTEM_NAME_BAK.
|
|
|
b9ab64d8
|
2017-05-11T21:02:29
|
|
TurboJPEG: Thread-safe error message retrieval
Introduce a new C API function (tjGetErrorStr2()) that can be used to
retrieve compression/decompression/transform error messages in a
thread-safe (i.e. instance-specific) manner. Retrieving error messages
from global functions is still thread-unsafe.
Addresses a concern expressed in #151.
|
|
|
2ac4e9d9
|
2017-06-26T21:58:32
|
|
Merge branch 'master' into dev
|
|
|
6a2b0674
|
2017-05-11T18:33:47
|
|
TJBench: Code formatting tweaks
Spaces-->tab + remove stray control character that was introduced in
95e4cb206085c3a715f0f017c174fdf367a2c1ff
|
|
|
11eec4a3
|
2017-06-26T20:48:02
|
|
TJBench: Fix errors when decomp. files w/ ICC data
Embedded ICC profiles can cause the size of a JPEG file to exceed the
size returned by tjBufSize() (which is really meant to be used for
compression anyhow, not for decompression), and this was causing a
segfault (C) or an ArrayIndexOutOfBoundsException (Java) when
decompressing such files with TJBench. This commit modifies the
benchmark such that, when tiled decompression is disabled, it re-uses
the source buffer as the primary JPEG buffer.
|
|
|
301ba4f3
|
2017-06-26T15:15:08
|
|
BUILDING.md: Include Android/x86 build recipes
Addresses a concern raised in #155.
|
|
|
70f236dd
|
2017-05-08T08:15:11
|
|
Travis: Fix OS X build
The Travis xcode7.3 image now apparently includes GnuPG 1.4.x by
default, so use it instead of installing GnuPG 2. Using GnuPG 2.1.x,
the default version in Homebrew as of this writing, is problematic for
this reason:
https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase
|
|
|
2a4f1894
|
2017-05-05T20:45:40
|
|
Restore compatibility with older autoconf releases
(broken by f06cc1200fd5f61b63479d7099ccf4a7457a89bd)
Fixes #149
|
|
|
9d64f3c6
|
2017-04-24T14:42:58
|
|
Attribute ARM runtime detection code to Nokia
This code was submitted in the initial ARM NEON patches
(https://sourceforge.net/p/libjpeg-turbo/patches/7/) by Siarhei while he
was still a Nokia employee.
|
|
|
da2a27ef
|
2017-03-18T16:15:14
|
|
Honor max_memory_to_use/JPEGMEM/-maxmemory
This re-introduces a feature of the obsolete system-specific libjpeg
memory managers-- namely the ability to limit the amount of main memory
used by the library during decompression or multi-pass compression.
This is mainly beneficial for two reasons:
- Works around a 2 GB limit in libFuzzer
- Allows security-sensitive applications to set a memory limit for the
JPEG decoder so as to work around the progressive JPEG exploit
(LJT-01-004) described here:
http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf
This commit also removes obsolete documentation regarding the MS-DOS
memory manager (which itself was removed long ago) and changes the
documentation of the -maxmemory switch and JPEGMEM environment variable
to reflect the fact that backing stores are never used in libjpeg-turbo.
Inspired by:
https://github.com/caolanm/libjpeg-turbo/commit/066fee2e7d6834f24838bc1896aa38ca77209e3c
Closes #143
|
|
|
c082dc03
|
2017-03-18T13:24:50
|
|
AppVeyor: Fix CI build
Something changed in the CI build environment, and our previous trick of
setting the Git URL to file://c:/projects/libjpeg-turbo no longer works.
Using cygpath to translate the Windows path to a MinGW-friendly format
is a better solution anyhow.
|
|
|
d4c41fe0
|
2017-03-18T12:56:36
|
|
TurboJPEG: Fix potential memory leaks
Referring to https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=746,
it seems that the values of local buffer pointers in TurboJPEG API
functions aren't always preserved if longjmp() returns control to a
point prior to the allocation of the local buffers. This is known to
be an issue with GCC 4.x and clang with -O1 and higher optimization
levels but not with GCC 5.x and later. It is unknown why GCC 5.x and
6.x do not suffer from the issue, but possibly the local buffer pointers
are not allocated on the stack when using those more recent compilers.
In any case, this commit modifies the TurboJPEG API library code such
that the jump buffer is always updated after any local buffer pointers
are allocated but before any subsequent libjpeg API functions are
called.
|
|
|
44b2399a
|
2017-01-19T15:18:57
|
|
libjpeg API: Support reading/writing ICC profiles
This commit does the following:
-- Merges the two glueware functions (read_icc_profile() and
write_icc_profile()) from iccjpeg.c, which is contained in downstream
projects such as LCMS, Ghostscript, Mozilla, etc. These functions were
originally intended for inclusion in libjpeg, but Tom Lane left the IJG
before that could be accomplished. Since then, programs and libraries
that needed to embed/extract ICC profiles in JPEG files had to include
their own local copy of iccjpeg.c, which is suboptimal.
-- The new functions were prefixed with jpeg_ and split into separate
files for the compressor and decompressor, per the existing libjpeg
coding standards.
-- jpeg_write_icc_profile() was made slightly more fault-tolerant.
It will now trigger a libjpeg error if it is called before
jpeg_start_compress() or if it is passed NULL arguments.
-- jpeg_read_icc_profile() was made slightly more fault-tolerant.
It will now trigger a libjpeg error if it is called before
jpeg_read_header() or if it is passed NULL arguments. It will also
now trigger libjpeg warnings if the ICC profile data is corrupt.
-- The code comments have been wordsmithed.
-- Note that the one-line setup_read_icc_profile() function was not
included. Instead, libjpeg.txt now documents the need to call
jpeg_save_markers(cinfo, JPEG_APP0 + 2, 0xFFFF) prior to calling
jpeg_read_header(), if jpeg_read_icc_profile() is to be used.
-- Adds documentation for the new functions to libjpeg.txt.
-- Adds an -icc switch to cjpeg and jpegtran that allows those programs
to embed an ICC profile in the JPEG files they generate.
-- Adds an -icc switch to djpeg that allows that program to extract an
ICC profile from a JPEG file while decompressing.
-- Adds appropriate unit tests for all of the above.
-- Bumps the SO_AGE of the libjpeg API library to indicate the presence
of new API functions.
Note that the licensing information was obtained from:
https://github.com/mm2/Little-CMS/issues/37#issuecomment-66450180
|