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.
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.
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.
projects / libjpeg-turbo / log