We use __CHAR_UNSIGNED__ (automatically defined by the AC_C_CHAR_UNSIGNED macro) rather than CHAR_IS_UNSIGNED (defined by custom autoconf code in libjpeg that we didn't port over), although I doubt it matters on any of the platforms we support.
This patch accomplishes the following:
-- Auto-generates HAVE_LOCALE_H macro and adds it to jconfig.h (this is used by rdjpgcom.c.)
-- Reconciles the description and ordering of macros between config.h.in and jconfig.h.in, so the two files can be easily diffed.
-- Eliminates the use of the autoheader-generated config.h in the project and moves relevant internal-only macros into a new file, jconfigint.h. This is to avoid "already defined" warnings in files that were including both config.h (to get the internal autotools package information or the INLINE definition) and jconfig.h.
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.
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.
Set the BUILD environment variable properly when building with MinGW implementations that lack a Unix shell (TDM-GCC, for instance); Only set CMP0022 if it is supported (older CMake implementations don't support it); Remove trailing spaces
DRC [Thu, 27 Mar 2014 20:47:39 +0000 (20:47 +0000)]
Modify svn:ignore so that it lists only files generated in-tree by autoreconf -fiv. It's pretty much impossible to maintain an up-to-date list of files generated by the actual build, so we'll just assume that the user will do an out-of-tree build if they want to avoid cluttering up their 'svn status' display.
DRC [Thu, 27 Mar 2014 03:36:04 +0000 (03:36 +0000)]
Make iOS build instructions more generic and applicable to all versions of Xcode; modify iOS build procedure for Xcode 5.0 and later to fix a build issue with Xcode 5.1.
DRC [Fri, 21 Mar 2014 23:34:53 +0000 (23:34 +0000)]
Since we're now maintaining our own Cygwin pseudo-repository directories instead of recommending that users install these packages from a local source, it makes more sense to name the packages according to Cygwin specs, so they can be copied as-is into the pseudo-repository.
DRC [Fri, 21 Mar 2014 11:00:00 +0000 (11:00 +0000)]
RHEL 6 (and probably other platforms as well) sets _defaultdocdir=%{_datadir}/doc, which screws things up, since we're overriding _datadir. Since we intend _defaultdocdir to be /usr/share/doc, just be explicit about it.
DRC [Mon, 17 Mar 2014 10:12:11 +0000 (10:12 +0000)]
Move the garbage collection of the JPEG tiles into the decompression function to increase the chances that tiled decompression of large images will succeed without an OutOfMemoryError.
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.
projects / libjpeg-turbo / log