DRC [Wed, 28 May 2014 20:28:30 +0000 (20:28 +0000)]
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.
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:
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.
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 [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 [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.
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.
DRC [Fri, 18 Jan 2013 05:54:06 +0000 (05:54 +0000)]
Subtle point, but the libjpeg v7+ API is not backward incompatible. That is, programs that were built against jpeg-6b can still build against jpeg-7+ with no issues. It's only the ABI that is backward incompatible, so the primary justification for implementing the emulation feature was to provide run-time (ABI) compatibility.
DRC [Sun, 13 Jan 2013 12:15:58 +0000 (12:15 +0000)]
Fix the x86 build with NASM 0.98. Since NASM 0.98 is the default version on OS X, we want to at least allow people to build 32-bit code with it, even though it can't properly build 64-bit code.
DRC [Fri, 12 Oct 2012 10:18:37 +0000 (10:18 +0000)]
Use a more robust method of obtaining the build timestamp on Windows. 'wmic os get LocalDateTime' will always return the timestamp in the format we want (YYYYMMDD), whereas date /t is sensitive to locale. If wmic fails, then we fall back to using date /t, even though this means that the BUILD variable will end up in the incorrect format on some systems.
DRC [Fri, 12 Oct 2012 10:19:09 +0000 (10:19 +0000)]
Use a more robust method of obtaining the build timestamp on Windows. 'wmic os get LocalDateTime' will always return the timestamp in the format we want (YYYYMMDD), whereas date /t is sensitive to locale. If wmic fails, then we fall back to using date /t, even though this means that the BUILD variable will end up in the incorrect format on some systems.
DRC [Fri, 29 Jun 2012 23:14:48 +0000 (23:14 +0000)]
Added flags to the TurboJPEG API that allow the caller to force the use of either the fast or the accurate DCT/IDCT algorithms in the underlying codec.
DRC [Thu, 28 Jun 2012 23:25:34 +0000 (23:25 +0000)]
More recent versions of autoconf add -traditional-cpp to the CPP flags, which causes jsimdcfg.inc.h to not preprocess correctly unless we expand all of the instances of the #definev macro.
DRC [Thu, 28 Jun 2012 23:22:03 +0000 (23:22 +0000)]
Later versions of autoconf (specifically, the one shipped with Xcode 4.3) default to building x86-64, so it is necessary to override the host_alias to get a 32-bit build.
DRC [Mon, 18 Jun 2012 00:18:04 +0000 (00:18 +0000)]
Fixed regression caused by a bug in the 32-bit strict memory access code in jdmrgss2.asm (contributed by Chromium to stop valgrind from whining whenever the output buffer size was not evenly divisible by 16 bytes.) On Linux/x86, this regression caused incorrect pixels on the right-hand side of images whose rows were not 16-byte aligned, whenever fancy upsampling was used and when decompressing to a 32-bit (RGBX, etc.) buffer.
DRC [Mon, 18 Jun 2012 00:16:15 +0000 (00:16 +0000)]
Fixed regression caused by a bug in the 32-bit strict memory access code in jdmrgss2.asm (contributed by Chromium to stop valgrind from whining whenever the output buffer size was not evenly divisible by 16 bytes.) On Linux/x86, this regression caused incorrect pixels on the right-hand side of images whose rows were not 16-byte aligned, whenever fancy upsampling was used and when decompressing to a 32-bit (RGBX, etc.) buffer.
DRC [Fri, 15 Jun 2012 21:54:45 +0000 (21:54 +0000)]
Fixed regression caused by a bug in the 32-bit strict memory access code in jdmrgss2.asm (contributed by Chromium to stop valgrind from whining whenever the output buffer size was not evenly divisible by 16 bytes.) On Linux/x86, this regression generated incorrect pixels on the right-hand side of images whose rows were not 16-byte aligned, whenever fancy upsampling was used. This patch also enables the strict memory access code on all platforms, not just Linux (it does no harm on other platforms) and removes a couple of pcmpeqb instructions that were rendered unnecessary by r835.
DRC [Wed, 13 Jun 2012 01:21:29 +0000 (01:21 +0000)]
Eliminate the use of the MASKMOVDQU instruction, to speed up decompression performance by 10x on AMD Bobcat embedded processors (and ~5% on AMD desktop processors.)
DRC [Fri, 10 Feb 2012 01:30:37 +0000 (01:30 +0000)]
Infrastructure for producing a universal x86-64/i386/ARM version of libjpeg.a and libturbojpeg.a on OS X, so that the same library can be used to build OS X and iOS apps
DRC [Tue, 7 Feb 2012 23:05:46 +0000 (23:05 +0000)]
Merge copyright messages into one string and change the run-time messages to avoid confusion (we are not technically based on the latest libjpeg, although we do borrow some code from it)
DRC [Tue, 31 Jan 2012 10:39:29 +0000 (10:39 +0000)]
Merge copyright messages into one string and change the run-time messages to avoid confusion (we are not technically based on the latest libjpeg, although we do borrow some code from it)
projects / libjpeg-turbo / log