- 1d92fb0 Fix a bug in the 64-bit Huffman encoder that Google discovered when encoding some very specific (and proprietary) aerial images using quality=98, an optimized Huffman table, and the ISLOW DCT. These images were causing the Huffman bit buffer to overflow, because the code for encoding the DC coefficient was using the equivalent of the 32-bit version of EMIT_BITS(). Thus, when 64-bit code was used, the DC coefficient code was not properly checking how many bits were in the buffer before attempting to add more bits to it. This issue appears to have existed in all versions of libjpeg-turbo. by dcommander · 10 years ago master
- fe90691 Restore backward compatibility with MSVC < 2010 (broken by r1540) by dcommander · 10 years ago
- ec25062 Oops. OS X doesn't define __WORDSIZE unless you include stdint.h, so apparently the Huffman codec hasn't ever been fully accelerated on 64-bit OS X. by dcommander · 10 years ago
- 22f5121 Allow the executables and libraries outside of the sharedlib/ directory to be linked against msvcr*.dll instead of libcmt*.lib. This is reported to be necessary when building libjpeg-turbo for use with C#. by dcommander · 10 years ago
- 5b824d4 Surround the usage of getenv() in the TurboJPEG API with #ifndef NO_GETENV so that developers can add -DNO_GETENV to the C flags when building for platforms that don't have getenv(). Currently this is known to be necessary when building for Windows Phone. by dcommander · 10 years ago
- 497b0eb Enable silent build rules for the NASM objects, if the source is configured with automake 1.11 or later. NOTE: the build still spits out "error: ignoring unknown tag NASM" for each object, but unfortunately, if we remove "--tag NASM" from the command line, the build breaks under older versions of automake (it aborts with "unable to infer tagged configuration.") by dcommander · 10 years ago
- 47203ff If libjpeg-turbo is configured with a non-default prefix, such as /usr, then use the docdir variable defined by autoconf 2.60 and later, if available. This will, for instance, install the documentation under /usr/share/doc/libjpeg-turbo by default if prefix=/usr, unless docdir is overridden. When using earlier versions of autoconf, docdir is set to ${datadir}/doc, as it always has been. by dcommander · 10 years ago
- 161bb27 Set the RPM and deb architecture properly on non-x86 platforms. by dcommander · 10 years ago
- 5bd8365 Extend the AltiVec VMX SIMD routines to support little endian PowerPC platforms. by dcommander · 10 years ago
- 6f1b1e3 Come on, Cohaagen, you got what you want. Give these people air! by dcommander · 11 years ago
- 3e38cd5 Oops. Need to set the alpha channel when using TYPE_4BYTE_ABGR*. This has no bearing on the actual tests, but it prevents the PNG pre-encode reference images for those tests from being blank. by dcommander · 11 years ago
- 8edc30d Oops. The MIPS SIMD implementations of h2v1 and h2v2 upsampling were not checking for DSPr2 support, so running 'djpeg -nosmooth' on a non-DSPr2-enabled platform caused an "illegal instruction" error. by dcommander · 11 years ago
- a5a5f1b Introduce fast paths to speed up NULL color conversion somewhat, particularly when using 64-bit code; on the decompression side, the "slow path" also now use an approach similar to that of the compression side (with the component loop outside of the column loop rather than inside.) This is faster when using 32-bit code. by dcommander · 11 years ago
- 041f19a Some clarifications (actually MIPS doesn't implement the float DCT/IDCT using SIMD instructions) by dcommander · 11 years ago
- 47d3f42 Sync change log with 1.4.x by dcommander · 11 years ago
- 53fb6b0 Make the floating point regression tests optional. It has been known for quite some time that these tests do not always generate the same results unless there is full SIMD coverage of the floating point algorithms in libjpeg-turbo. Further research reveals that there are basically three expected results: the results from our SSE SIMD extensions (which are slightly more accurate than the C code), results from the C code when running on a 32-bit FPU (or when using SSE instructions on an x86-64 CPU, which is the default with GCC), and results from the C code when running on a 64-bit FPU (which presumably uses double-precision arithmetic by default.) There is basically no way to determine which type of math will be used prior to run time, so it's best to just let the developers specify which result they expect on their particular system. by dcommander · 11 years ago
- 174f868 Document AltiVec extensions by dcommander · 11 years ago
- d74d508 Revert r1506 (we actually are generating columns with the IDCT, so the naming makes sense in retrospect); further de-confusification in the forward DCT by dcommander · 11 years ago
- a59c9ca De-confusify the variable names a bit -- "out" represents the output of the IDCT kernel, so use "final" to represent the packed data that will be stored to memory. by dcommander · 11 years ago
- e27e46f Add the ability to benchmark YCCK JPEG compression/decompression. This is particularly useful since that is the only way to test the performance of the "plain" upsampling routines, which are accelerated on some platforms. by dcommander · 11 years ago