DRC [Tue, 11 Mar 2014 06:24:46 +0000 (06:24 +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 [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 [Mon, 10 Mar 2014 20:14:53 +0000 (20:14 +0000)]
For now, punt on trying to support fancy upsampling in tjDecodeYUV(). Fancy upsampling requires context rows and other refinements, which are difficult to implement correctly with the algorithm we're using. Longer-term, supporting fancy upsampling would probably require using the main buffer that libjpeg allocates.
DRC [Mon, 10 Mar 2014 09:34:04 +0000 (09:34 +0000)]
When tjDecodeYUV() is used with a "fresh" decompressor instance (one that hasn't been previously used to decompress a JPEG image), then it needs comps_in_scan, data_precision, and the quantization tables to be defined. This patch also extends TJUnitTest to check for this error.
DRC [Sat, 8 Mar 2014 20:50:35 +0000 (20:50 +0000)]
Silence valgrind false positives about uninitialized values. Even with this patch, valgrind still complains about uninitialized values when decompressing or decoding to a buffer with an alpha-enabled colorspace. Not sure why this happens, but it occurs in libjpeg-turbo 1.3 as well, and only when the x86/x86-64 SIMD code is being used. It is my belief that these remaining warnings are also false positives, because if the output buffer is memset to all 0's prior to invoking tjDecodeYUV()/tjDecompress(), no errors are reported. If any of the alpha channel bits were in fact not being initialized, then they would still be 0 after invoking tjDecodeYUV()/tjDecompress(), and TJUnitTest would report an error.
DRC [Fri, 7 Mar 2014 03:52:57 +0000 (03:52 +0000)]
Go ahead and call jinit_master_decompress() rather than trying to reproduce its functionality. That function does a few things that we were missing, including allocating the range limit table used by the plain C color conversion code.
DRC [Fri, 28 Feb 2014 09:06:42 +0000 (09:06 +0000)]
Remove benchmarks. They were originally intended as a way of measuring overhead for small compress/decompress operations, but using TJBench with a small image is a better way to accomplish that.
DRC [Fri, 28 Feb 2014 05:34:02 +0000 (05:34 +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: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 [Tue, 11 Feb 2014 09:45:18 +0000 (09:45 +0000)]
Fix an issue that prevented tjEncodeYUV3() 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 tjEncodeYUV3() 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 [Fri, 7 Feb 2014 19:05:07 +0000 (19:05 +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 [Fri, 31 Jan 2014 17:22:15 +0000 (17:22 +0000)]
Some motion JPEG implementations generate "abbreviated JPEG streams" (JPEG images without the default tables included) for some or all of the video frames, in order to save space. When these are encountered, it is generally expected that they will be decompressed using the default Huffman tables, so libjpeg-turbo now does this unless the tables have been explicitly specified by an application.
DRC [Mon, 25 Nov 2013 21:12:23 +0000 (21:12 +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 r960.)
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, 6 Nov 2013 06:50:38 +0000 (06:50 +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 [Tue, 5 Nov 2013 19:53:12 +0000 (19:53 +0000)]
Add the ability to test scaling when decompressing to YUV; compression from YUV to JPEG; and YUV padding. Replace clunky -411 and -440 parameters with a -subsamp parameter that allows any of the subsampling options to be tested in isolation.
DRC [Mon, 4 Nov 2013 23:07:54 +0000 (23:07 +0000)]
Add the ability to test scaling when decompressing to YUV; compression from YUV to JPEG; and YUV padding. Replace clunky -411 and -440 parameters with a -subsamp parameter that allows any of the subsampling options to be tested in isolation.
DRC [Thu, 31 Oct 2013 07:40:24 +0000 (07:40 +0000)]
Make environment variable syntax consistent between ARM and x86 code, and add an option to disable SIMD on x86 (this option will be added to the x86-64 code as well, but it makes more sense to add it when we add AVX support.)
DRC [Thu, 31 Oct 2013 07:11:39 +0000 (07:11 +0000)]
Deprecate and undocument the FORCE{MMX|SSE|SSE2|SSE3} flags. These were originally introduced in TurboJPEG/IPP as a way to override the automatic CPU selection in the underlying IPP codec, which was closed source. They are not meaningful anymore, since libjpeg-turbo provides environment variables to accomplish the same thing and since it no longer necessarily uses x86 SIMD code behind the scenes.
DRC [Thu, 31 Oct 2013 04:53:27 +0000 (04:53 +0000)]
Clean up formatting code and rename the JPEG files generated during the YUV decode tests to reflect the fact that they are being generated from YUV source images.
DRC [Wed, 30 Oct 2013 22:21:06 +0000 (22:21 +0000)]
Fix a really subtle issue whereby an invalid free() could occur if a program called tjInitDecompress() and then accidentally passed the handle to tjEncodeYUV3(), or if a program called tjInitCompress() and then accidentally passed the handle to tjDecompressToYUV2().
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.
DRC [Sat, 12 Oct 2013 21:51:16 +0000 (21:51 +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.
projects / libjpeg-turbo / log