DRC [Sat, 15 Mar 2014 13:25:11 +0000 (13:25 +0000)]
Add @Deprecated to the deprecated Java methods, so javac will actually print deprecation warnings, as opposed to just listing the methods as deprecated in javadoc; remove the use of the deprecated methods by our own test programs.
DRC [Tue, 11 Mar 2014 08:28:47 +0000 (08:28 +0000)]
Back-port the -subsamp option from 1.4 rather than use the hackish approach of replacing 4:2:2 with 4:4:0. This has the added advantage of allowing the user to test only a specific level of subsampling.
DRC [Tue, 11 Mar 2014 06:21:46 +0000 (06:21 +0000)]
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.
DRC [Fri, 28 Feb 2014 05:27:55 +0000 (05:27 +0000)]
Remove unused code (the destination manager is not used during YUV encoding, there are no virtual arrays to realize, and jinit_c_prep_controller() is unnecessary because we are not using smoothing.)
DRC [Fri, 28 Feb 2014 05:19:43 +0000 (05:19 +0000)]
Remove unused code (the destination manager is not used during YUV encoding, there are no virtual arrays to realize, and jinit_c_prep_controller() is unnecessary because we are not using smoothing.)
DRC [Tue, 11 Feb 2014 10:16:42 +0000 (10:16 +0000)]
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.)
DRC [Tue, 11 Feb 2014 09:56:12 +0000 (09:56 +0000)]
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.)
DRC [Fri, 7 Feb 2014 19:06:03 +0000 (19:06 +0000)]
Further examination of the code reveals that this change is unnecessary. The histogram stores a count of each color in the image, so it will always contain at least one non-zero element, and thus the total can never be zero. Since the histogram is generated from the image data and not read from the header, there is no chance that header corruption would affect it.
DRC [Mon, 25 Nov 2013 21:08:47 +0000 (21:08 +0000)]
Per the conventions of the image compression and digital video communities, use "YCbCr" to describe the JPEG colorspace and "YUV" to describe an image format consisting of Y, Cb, and Cr planes (this partially reverts r959.)
DRC [Mon, 25 Nov 2013 20:30:12 +0000 (20:30 +0000)]
Per the conventions of the image compression and digital video communities, use "YCbCr" to describe the JPEG colorspace and "YUV" to describe an image format consisting of Y, Cb, and Cr planes (this partially reverts r959.)
DRC [Wed, 6 Nov 2013 07:45:39 +0000 (07:45 +0000)]
Back-port code from jpeg-8 that removes unpopulated (and unneeded) tables for AC and DC coefficients when generating progressive JPEG files with arithmetic coding. This should make such files bitwise compatible with jpeg-8, barring any other mathematical differences (such as the different subsampling algorithm used in jpeg-8.) Add regression tests for progressive+arithmetic JPEG files.
DRC [Wed, 6 Nov 2013 07:37:01 +0000 (07:37 +0000)]
Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo.
DRC [Wed, 6 Nov 2013 06:55:28 +0000 (06:55 +0000)]
Back-port code from jpeg-8 that removes unpopulated (and unneeded) tables for AC and DC coefficients when generating progressive JPEG files with arithmetic coding. This should make such files bitwise compatible with jpeg-8, barring any other mathematical differences listed in README-turbo.txt. Add regression tests for progressive+arithmetic JPEG files.
DRC [Wed, 30 Oct 2013 22:12:37 +0000 (22:12 +0000)]
Fix a really subtle issue whereby an invalid free() could occur if a program called tjInitDecompress() and then accidentally passed the handle to tjEncodeYUV2(), or if a program called tjInitCompress() and then accidentally passed the handle to tjDecompressToYUV().
DRC [Sat, 12 Oct 2013 21:52:48 +0000 (21:52 +0000)]
Fix a couple of issues with return value checking. JFREAD(), which wraps fread(), will never return -1. fread() will instead return 0 or a short object count if an error occurs, and ferror() will return 1 in that case. The second issue was that we were assigning the return value of ftell() to an unsigned long prior to checking the value, so the value would never be < 0 if an error occurred. It would instead be (unsigned long)-1.
Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo.
Due to the way in which the configure script silently falls back to a non-SIMD build if SIMD can't be enabled, we accidentally released iOS ARM v7 and v7s binaries in 1.3.0 that did not contain NEON SIMD code, because gas-preprocessor.pl wasn't in the PATH. In order to prevent this from happening again, specifying --with-simd now has the effect of forcing a SIMD build, and if this argument is specified, any issues encountered while enabling SIMD are treated as fatal.
We can't enable optimized entropy coding unless we're using Huffman coding. This fixes a bug whereby attempting to create a progressive JPEG with arithmetic coding would fail.
Fix I/O suspension. This little nugget of code was introduced in r30 as part of an early attempt to make buffered I/O work with the optimized Huffman codec. Ultimately, r32 reverted a lot of that mess and introduced much of the logic we now use, rendering this code unnecessary, but it was never reverted because it only causes problems when I/O suspension is used, and apparently no one has tried to do that with libjpeg-turbo until now.
We can't enable optimized entropy coding unless we're using Huffman coding. This fixes a bug whereby attempting to create a progressive JPEG with arithmetic coding would fail.
Oops. We need to delete the new copy of turbojpeg.dll in the binary directory. Also add quotes to InstDir to allow installing under "c:\Program Files\", and remove unnecessary quotes in the Delete directives.
In the Windows installer packages, place a duplicate copy of turbojpeg.dll in c:\libjpeg-turbo[-gcc][64]\bin. This is mainly to give installers an easy way to find the DLL for the purposes of bundling it. Specifically, this was necessary for TurboVNC, becuase 32-bit CMake running on 64-bit Windows cannot ever access the "real" c:\windows\system32 directory.
DRC [Sun, 18 Aug 2013 10:47:07 +0000 (10:47 +0000)]
Add note regarding the fact that 4:4:0 lacks full SIMD support; Add an option for benchmarking 4:4:0 subsampling in TJBench; Wordsmithing; Disable timestamp in generated HTML files to make diffing and merging easier
DRC [Sun, 11 Aug 2013 22:57:19 +0000 (22:57 +0000)]
By default, install the libraries into /opt/libjpeg-turbo/lib32 on any 32-bit system, not just x86, and into /opt/libjpeg-turbo/lib64 on any 64-bit system, not just x86-64. In particular, this addresses an issue with building TurboVNC and VirtualGL on ARM systems.
Not that it matters, because JNI uses dlopen()/dlsym() to load symbols, but for bookkeeping purposes, move the JNI symbols introduced in libjpeg-turbo 1.3 into a new section.
Subtle point, but since libjpeg-turbo 1.3 now supports scaling factors > 1, the width and height specified in tjDecompress2() are not necessarily smaller than the JPEG width/height.
Fix I/O suspension. This little nugget of code was introduced in r30 as part of an early attempt to make buffered I/O work with the optimized Huffman codec. Ultimately, r32 reverted a lot of that mess and introduced much of the logic we now use, rendering this code unnecessary, but it was never reverted because it only causes problems when I/O suspension is used, and apparently no one has tried to do that with libjpeg-turbo until now.
projects / libjpeg-turbo / log