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 [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.
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.
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.
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.
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.
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.
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, 18 Aug 2013 10:39:30 +0000 (10:39 +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 23:23:41 +0000 (23:23 +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.
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.
DRC [Tue, 7 May 2013 21:17:35 +0000 (21:17 +0000)]
Fix incorrect data output and buffer overruns in the new tjDecompressToYUV2() function whenever scaling is used along with a 4:2:0 JPEG image; extend tjunittest and TJUnitTest to test for these issues.
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.
projects / libjpeg-turbo / log