|
fe11699d
|
2016-02-03T14:02:13
|
|
Adjust performance claims
Document the latest benchmarks on the Nexus 5X and change the "2-4x"
overall claim to "2-6x". The peak performance on x86 platforms was
already closer to 5x, and the addition of SIMD-accelerated Huffman
encoding gave it that extra push over the cliff.
|
|
|
8af3f8a9
|
2016-01-18T16:40:07
|
|
Provide pkg-config (.pc) scripts
This allows a project to use PKG_CHECK_MODULES() in its configure.ac
file to easily check for the presence of libjpeg-turbo and modify the
compiler/linker flags accordingly. Note that if a project relies solely
on pkg-config to check for libjpeg-turbo, then it will not be possible
to build that project using libjpeg or an earlier version of
libjpeg-turbo.
Closes #53
Based on:
https://github.com/cberner/libjpeg-turbo/commit/496713871939b550d00005b4042420da41641a0a
|
|
|
d38b4f21
|
2016-01-16T01:53:32
|
|
Optimize ARM64 SIMD code for Cavium ThunderX
Per @ssvb:
ThunderX is an ARM64 chip that dedicates most of its transistor real
estate to providing 48 cores, so each core is not as fast as a result.
Each core is dual-issue & in-order for scalar instructions and has only
a single-issue half-width NEON unit, so the peak throughput is one
128-bit instruction per 2 cycles. So careful instruction scheduling is
important. Furthermore, ThunderX has an extremely slow implementation
of ld2 and ld3, so this commit implements the equivalent of those
instructions using ld1.
Compression speedup relative to libjpeg-turbo 1.4.2:
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 58-85% (avg. 74%)
relative to jpeg-6b: 1.75-2.14x (avg. 1.95x)
Refer to #49 and #51 for discussion.
Closes #51.
This commit also wordsmiths the ChangeLog entry (the ARMv8 SIMD
implementation is "complete" only for compression-- it still lacks some
decompression algorithms, as does the ARMv7 implementation.)
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/9405b5fd031558113bdfeae193a2b14baa589a75
which is based on:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/f561944ff70adef65bb36212913bd28e6a2926d6
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/962c8ab21feb3d7fc2a7a1ec8d26f6b985bbb86f
|
|
|
e8aa5fa9
|
2016-01-15T13:15:54
|
|
Add JSIMD_NOHUFFENC environment variable for ARM
Useful in regression/performance testing
|
|
|
ec6941f7
|
2016-01-15T09:29:11
|
|
Complete the ARM64 NEON SIMD implementation
This adds 64-bit NEON coverage for all of the algorithms that are
covered by the 32-bit NEON implementation, except for h2v1 (4:2:2) fancy
upsampling (used when decompressing 4:2:2 JPEG images.) It also adds
64-bit NEON SIMD coverage for:
* slow integer forward DCT (compressor)
* h2v2 (4:2:0) downsampling (compressor)
* h2v1 (4:2:2) downsampling (compressor)
which are not covered in the 32-bit implementation.
Compression speedups relative to libjpeg-turbo 1.4.2:
Apple A7 (iPhone 5S), iOS, 64-bit: 113-150% (reported)
48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 2.1-33% (avg. 15%)
Refer to #44 and #49 for discussion
This commit also removes the unnecessary
if (simd_support & JSIMD_ARM_NEON)
statements from the jsimd* algorithm functions. Since the jsimd_can*()
functions check for the existence of NEON, the corresponding algorithm
functions will never be called if NEON isn't available.
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/dcd9d84f10fae192c0e3935818dc289bca9c3e29
https://github.com/mayeut/libjpeg-turbo/commit/b0d87b811f37bd560083deea8c6e7d704e5cd944
https://github.com/mayeut/libjpeg-turbo/commit/70cd5c8a493a67f4d54dd2067ae6dedb65d95389
https://github.com/mayeut/libjpeg-turbo/commit/3e58d9a064648503c57ec2650ee79880f749a52b
https://github.com/mayeut/libjpeg-turbo/commit/837b19542f53fa81af83e6ba002d559877aaf597
https://github.com/mayeut/libjpeg-turbo/commit/73dc43ccc870c2e10ba893e9764b8e48d6836585
https://github.com/mayeut/libjpeg-turbo/commit/a82b71a261b4c0213f558baf4bc745f1c27356d8
https://github.com/mayeut/libjpeg-turbo/commit/c1b1188c2106d6ea7b76644b6023b57edeb602e1
https://github.com/mayeut/libjpeg-turbo/commit/305c89284e1bb222b34fbc7261f697a0cc452a41
https://github.com/mayeut/libjpeg-turbo/commit/7f443f99950b4d7d442b9b879648eca5273209bd
https://github.com/mayeut/libjpeg-turbo/commit/4c2b53b77da5a20e30e2aadaeddb0efbfe24e06d
Unified version with fixes:
https://github.com/mayeut/libjpeg-turbo/commit/1004a3cd05870612a194b410efeaa1b4da76d246
|
|
|
499c470b
|
2016-01-13T03:13:20
|
|
ARM32 NEON SIMD implementation of Huffman encoding
Full-color compression speedups relative to libjpeg-turbo 1.4.2:
800 MHz ARM Cortex-A9, iOS, 32-bit: 26-44% (avg. 32%)
Refer to #42 and #47 for discussion.
This commit also removes the unnecessary
if (simd_support & JSIMD_ARM_NEON)
statements from the jsimd* algorithm functions. Since the jsimd_can*()
functions check for the existence of NEON, the corresponding algorithm
functions will never be called if NEON isn't available. Removing those
if statements improved performance across the board by a couple of
percent.
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/fc023c880ce1d6c908fb78ccc25f5d5fd910ccc5
|
|
|
f3a8684c
|
2016-01-07T00:19:43
|
|
SSE2 SIMD implementation of Huffman encoding
Full-color compression speedups relative to libjpeg-turbo 1.4.2:
2.8 GHz Intel Xeon W3530, Linux, 64-bit: 2.2-18% (avg. 9.5%)
2.8 GHz Intel Xeon W3530, Linux, 32-bit: 10-25% (avg. 17%)
2.3 GHz AMD A10-4600M APU, Linux, 64-bit: 4.9-17% (avg. 11%)
2.3 GHz AMD A10-4600M APU, Linux, 32-bit: 8.8-19% (avg. 15%)
3.0 GHz Intel Core i7, OS X, 64-bit: 3.5-16% (avg. 10%)
3.0 GHz Intel Core i7, OS X, 32-bit: 4.8-14% (avg. 11%)
2.6 GHz AMD Athlon 64 X2 5050e:
Performance-neutral (give or take a few percent)
Full-color compression speedups relative to IPP:
2.8 GHz Intel Xeon W3530, Linux, 64-bit: 4.8-34% (avg. 19%)
2.8 GHz Intel Xeon W3530, Linux, 32-bit: -19%-7.0% (avg. -7.0%)
Refer to #42 for discussion. Numerous other approaches were attempted,
but this one proved to be the most performant across all platforms.
This commit also fixes #3 (works around, really-- the clang-compiled version
of jchuff.c still performs 20% worse than its GCC-compiled counterpart, but
that code is now bypassed by the new SSE2 Huffman algorithm.)
Based on:
https://github.com/mayeut/libjpeg-turbo/commit/2cb4d41330e1edc4469f6b97ba73b73abfbeb02f
https://github.com/mayeut/libjpeg-turbo/commit/36c94e050d117912adbff9fbcc6fe307df240168
|
|
|
eb59b6e7
|
2016-01-11T22:27:38
|
|
Add -nowrite arg to TJBench to improve consistency
Prevents any images from being written to disk, thus making the
performance of the benchmark as CPU-bound as possible.
|
|
|
368cd52d
|
2016-01-11T22:03:16
|
|
Allow JSIMD_FORCENONE=1 env to disable x86-64 SIMD
Traditionally, the x86-64 code did not call init_simd() because it had
no need to (only SSE2 was supported.) However, having the ability to
disable SIMD at run time is a useful testing tool, and all of the other
SIMD implementations have this ability.
|
|
|
2111c5ac
|
2016-01-06T19:24:55
|
|
Merge branch '1.4.x'
|
|
|
5a3b4fed
|
2016-01-06T19:17:54
|
|
Regression: Allow co-install of 32-bit/64-bit RPMs
Fix a regression introduced in 1.4.1 that prevented 32-bit and 64-bit
libjpeg-turbo RPMs from being installed simultaneously on recent Red
Hat/Fedora distributions. This was due to the addition of the
SIZEOF_SIZE_T macro in jconfig.h, which allows the Huffman codec to
determine the word size at compile time. Since that macro differs
between 32-bit and 64-bit builds, this caused a conflict between the
i386 and x86_64 RPMs (any differing files, other than executables, are
not allowed when 32-bit and 64-bit RPMs are installed simultaneously.)
Since the macro is used only internally, it has been moved into
jconfigint.h.
|
|
|
d70a5c12
|
2015-12-14T16:59:43
|
|
Remove unnecessary .arch directive in ARM64 code
This directive was preventing the code from assembling using the
integrated assembler in clang.
Fixes #33
|
|
|
d65e768b
|
2015-10-14T22:26:25
|
|
Fix additional issues reported by UB sanitizers
Most of these involved overrunning the signed 32-bit JLONG type whenever
building libjpeg-turbo with a 32-bit compiler. These issues are not
believed to represent actual security threats, but eliminating them
makes it easier to detect such threats should they arise in the future.
|
|
|
250c8877
|
2015-10-13T13:37:32
|
|
ChangeLog: acknowledge existence of 1.4.2
|
|
|
7e3acc0e
|
2015-10-10T10:25:46
|
|
Rename README, LICENSE, BUILDING text files
The IJG README file has been renamed to README.ijg, in order to avoid
confusion (many people were assuming that that was our project's README
file and weren't reading README-turbo.txt) and to lay the groundwork for
markdown versions of the libjpeg-turbo README and build instructions.
|
|
|
60efb896
|
2015-09-21T13:13:44
|
|
Merge branch '1.4.x'
|
|
|
8e9cef2e
|
2015-09-21T12:57:41
|
|
Fix various issues reported by the UB sanitizers
Most of these involved left shifting a negative number, which is
technically undefined (although every modern compiler I'm aware of
will implement this by treating the signed integer as a 2's complement
unsigned integer-- the LEFT_SHIFT() macro just makes this behavior
explicit in order to shut up ubsan.) This also fixes a couple of
non-issues in the entropy codecs, whereby the sanitizer reported an
out-of-bounds index in the 4th argument of jpeg_make_d_derived_tbl().
In those cases, the index was actually out of bounds (caused by a
malformed JPEG image), but jpeg_make_d_derived_tbl() would have caught
the error and aborted prior to actually using the invalid address. Here
again, the fix was to make our intentions explicit so as to shut up
ubsan.
|
|
|
870b4f28
|
2015-09-16T23:26:13
|
|
Fix ChangeLog numbering biffed by previous merge
|
|
|
b961f0bf
|
2015-09-16T23:16:38
|
|
Merge branch '1.4.x'
|
|
54792ba3
|
2015-09-16T23:05:46
|
|
Fix MIPS DSPr2 4:2:0 upsample bug w/ small images
The DSPr2 code was errantly comparing the residual (t9, width & 0xF)
with the end pointer (t4, out + width) instead of the width directly
(a1). This would give the wrong results with any image whose output
width was less than 16. The other small changes (ulw to lw and removal
of the nop) are just some easy optimizations around this code.
This issue caused a buffer overrun and subsequent segfault on images
whose scaled output height was 1 pixel and whose scaled output width was
< 16 pixels. Note that the "plain" (non-fancy and non-merged) upsample
routine, which was affected by this bug, is normally not used except
when decompressing a non-YCbCr JPEG image, but it is also used when
decompressing a single-row image (because the other upsampling
algorithms require at least two rows.)
Closes #16.
|
|
498d9bc9
|
2015-09-15T11:57:03
|
|
Fix x86-64 ABI conformance issue in SIMD code
(descriptions cribbed by DRC from discussion in #20)
In the x86-64 ABI, the high (unused) DWORD of a 32-bit argument's
register is undefined, so it was incorrect to use a 64-bit mov
instruction to transfer a JDIMENSION argument in the 64-bit SSE2 SIMD
functions. The code worked thus far only because the existing compiler
optimizers weren't smart enough to do anything else with the register in
question, so the upper 32 bits happened to be all zeroes-- for the past
6 years, on every x86-64 compiler previously known to mankind.
The bleeding-edge Clang/LLVM compiler has a smarter optimizer, and
under certain circumstances, it will attempt to load-combine adjacent
32-bit integers from one of the libjpeg structures into a single 64-bit
integer and pass that 64-bit integer as a 32-bit argument to one of the
SIMD functions (which is allowed by the ABI, since the upper 32 bits of
the 32-bit argument's register are undefined.) This caused the
libjpeg-turbo regression tests to crash.
Also enhance the documentation of JDIMENSION to explain that its size
is significant to the implementation of the SIMD code.
Closes #20. Refer also to http://crbug.com/532214.
|
|
|
00d82c42
|
2015-08-29T18:15:25
|
|
Merge branch '1.4.x'
|
|
|
b5a55e6d
|
2015-08-29T18:05:43
|
|
Fix negative shift with IFAST FDCT and qual=100
With certain images, compressing using quality=100 and the fast integer
forward DCT will cause the divisor passed to compute_reciprocal() to be
1. In those cases, the library already disables the SIMD quantization
algorithm to avoid 16-bit overflow. However, compute_reciprocal()
doesn't properly handle the divisor==1 case, so we need to use special
values in that case so that the C quantization algorithm will behave
like an identity function.
|
|
|
f62dbccf
|
2015-08-15T13:30:14
|
|
Fix build error when compiling MIPS SIMD w/ -mfpxx
When compiled with -mfpxx (which is now the default on Debian), there are
some restrictions on the use of odd-numbered FP registers. More details
about FPXX can be found here:
https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
This commit simply changes all uses of FP registers to an even-numbered
equivalent like this:
f0 -> f0
f1 -> f2
f2 -> f4
...
f8 -> f16
This commit should have no observable effect except that the MIPS assembly
will now compile with -mfpxx.
Closes #11
|
|
|
a3ef34c6
|
2015-08-13T11:09:05
|
|
Fix cjpeg segfault when Windows BMP width/height<0
rdbmp.c used the ambiguous INT32 datatype, which is sometimes typedef'ed
to long. Windows bitmap headers use 32-bit signed integers for the
width and height, because height can sometimes be negative (this
indicates a top-down bitmap.) If biWidth or biHeight was negative and
INT32 was a 64-bit long, then biWidth and biHeight were read as a
positive integer > INT32_MAX, which failed the test in line 385:
if (biWidth <= 0 || biHeight <= 0)
ERREXIT(cinfo, JERR_BMP_EMPTY);
This commit refactors rdbmp.c so that it uses the datatypes specified by
Microsoft for the Windows BMP header.
This closes #9 and also provides a better solution for mozilla/mozjpeg#153.
|
|
|
6fa14b37
|
2015-08-13T20:06:03
|
|
Declare source buffers in TurboJPEG C API as const
This reassures the caller that the buffers will not be modified and also
allows read-only buffers to be passed to the functions.
Partially reverts 3947a19f25fc8186d3812dbcf8e70baea36ef652.
|
|
|
8fb37b81
|
2015-08-13T11:09:05
|
|
Fix cjpeg segfault when Windows BMP width/height<0
rdbmp.c used the ambiguous INT32 datatype, which is sometimes typedef'ed
to long. Windows bitmap headers use 32-bit signed integers for the
width and height, because height can sometimes be negative (this
indicates a top-down bitmap.) If biWidth or biHeight was negative and
INT32 was a 64-bit long, then biWidth and biHeight were read as a
positive integer > INT32_MAX, which failed the test in line 385:
if (biWidth <= 0 || biHeight <= 0)
ERREXIT(cinfo, JERR_BMP_EMPTY);
This commit refactors rdbmp.c so that it uses the datatypes specified by
Microsoft for the Windows BMP header.
This closes #9 and also provides a better solution for mozilla/mozjpeg#153.
|
|
|
739edeb8
|
2015-07-21T09:34:02
|
|
Further exception cleanup
Use a new checked exception type (TJException) when passing through
errors from the underlying C library. This gives the application a
choice of catching all exceptions or just those from TurboJPEG.
Throw IllegalArgumentException at the JNI level when arguments to the
JNI function are incorrect, and when one of the TurboJPEG "utility"
functions returns an error (because, per the C API specification, those
functions will only return an error if one of their arguments is out of
range.)
Remove "throws Exception" from the signature of any methods that no
longer pass through an error from the TurboJPEG C library.
Credit Viktor for the new code
Code formatting tweaks
|
|
b3817dab
|
2015-07-14T20:42:52
|
|
Throw idiomatic unchecked exceptions from the Java classes and JNI wrapper if there is an unrecoverable error caused by incorrect API usage (such as illegal arguments, etc.), and throw Errors if there is an unrecoverable error at the C level (such as a failed malloc() call.)
Change the behavior of the bailif0() macro in the JNI wrapper so that it doesn't throw an exception for an unexpected NULL condition. In fact, in all cases, the underlying JNI API function (such as GetFieldID(), etc.) will throw an Error on its own whenever it returns NULL, so our custom exceptions were never being thrown in that case anyhow. All we need to do is just detect the error and bail out of the C code.
This also corrects a couple of formatting issues (semicolons aren't needed at the end of class definitions, and @Override should be specified for the methods we're overriding from super-classes, so the compiler can sanity-check that we're actually overriding a method and not declaring a new one.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1595 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
1a4778f8
|
2015-07-07T16:39:03
|
|
Allow TJCompressor and TJDecompressor to be used with a try-with-resources statement in Java 7 and later.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1594 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
eb32cc1e
|
2015-06-25T03:44:36
|
|
Add a new libjpeg API function (jpeg_skip_scanlines()) to allow for partially decoding a JPEG image.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1582 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
89b5e06d
|
2015-06-20T16:20:53
|
|
Studies show that GCC v5.1.0 performs as well as or better than v4.2, but 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/trunk@1571 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
f15ef337
|
2015-06-08T17:41:34
|
|
Fix a segfault that occured in the MIPS DSPr2 fancy upsampling routine when 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
|
|
|
1f79c7c8
|
2015-06-01T19:22:41
|
|
If a warning (such as "Premature end of JPEG file") is triggered in the 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
|
|
|
bec45b16
|
2015-05-17T15:56:18
|
|
Back out r1555 and r1548. Using setenv() didn't fix the iOS simulator 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
|
|
|
665c96ed
|
2015-05-15T22:08:21
|
|
Allow building only static or only shared libraries on Windows
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1553 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3ebcc320
|
2015-05-15T19:09:44
|
|
__WORDSIZE doesn't seem to be available on platforms other than Mac or Linux, and best practices are for user-level code not to rely on it anyhow, since it's meant to be an internal macro. Fortunately, autoconf already has a way of determining the word size at configure time, so it can be passed into the compiler. This should work on any platform and has been tested on all of the Un*x platforms we support (Linux, Mac, FreeBSD, Solaris.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1550 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
44320a21
|
2015-05-15T18:23:59
|
|
Unless you define _ANSI_SOURCE, then putenv() on Mac is renamed to putenv$UNIX2003(), and this causes problems when trying to link an i386 iOS application (for the simulator) against the TurboJPEG static library. It's easiest to just use setenv() instead.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1548 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a8b6ea2f
|
2015-05-06T22:41:12
|
|
Fix a bug in the 64-bit Huffman encoder that Google discovered when encoding some very specific (and proprietary) aerial images using quality=98, an optimized Huffman table, and the ISLOW DCT. These images were causing the Huffman bit buffer to overflow, because the code for encoding the DC coefficient was using the equivalent of the 32-bit version of EMIT_BITS(). Thus, when 64-bit code was used, the DC coefficient code was not properly checking how many bits were in the buffer before attempting to add more bits to it. This issue appears to have existed in all versions of libjpeg-turbo.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1547 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
f64b36fd
|
2015-04-22T08:43:04
|
|
Oops. OS X doesn't define __WORDSIZE unless you include stdint.h, so apparently the Huffman codec hasn't ever been fully accelerated on 64-bit OS X.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1541 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3f760834
|
2015-01-28T00:25:43
|
|
Come on, Cohaagen, you got what you want. Give these people air!
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1527 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
8b5a0093
|
2015-01-21T17:42:28
|
|
Oops. The MIPS SIMD implementations of h2v1 and h2v2 upsampling were not checking for DSPr2 support, so running 'djpeg -nosmooth' on a non-DSPr2-enabled platform caused an "illegal instruction" error.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1523 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0e94025a
|
2015-01-20T10:33:32
|
|
Introduce fast paths to speed up NULL color conversion somewhat, particularly when using 64-bit code; on the decompression side, the "slow path" also now use an approach similar to that of the compression side (with the component loop outside of the column loop rather than inside.) This is faster when using 32-bit code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1521 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3af282df
|
2015-01-16T06:53:36
|
|
Make the floating point regression tests optional. It has been known for quite some time that these tests do not always generate the same results unless there is full SIMD coverage of the floating point algorithms in libjpeg-turbo. Further research reveals that there are basically three expected results: the results from our SSE SIMD extensions (which are slightly more accurate than the C code), results from the C code when running on a 32-bit FPU (or when using SSE instructions on an x86-64 CPU, which is the default with GCC), and results from the C code when running on a 64-bit FPU (which presumably uses double-precision arithmetic by default.) There is basically no way to determine which type of math will be used prior to run time, so it's best to just let the developers specify which result they expect on their particular system.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1515 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
dd7f03be
|
2015-01-16T06:45:54
|
|
In the process of developing the AltiVec extensions, it was discovered that the normal regression tests aren't sufficient to test the behavior of the library with very small image sizes and when compressing from/decompressing to a subregion of a larger image buffer. Thus, an additional regression test was added that takes advantage of the tiled compression/decompression feature in tjbench. This is being back-ported to the 1.4.x branch primarily to verify that there are no lingering issues in the existing SIMD extensions.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1514 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
cbc9970e
|
2015-01-16T06:29:52
|
|
Add the ability to benchmark YCCK JPEG compression/decompression. This is particularly useful since that is the only way to test the performance of the "plain" upsampling routines, which are accelerated on some platforms.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1511 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
c641cddb
|
2015-01-14T15:41:11
|
|
AltiVec SIMD implementation of H2V1 and H2V2 plain upsampling (used only when decompressing YCCK images with fast upsampling enabled.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1504 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
8f7f49a0
|
2015-01-12T08:36:37
|
|
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1494 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d51e6c2f
|
2014-12-19T18:18:46
|
|
Document that the ARMv8/iOS issues are now fixed
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1454 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
6e6b28c3
|
2014-12-19T17:34:30
|
|
Include ARMv8 binaries when generating a combined OS X/iOS package using 'make iosdmg'
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1452 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2a6b8316
|
2014-11-25T10:07:43
|
|
Some software also needs the FAR macro. Ugh. Also wordsmithing.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1432 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
e2dd3e3e
|
2014-11-25T09:48:15
|
|
Restore the JPP() and JMETHOD() macros. Even though libjpeg-turbo doesn't use them anymore, other software apparently does:
https://bugzilla.redhat.com/show_bug.cgi?id=1164815
https://bugs.kde.org/show_bug.cgi?id=340944
https://bugzilla.mozilla.org/show_bug.cgi?id=1093615
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1430 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0f4469c5
|
2014-11-22T23:56:26
|
|
Oops. Include the tjPlane*() functions in the mapfile so that they are exposed in the shared library on ELF systems.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1429 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
bb383b41
|
2014-11-22T22:24:41
|
|
Fix Huffman local buffer overrun discovered by Debian developers when attempting to transform a junk image using ImageMagick:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1427 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
402a715f
|
2014-11-22T22:09:30
|
|
Fix Huffman local buffer overrun discovered by Debian developers when attempting to transform a junk image using ImageMagick:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1426 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
9665f5e3
|
2014-11-22T04:04:38
|
|
Print the library version and exit whenever -version is passed to cjpeg, djpeg, or jpegtran.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1422 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ef263e3e
|
2014-11-21T15:35:33
|
|
Make TJCompressor.close() and TJDecompressor.close() idempotent
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1420 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0426cd34
|
2014-11-21T15:33:19
|
|
Sometimes the sampling factors in grayscale images can be > 1 (for instance, if compressing using 'cjpeg -sample 2x2 -grayscale'.) Technically, sampling factors have no meaning with grayscale JPEGs, and the libjpeg decompressor ignores them in that case. Thus, the TurboJPEG decompressor should ignore them as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1419 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ea1eea47
|
2014-11-19T00:55:28
|
|
Sometimes the sampling factors in grayscale images can be > 1 (for instance, if compressing using 'cjpeg -sample 2x2 -grayscale'.) Technically, sampling factors have no meaning with grayscale JPEGs, and the libjpeg decompressor ignores them in that case. Thus, the TurboJPEG decompressor should ignore them as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1418 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3ebcf7cf
|
2014-11-18T21:45:34
|
|
Make TJCompressor.close() and TJDecompressor.close() idempotent
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1416 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
803b5d24
|
2014-11-18T15:56:43
|
|
Uses clz and bsr instructions for bit counting on ARM64 platforms as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1414 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
55620c6e
|
2014-10-23T19:08:14
|
|
Another oops. tjBufSizeYUV2() should return -1 if width < 1.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1410 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2240974d
|
2014-10-23T18:54:42
|
|
Oops. tjPlaneSizeYUV() should return -1 if componentID > 0 and subsamp==TJSAMP_GRAY.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1408 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
72a3cc0e
|
2014-08-30T20:37:50
|
|
Fix issues with RGB565 color conversion on big endian machines. The RGB565 routines are now abstracted in a separate file, with separate little-endian and big-endian versions defined at compile time through the use of macros (this is similar to how the colorspace extension routines work.) This allows big-endian machines to take advantage of the same performance optimizations as little-endian machines, and it retains the performance on little-endian machines, since the conditional branch for endianness is at a very coarse-grained level.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1399 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
339589f3
|
2014-08-30T13:55:08
|
|
Fix build on OS X PowerPC platforms
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1397 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
eb8d096b
|
2014-08-30T13:52:09
|
|
Fix build on OS X PowerPC platforms
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1396 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
fe77fa22
|
2014-08-30T13:48:45
|
|
Oops. Forgot to alter the version header in the change log to indicate the release of 1.4 beta.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1394 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d729f4da
|
2014-08-23T15:47:51
|
|
ARM NEON SIMD support for YCC-to-RGB565 conversion, and optimizations to the existing YCC-to-RGB conversion code:
-----
https://github.com/ssvb/libjpeg-turbo/commit/aee36252be20054afce371a92406fc66ba6627b5.patch
From aee36252be20054afce371a92406fc66ba6627b5 Mon Sep 17 00:00:00 2001
From: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Date: Wed, 13 Aug 2014 03:50:22 +0300
Subject: [PATCH] ARM: Faster NEON yuv->rgb conversion for Krait and Cortex-A15
The older code was developed and tested only on ARM Cortex-A8 and ARM Cortex-A9.
Tuning it for newer ARM processors can introduce some speed-up (up to 20%).
The performance of the inner loop (conversion of 8 pixels) improves from
~27 cycles down to ~22 cycles on Qualcomm Krait 300, and from ~20 cycles
down to ~18 cycles on ARM Cortex-A15.
The performance remains exactly the same on ARM Cortex-A7 (~58 cycles),
ARM Cortex-A8 (~25 cycles) and ARM Cortex-A9 (~30 cycles) processors.
Also use larger indentation in the source code for separating two independent
instruction streams.
-----
https://github.com/ssvb/libjpeg-turbo/commit/a5efdbf22ce9c1acd4b14a353cec863c2c57557e.patch
From a5efdbf22ce9c1acd4b14a353cec863c2c57557e Mon Sep 17 00:00:00 2001
From: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Date: Wed, 13 Aug 2014 07:23:09 +0300
Subject: [PATCH] ARM: NEON optimized yuv->rgb565 conversion
The performance of the inner loop (conversion of 8 pixels):
* ARM Cortex-A7: ~55 cycles
* ARM Cortex-A8: ~28 cycles
* ARM Cortex-A9: ~32 cycles
* ARM Cortex-A15: ~20 cycles
* Qualcomm Krait: ~24 cycles
Based on the Linaro rgb565 patch from
https://sourceforge.net/p/libjpeg-turbo/patches/24/
but implements better instructions scheduling.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1385 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
fe80ec22
|
2014-08-21T15:51:47
|
|
If the output buffer in the TurboJPEG destination manager was allocated by the destination manager and is being reused from a previous compression operation, then we need to get the buffer size from the previous operation, since the calling program doesn't know the actual buffer size.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1368 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2261e1e4
|
2014-08-21T03:40:37
|
|
Actually, we need to increase the size of BUFSIZE, not just the size of _buffer. The previous patch might have cause problems if, for instance, state->free_in_buffer was 127 but 129 bytes were compressed. In that case, only 127 of the 129 bytes would have been written to the file. Also document the fix.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1367 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
eddc355d
|
2014-08-21T03:38:14
|
|
Actually, we need to increase the size of BUFSIZE, not just the size of _buffer. The previous patch might have cause problems if, for instance, state->free_in_buffer was 127 but 129 bytes were compressed. In that case, only 127 of the 129 bytes would have been written to the file. Also document the fix.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1366 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
f6d7b776
|
2014-08-20T16:02:49
|
|
Wordsmithing & clarifications
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1363 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
bc3c1685
|
2014-08-20T15:40:43
|
|
Document the existence of the new ARM64 SIMD code
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1362 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
aecea388
|
2014-08-11T18:05:41
|
|
Extend the TurboJPEG C API to support handling YUV images stored in separate image planes instead of a unified buffer
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1343 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
aee4f721
|
2014-08-09T23:06:07
|
|
12-bit JPEG support
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1337 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
a81f5427
|
2014-06-22T20:50:14
|
|
Big oops. wrjpgcom on Windows was being built using the rdjpgcom source.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1327 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3da10338
|
2014-06-22T20:48:38
|
|
Big oops. wrjpgcom on Windows was being built using the rdjpgcom source.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1326 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
73821bff
|
2014-06-22T20:46:48
|
|
Big oops. wrjpgcom on Windows was being built using the rdjpgcom source.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1325 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
23843313
|
2014-06-22T20:38:54
|
|
Prevent a buffer overrun if the comment begins with a literal quote character and the string exceeds 65k characters. Also prevent comments longer than 65k characters from being written, since this will produce an incorrect JPEG file.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1324 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
b7d6e84d
|
2014-06-22T20:36:50
|
|
Prevent a buffer overrun if the comment begins with a literal quote character and the string exceeds 65k characters. Also prevent comments longer than 65k characters from being written, since this will produce an incorrect JPEG file.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1323 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
88c7e300
|
2014-05-28T20:28:30
|
|
Our copyright string is longer than JMSG_LENGTH_MAX, and this was causing a buffer overrun if output_message() was called with msg_code set to JMSG_COPYRIGHT, or if format_message() was called with msg_code set to JMSG_COPYRIGHT and with a buffer of length JMSG_LENGTH_MAX.
We can't simply increase JMSG_LENGTH_MAX, because it is part of the libjpeg API, and it is generally assumed that a buffer of this length will be passed to format_message(). Thus, the easiest solution is simply to use a shorter copyright string for JMSG_COPYRIGHT.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1320 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d7a25595
|
2014-05-28T20:27:42
|
|
Our copyright string is longer than JMSG_LENGTH_MAX, and this was causing a buffer overrun if output_message() was called with msg_code set to JMSG_COPYRIGHT, or if format_message() was called with msg_code set to JMSG_COPYRIGHT and with a buffer of length JMSG_LENGTH_MAX.
We can't simply increase JMSG_LENGTH_MAX, because it is part of the libjpeg API, and it is generally assumed that a buffer of this length will be passed to format_message(). Thus, the easiest solution is simply to use a shorter copyright string for JMSG_COPYRIGHT.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1319 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
cf55f0b5
|
2014-05-28T20:19:54
|
|
Our copyright string is longer than JMSG_LENGTH_MAX, and this was causing a buffer overrun if output_message() was called with msg_code set to JMSG_COPYRIGHT, or if format_message() was called with msg_code set to JMSG_COPYRIGHT and with a buffer of length JMSG_LENGTH_MAX.
We can't simply increase JMSG_LENGTH_MAX, because it is part of the libjpeg API, and it is generally assumed that a buffer of this length will be passed to format_message(). Thus, the easiest solution is simply to use a shorter copyright string for JMSG_COPYRIGHT.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1318 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
5033f3e1
|
2014-05-18T18:33:44
|
|
Remove MS-DOS code and information, and adjust copyright headers to reflect the removal of features in r1307 and r1308. libjpeg-turbo has never supported MS-DOS, nor is it even possible for us to do so.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1312 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
78df2e61
|
2014-05-12T09:23:57
|
|
Add support for decompressing to RGB565 (16-bit) pixels
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1295 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
715bb41e
|
2014-05-11T10:09:07
|
|
Port the more accurate (and slightly faster) floating point IDCT implementation from jpeg-8a and later. New research revealed that the SSE/SSE2 floating point IDCT implementation was actually more accurate than the jpeg-6b implementation, not less, which is why its mathematical results have always differed from those of the jpeg-6b implementation. This patch brings the accuracy of the C code in line with that of the SSE/SSE2 code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1288 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
beb0b337
|
2014-04-20T07:36:33
|
|
Work around an issue in Visual C++ 2010 and 2013 that was causing the 256-bit bitmap test in the regression tests to fail. More specifically, when optimization is enabled in these versions of Visual C++, the optimizer seems to get confused by the following code block:
delta = cur0 * 2;
cur0 += delta; /* form error * 3 */
errorptr[0] = (FSERROR) (bpreverr0 + cur0);
cur0 += delta; /* form error * 5 */
bpreverr0 = belowerr0 + cur0;
cur0 += delta; /* form error * 7 */
Each time cur0 is incremented by delta, the compiled code doubles the value of delta (WTF?!) Thus, by the time the end of the block is reached, cur0 is equal to 15 times its former self, not 7 times its former self as it should be. At any rate, it was a lot simpler to just refactor the code so that it uses multiplication.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1255 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ac9a92eb
|
2014-04-20T07:22:21
|
|
Work around an issue in Visual C++ 2010 and 2013 that was causing the 256-bit bitmap test in the regression tests to fail. More specifically, when optimization is enabled in these versions of Visual C++, the optimizer seems to get confused by the following code block:
delta = cur0 * 2;
cur0 += delta; /* form error * 3 */
errorptr[0] = (FSERROR) (bpreverr0 + cur0);
cur0 += delta; /* form error * 5 */
bpreverr0 = belowerr0 + cur0;
cur0 += delta; /* form error * 7 */
Each time cur0 is incremented by delta, the compiled code doubles the value of delta (WTF?!) Thus, by the time the end of the block is reached, cur0 is equal to 15 times its former self, not 7 times its former self as it should be. At any rate, it was a lot simpler to just refactor the code so that it uses multiplication.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1253 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0816d086
|
2014-04-20T06:57:52
|
|
Work around an issue in Visual C++ 2010 and 2013 that was causing the 256-bit bitmap test in the regression tests to fail. More specifically, when optimization is enabled in these versions of Visual C++, the optimizer seems to get confused by the following code block:
delta = cur0 * 2;
cur0 += delta; /* form error * 3 */
errorptr[0] = (FSERROR) (bpreverr0 + cur0);
cur0 += delta; /* form error * 5 */
bpreverr0 = belowerr0 + cur0;
cur0 += delta; /* form error * 7 */
Each time cur0 is incremented by delta, the compiled code doubles the value of delta (WTF?!) Thus, by the time the end of the block is reached, cur0 is equal to 15 times its former self, not 7 times its former self as it should be. At any rate, it was a lot simpler to just refactor the code so that it uses multiplication.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1251 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
fdd625ef
|
2014-04-15T03:07:44
|
|
wordsmithing
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1233 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0cfc4c17
|
2014-03-28T18:33:25
|
|
Use clz/bsr instructions on ARM for bit counting rather than the lookup table (reduces memory footprint and can improve performance in some cases.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1220 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
b1068fa2
|
2014-03-23T17:53:07
|
|
Migrate Mac packaging system to pkgbuild, since PackageMaker is no longer supported.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1212 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
de23dd80
|
2014-03-22T20:43:03
|
|
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1203 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
c8b0226d
|
2014-03-22T20:42:01
|
|
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1202 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
fc26b657
|
2014-03-16T22:56:26
|
|
Extend the YUV decode functionality to the TurboJPEG Java API, and port the TJUnitTest modifications that treat YUV encoding/decoding as an intermediate step of the JPEG compression/decompression pipeline rather than a separate test case; Add the ability to encode YUV images from an arbitrary position in a large image buffer; Significantly refactor the handling of YUV images; numerous doc tweaks; other Java API cleanup and usability improvements
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1176 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
3bf21e05
|
2014-03-11T06:24:46
|
|
Fix the build of the Java classes when using MSVC 2010 and later. Something in the recesses of my brain is telling me that I tried this before and it failed under some circumstances, but it must have been a bug in an older CMake implementation. CMake 2.8.8 and later seem to work fine with this patch. This patch also updates the minimum required version to 2.8.8, because 2.8.8 fixed another issue that was preventing the SIMD code from building under MSVC 2010 and later.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1149 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
d45c5499
|
2014-03-11T06:21:46
|
|
Fix the build of the Java classes when using MSVC 2010 and later. Something in the recesses of my brain is telling me that I tried this before and it failed under some circumstances, but it must have been a bug in an older CMake implementation. CMake 2.8.8 and later seem to work fine with this patch. This patch also updates the minimum required version to 2.8.8, because 2.8.8 fixed another issue that was preventing the SIMD code from building under MSVC 2010 and later.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1148 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
34dca052
|
2014-02-28T09:17:14
|
|
Implement a YUV decode function in the TurboJPEG API, to be symmetric with tjEncodeYUV().
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1132 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
693f4a56
|
2014-02-11T10:16:42
|
|
Fix an issue that prevented tjEncodeYUV2() and TJCompressor.encodeYUV() from working properly if the source image was very tiny. Basically, jpeg_start_compress() was attempting to write the JPEG headers, which was overrunning the YUV buffer. This patch removes the call to jpeg_start_compress() in tjEncodeYUV2() and replaces it with calls to the individual routines that are necessary to initialize the color converter and downsampler. TJUnitTest has also been modified to test for this condition (the buffer size regression test now works in YUV mode.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1121 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2c0c807f
|
2014-02-11T09:56:12
|
|
Fix an issue that prevented tjEncodeYUV2() and TJCompressor.encodeYUV() from working properly if the source image was very tiny. Basically, jpeg_start_compress() was attempting to write the JPEG headers, which was overrunning the YUV buffer. This patch removes the call to jpeg_start_compress() in tjEncodeYUV2() and replaces it with calls to the individual routines that are necessary to initialize the color converter and downsampler. TJUnitTest has also been modified to test for this condition (the buffer size regression test now works in YUV mode.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1120 632fc199-4ca6-4c93-a231-07263d6284db
|