Log

Author Commit Date CI Message
DRC d111d9ff 2020-11-17T11:54:20 Merge branch 'master' into dev
DRC 10ba6ed3 2020-11-16T17:30:37 Travis: Install MacPorts without using macports-ci
DRC 292d78e7 2020-11-16T15:28:02 Merge branch 'master' into dev
DRC 88bf1d16 2020-11-16T14:38:15 Build: Set FLOATTEST more intelligently The "32bit" vs. "64bit" floating point test results actually have nothing to do with the FPU. That was a fallacious assumption based on the observation that, with multiple CPU types, 32-bit and 64-bit builds produce different floating point test results. It seems that this is, in fact, due to differing compiler behavior-- more specifically, whether fused multiply-add (FMA) instructions are used to combine multiple floating point operations into a single instruction ("floating point expression contraction".) GCC does this by default if the target supports FMA instructions, which PowerPC and AArch64 targets both do. Fixes #468
DRC 8f830598 2020-11-13T15:21:26 Merge branch 'master' into dev
DRC 42f7c78f 2020-11-13T15:18:35 BUILDING.md: Use min. iOS v8 in iOS Armv8 example This is necessary in order to enable thread-local storage.
DRC 33859880 2020-11-13T12:12:47 Neon: Auto-detect compiler intrinsics completeness This allows the Neon intrinsics code to be built successfully (albeit likely with reduced run-time performance) with Xcode 5.0-6.2 (iOS/AArch64) and Android NDK < r19 (AArch32). Note that Xcode 5.0-6.2 will not build the Armv8 GAS code without gas-preprocessor.pl, and no version of Xcode will build the Armv7 GAS code without gas-preprocessor.pl, so we always use the full Neon intrinsics implementation by default with macOS and iOS builds. Auto-detecting the completeness of the compiler's set of Neon intrinsics also allows us to more intelligently set the default value of NEON_INTRINSICS, based on the values of HAVE_VLD1*. This is a reasonable, albeit imperfect, proxy for whether a compiler has a full and optimal set of Neon intrinsics. Specific notes: - 64-bit RGB-to-YCbCr color conversion does not use any of the intrinsics in question, regresses with GCC - 64-bit accurate integer forward DCT uses vld1_s16_x3(), regresses with GCC - 64-bit Huffman encoding uses vld1q_u8_x4(), regresses with GCC - 64-bit YCbCr-to-RGB color conversion does not use any of the intrinsics in question, regresses with GCC - 64-bit accurate integer inverse DCT uses vld1_s16_x3(), regresses with GCC - 64-bit 4x4 inverse DCT uses vld1_s16_x3(). I did not test this algorithm in isolation, so it may in fact regress with GCC, but the regression may be hidden by the speedup from the new SIMD-accelerated upsampling algorithms. - 32-bit RGB-to-YCbCr color conversion: uses vld1_u16_x2(), regresses with GCC - 32-bit accurate integer forward DCT uses vld1_s16_x3(), regression irrelevant because there was no previous implementation - 32-bit accurate integer inverse DCT uses vld1_s16_x3(), regresses with GCC - 32-bit fast integer inverse DCT does not use any of the intrinsics in question, regresses with GCC - 32-bit 4x4 inverse DCT uses vld1_s16_x3(). I did not test this algorithm in isolation, so it may in fact regress with GCC, but the regression may be hidden by the speedup from the new SIMD-accelerated upsampling algorithms. Presumably when GCC includes a full and optimal set of Neon intrinsics, the HAVE_VLD1* tests will pass, and the full Neon intrinsics implementation will be enabled automatically.
DRC 3e9e7c70 2020-11-11T17:54:06 Fix build if WITH_12BIT==1 && WITH_JPEG(7|8)==1 Fixes #466
DRC bbd80892 2020-11-10T17:54:14 Neon: Finalize intrinsics implementation - Remove gas-preprocessor.pl. None of the compilers that can build the new intrinsics implementation require gas-preprocessor.pl (tested with Xcode and with Clang 3.9+ for Linux.) - Document that Xcode 6.3.x or later is now required for iOS builds (older versions of Xcode do not have a full set of Neon intrinsics.) - Add a change log entry. - Do not enable the ASM CMake language unless NEON_INTRINSICS is false. - Add a Clang/Arm64 test to .travis.yml in order to test the new intrinsics implementation. Closes #455
Jonathan Wright 2acfb93c 2019-05-08T15:43:26 Neon: Intrinsics impl. of h1v2 fancy upsamling There was no previous GAS implementation.
Jonathan Wright 97530777 2018-06-15T11:13:52 Neon: Intrinsics impl. of h2v1 & h2v2 fancy upsamp The previous AArch32 GAS implementation of h2v1 fancy upsampling has been removed, since the intrinsics implementation provides the same or better performance. There was no previous GAS implementation of h2v2 fancy upsampling, and there was no previous AArch64 GAS implementation of h2v1 fancy upsampling.
Jonathan Wright 5dbd3932 2018-08-01T16:52:31 Neon: Intrinsics implementation of YCbCr->RGB565 The previous AArch64 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. The previous AArch32 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright 0f35cd68 2018-07-16T10:25:14 Neon: Intrinsics implementation of YCbCr->RGB The previous AArch64 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. The previous AArch32 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance.
Martyn Jacques 141f26ff 2018-09-18T18:28:31 Neon: Intrinsics impl. of 2x2 and 4x4 scaled IDCTs The previous AArch32 and AArch64 GAS implementations have been removed, since the intrinsics implementations provide the same or better performance.
Jonathan Wright f3c3f01d 2018-09-24T04:35:20 Neon: Intrinsics impl. of Huffman encoding The previous AArch64 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. The previous AArch32 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright d0004de5 2018-08-22T13:38:37 Neon: Intrinsics impl. of accurate int forward DCT The previous AArch64 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. There was no previous AArch32 GAS implementation.
Jonathan Wright 4574f01f 2018-06-28T16:17:36 Neon: Intrinsics impl. of h2v1 & h2v2 plain upsamp There was no previous GAS implementation. NOTE: This doesn't produce much of a speedup when using -O3, because -O3 already enables Neon autovectorization, which works well for the scalar C implementation of plain upsampling. However, the Neon SIMD implementation will benefit other optimization levels.
Jonathan Wright 3d84668d 2018-08-23T14:22:23 Neon: Intrinsics impl. of fast integer forward DCT The previous AArch32 and AArch64 GAS implementations have been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright 951d3677 2018-08-24T18:04:21 Neon: Intrinsics impl. of int sample conv./quant. The previous AArch32 and AArch64 GAS implementations have been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright ba52a3de 2018-07-19T18:46:24 Neon: Intrinsics impl of h2v1 & h2v2 merged upsamp There was no previous GAS implementation. This commit also reverts 40557b23015d2f8b576420231b8dd1f39f2ceed8 and 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57. 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57 was only necessary because there was no Neon implementation of merged upsampling/color conversion, and 40557b23015d2f8b576420231b8dd1f39f2ceed8 was only necessary because of 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57.
Jonathan Wright 366168aa 2018-08-06T15:14:34 Neon: Intrinsics impl. of h2v1 & h2v2 downsampling The previous AArch64 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance. There was no previous AArch32 GAS implementation.
Jonathan Wright f73b1dbc 2018-08-09T15:08:21 Neon: Intrinsics implementation of RGB->Grayscale There was no previous GAS implementation.
Jonathan Wright 240ba417 2020-01-07T16:40:32 Neon: Intrinsics impl. of prog. Huffman encoding The previous AArch64 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance. There was no previous AArch32 GAS implementation.
Jonathan Wright ed581cd9 2019-06-12T18:16:53 Neon: Intrinsics impl. of accurate int inverse DCT The previous AArch32 and AArch64 GAS implementations are retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable.
Jonathan Wright 2c6b68e2 2018-09-25T18:20:25 Neon: Intrinsics impl. of fast integer Inverse DCT The previous AArch32 GAS implementation is retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using the new NEON_INTRINSICS CMake variable. The previous AArch64 GAS implementation has been removed, since the intrinsics implementation provides the same or better performance.
Jonathan Wright 4f2216b4 2019-11-26T18:14:33 Neon: Intrinsics implementation of RGB->YCbCr The previous AArch32 and AArch64 GAS implementations are retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using a new NEON_INTRINSICS CMake variable.
DRC 0efc4858 2020-11-09T18:55:21 Merge branch 'master' into dev
DRC 02227e48 2020-11-09T16:31:49 Travis: Combine PPC/Arm tests with jpeg-7/8 tests There is no reason not to, since the jpeg-7 and jpeg-8 API/ABI tests do not exercise the SIMD extensions any differently than the other tests.
DRC c7dd1912 2020-11-08T15:15:02 Merge branch 'master' into dev
DRC 40557b23 2020-11-06T18:51:55 Build: Fix test failures w/ Arm Neon SIMD exts Regression caused by a46c111d9f3642f0ef3819e7298846ccc61869e0 Because of 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57, which was introduced in libjpeg-turbo 1.5.1 in response to #81, merged upsampling/ color conversion is disabled on platforms that have SIMD-accelerated YCbCr -> RGB color conversion but not SIMD-accelerated merged upsampling/color conversion. This was intended to improve performance with the Neon SIMD extensions, since those are the only SIMD extensions for which those circumstances apply. Under normal circumstances, the separate "plain" (non-fancy) upsampling and color conversion routines will produce bitwise-identical output to the merged upsampling/color conversion routines, but that is not the case when skipping scanlines starting at an odd-numbered scanline. The modified test introduced in a46c111d9f3642f0ef3819e7298846ccc61869e0 does precisely that in order to validate the fixes introduced in 9120a247436e84c0b4eea828cb11e8f665fcde30 and a46c111d9f3642f0ef3819e7298846ccc61869e0. Because of 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57, the segfault fixed in 9120a247436e84c0b4eea828cb11e8f665fcde30 and a46c111d9f3642f0ef3819e7298846ccc61869e0 didn't affect the Neon SIMD extensions, so this commit effectively reverts the test modifications in a46c111d9f3642f0ef3819e7298846ccc61869e0 when using those SIMD extensions. We can get rid of this hack, as well as 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57, once a Neon implementation of merged upsampling/color conversion is available.
DRC a524b9b0 2020-11-06T17:24:16 Travis: Regression-test Armv8 and PPC SIMD exts Currently this only tests the 64-bit code paths, but it's better than nothing.
DRC 7c1a1789 2020-11-05T16:04:55 Merge branch 'master' into dev
DRC 6e632af9 2020-11-04T10:13:06 Demote "fast" [I]DCT algorithms to legacy status - Refer to the "slow" [I]DCT algorithms as "accurate" instead, since they are not slow under libjpeg-turbo. - Adjust documentation claims to reflect the fact that the "slow" and "fast" algorithms produce about the same performance on AVX2-equipped CPUs (because of the dual-lane nature of AVX2, it was not possible to accelerate the "fast" algorithm beyond what was achievable with SSE2.) Also adjust the claims to reflect the fact that the "fast" algorithm tends to be ~5-15% faster than the "slow" algorithm on non-AVX2-equipped CPUs, regardless of the use of the libjpeg-turbo SIMD extensions. - Indicate the legacy status of the "fast" and float algorithms in the documentation and cjpeg/djpeg usage info. - Remove obsolete paragraph in the djpeg man page that suggested that the float algorithm could be faster than the "fast" algorithm on some CPUs.
DRC cd342acf 2020-10-27T16:42:14 Merge branch 'master' into dev
DRC c3bfbde2 2020-10-27T15:36:19 jpegtran.c: "subarea" = "region" It is our convention to use the term "region" when referring to crop specs, since this is more consistent with the terminology used by the rest of the image processing community.
DRC a8656d70 2020-10-27T15:35:21 jpegtran.1: Minor formatting tweak
DRC 9ecb67c2 2020-10-27T15:32:46 transupp.c: Code formatting tweaks
DRC 53c685b7 2020-10-27T15:16:13 cdjpeg.h: Remove unused function stub enable_signal_catcher() was only needed with libjpeg's temp. file memory manager (jmemname.c), which libjpeg-turbo has never supported.
DRC d27b935a 2020-10-27T15:04:39 Consistify formatting to simplify checkstyle The checkstyle script was hastily developed prior to libjpeg-turbo 2.0 beta1, so it has a lot of exceptions and is thus prone to false negatives. This commit eliminates some of those exceptions.
DRC 88ae6098 2020-10-27T13:28:56 Merge branch 'ijg' into dev - Restore GIF read/compressed GIF write support from jpeg-6a and jpeg-9d. - Integrate jpegtran -wipe and -drop options from jpeg-9a and jpeg-9d. - Integrate jpegtran -crop extension (for expanding the image size) from jpeg-9a and jpeg-9d. - Integrate other minor code tweaks from jpeg-9*
DRC 7e4eac70 2020-10-26T09:41:32 Merge branch 'master' into dev
Guido Vollbeding 9fc018fd 2020-01-12T00:00:00 The Independent JPEG Group's JPEG software v9d
Guido Vollbeding 96e4e7eb 2018-01-14T00:00:00 The Independent JPEG Group's JPEG software v9c
DRC 26e3aedb 2020-10-22T23:04:24 README.ijg: Update URLs; remove Usenet info
DRC b4525f9f 2020-10-19T22:05:09 jversion.h: Update copyrights
DRC 59352195 2020-10-19T21:17:46 Merge branch 'master' into dev
DRC f7ca3c5a 2020-10-19T15:34:03 Build: Improve Arm 32-bit cross-comp./packaging - Set CPU_TYPE=arm if performing a 32-bit build on an AArch64 system. This eliminates the need to use a CMake toolchain file. - Set RPMARCH=armv7hl if building on a 32-bit Arm system with an FPU. - Set RPMARCH=armv7hl and DEBARCH=armhf if performing a 32-bit build using a gnueabihf toolchain. - If performing a 32-bit Arm build, generate a 32-bit supplementary DEB package for AArch64 systems.
DRC 1ed312ea 2020-10-15T17:47:31 "ARM"="Arm", "NEON"="Neon" Refer to: https://www.arm.com/company/policies/trademarks/arm-trademark-list/arm-trademark https://www.arm.com/company/policies/trademarks/arm-trademark-list/neon-trademark NOTE: These changes are only applied to change log entries for 2.0.x and later, since the change log is a historical record and Arm's new trademark policy did not go into effect until late 2017.
DRC b8200c66 2019-03-08T11:57:54 Build: Add CMake package config files Based on: https://github.com/hjmallon/libjpeg-turbo/commit/d34b89b41134bd2b581e222514ee493594193d87 Closes #339 Closes #342
DRC ea8f643c 2020-10-14T16:30:44 Build: Remove lib32 symlink from official Mac pkg (oversight from 4c5a15c362a951a66066521bd049728116eb7ead)
DRC 460dfe40 2020-10-14T14:46:30 ChangeLog: Acknowledge 2.0.6 release
DRC ae08115d 2020-10-15T10:25:46 Merge branch 'master' into dev
DRC b5a14727 2020-10-15T10:22:51 Build: Fix permissions
DRC 190382b7 2020-10-14T15:14:26 ChangeLog: Fix minor formatting issue
DRC 8789a5e2 2020-10-01T21:27:47 Merge branch 'master' into dev
DRC 89c88c25 2020-10-01T21:24:27 ChangeLog.md: jpeg_crop_scanline(), not scanlines
DRC 2ec4a5eb 2020-10-01T19:18:44 Fix dec artifacts w/cropped+smoothed prog DC scans This commit modifies decompress_smooth_data(), adding missing MCU column offsets to the prev_block_row and next_block_row indices that are used for block rows other than the first and last. Effectively, this eliminates unexpected visual artifacts when using jpeg_crop_scanline() along with interblock smoothing while decompressing the DC scan of a progressive JPEG image. Based on: https://github.com/mo271/libjpeg-turbo/commit/0227d4fb484e6baf1565163211ee64e52e7b96bd Fixes #456 Closes #457
DRC 1d7faf84 2020-10-01T18:17:46 Merge branch 'master' into dev
DRC 8e895c79 2020-10-01T18:13:35 Java dox: Fix errors w/ javadoc in Java 8 or later
DRC 2b121d39 2020-10-01T16:20:14 Merge branch 'master' into dev
DRC 2d14fc2e 2020-10-01T14:35:46 Dox: Re-generate using Doxygen 1.8.20 This fixes a GitHub Dependabot alert regarding jquery.js. Fixes #421
DRC 6ab61fa1 2020-09-13T17:02:09 Merge branch 'master' into dev
DRC fe5b6a1c 2020-09-13T16:58:08 TJPEG: Remove unnecessary setCompDefaults() retval setCompDefaults() hasn't thrown an error since aa7459050d7a50e1d8a99488902d41fbc118a50f was introduced in 2.0.x.
DRC 6ee5d5f5 2020-07-28T18:06:20 ARMv8 NEON: Support Windows builds w/AArch64 MinGW Based on: https://github.com/mstorsjo/libjpeg-turbo/commit/c5ef6659285a7d5bc74c679aa87ad187186cf7e1 Closes #438
DRC fe79f56b 2020-07-28T15:09:00 Merge branch 'master' into dev
DRC c1037f43 2020-07-28T14:57:47 Fix bad return val when skipping past end of image Fixes #439
DRC 30282a87 2020-07-28T13:00:39 README.md, jquant2.c: Use gender-neutral pronouns Closes #444
DRC a46c111d 2020-07-27T14:21:23 Further jpeg_skip_scanlines() fixes - Introduce a partial image decompression regression test script that validates the correctness of jpeg_skip_scanlines() and jpeg_crop_scanlines() for a variety of cropping regions and libjpeg settings. This regression test catches the following issues: #182, fixed in 5bc43c7821df982f65aa1c738f67fbf7cba8bd69 #237, fixed in 6e95c08649794f5018608f37250026a45ead2db8 #244, fixed in 398c1e9acc9b4531edceb3d77da0de5744675052 #441, fully fixed in this commit It does not catch the following issues: #194, fixed in 773040f9d949d5f313caf7507abaf4bd5d7ffa12 #244 (additional segfault), fixed in 9120a247436e84c0b4eea828cb11e8f665fcde30 - Modify the libjpeg-turbo regression test suite (make test) so that it checks for the issue reported in #441 (segfault in jpeg_skip_scanlines() when used with 4:2:0 merged upsampling/color conversion.) - Fix issues in jpeg_skip_scanlines() that caused incorrect output with h2v2 (4:2:0) merged upsampling/color conversion. The previous commit fixed the segfault reported in #441, but that was a symptom of a larger problem. Because merged 4:2:0 upsampling uses a "spare row" buffer, it is necessary to allow the upsampler to run when skipping rows (fancy 4:2:0 upsampling, which uses context rows, also requires this.) Otherwise, if skipping starts at an odd-numbered row, the output image will be incorrect. - Throw an error if jpeg_skip_scanlines() is called with two-pass color quantization enabled. With two-pass color quantization, the first pass occurs within jpeg_start_decompress(), so subsequent calls to jpeg_skip_scanlines() interfere with the multipass state and prevent the second pass from occurring during subsequent calls to jpeg_read_scanlines().
DRC 9120a247 2020-07-23T21:24:38 Fix jpeg_skip_scanlines() segfault w/merged upsamp The additional segfault mentioned in #244 was due to the fact that the merged upsamplers use a different private structure than the non-merged upsamplers. jpeg_skip_scanlines() was assuming the latter, so when merged upsampling was enabled, jpeg_skip_scanlines() clobbered one of the IDCT method pointers in the merged upsampler's private structure. For reasons unknown, the test image in #441 did not encounter this segfault (too small?), but it encountered an issue similar to the one fixed in 5bc43c7821df982f65aa1c738f67fbf7cba8bd69, whereby it was necessary to set up a dummy postprocessing function in read_and_discard_scanlines() when merged upsampling was enabled. Failing to do so caused either a segfault in merged_2v_upsample() (due to a NULL pointer being passed to jcopy_sample_rows()) or an error ("Corrupt JPEG data: premature end of data segment"), depending on the number of scanlines skipped and whether the first scanline skipped was an odd- or even-numbered row. Fixes #441 Fixes #244 (for real this time)
DRC c965dc7a 2020-07-22T13:59:27 ChangeLog.md: Add missing sub-header for 2.0.6
DRC b9142b21 2020-07-22T13:24:51 Android: Fix "using JNI after critical get" errors (again.) Fixes #300
DRC 7d829bfa 2020-07-07T10:16:29 Bump version to 2.0.6 to prepare for new commits
DRC fb6f5e8b 2020-06-25T21:31:11 Java/Mac:Remove obsolete libturbojpeg.jnilib alias IIRC, this was only necessary with the version of Java 1.5 that shipped with OS X 10.4 "Tiger". Apple's implementation of Java 6 ("Java for OS X Systems") supported both .jnilib and .dylib extensions for JNI libraries, but Oracle's implementation of Java has only ever supported the .dylib extension.
DRC c77783ed 2020-06-25T21:28:33 BUILDING.md: Undocument 32-bit Mac build/packaging (oversight from previous commit)
DRC 4c5a15c3 2020-06-25T19:08:19 Eliminate 32-bit Mac build/packaging support The scales have now tilted overwhelmingly in favor of eliminating support for 32-bit Macs: - 32-bit applications are only necessary in order to support OS X 10.5 "Leopard" and OS X 10.6 "Snow Leopard". OS X 10.7 "Lion" requires a 64-bit Mac and supports all 64-bit Macs. - 32-bit applications are no longer allowed in the macOS App Store. - 32-bit applications no longer run in macOS 10.15 "Catalina". - 32-bit applications do not support thread-local storage, so the TurboJPEG API library's global error handler is not thread-safe with such applications. - libjpeg-turbo 2.1.x no longer supports 32-bit iOS apps, so it makes sense to also eliminate support for 32-bit macOS applications. It's time.
DRC b797f700 2020-06-25T19:05:45 Build: Eliminate Cygwin packaging support We haven't provided official Cygwin builds since 1.4.x, since Cygwin now supplies its own libjpeg-turbo packages (although they apparently haven't been updated past 1.5.3.)
DRC 80d77720 2020-06-19T00:22:49 AppVeyor: We no longer build/package JNI JARs This was done solely to support Java Web Start, which is now obsolete.
DRC aecee256 2020-06-19T00:03:51 Merge branch 'master' into dev
DRC ae87a958 2020-06-16T13:52:39 TurboJPEG: Make global error handling thread-safe ... on platforms that support thread-local storage. This currently includes all supported platforms except 32-bit macOS. Fixes #396
DRC b443c541 2020-06-03T16:08:08 ChangeLog.md: Add missing sub-header for 2.0.5
DRC cf483eee 2020-06-03T16:04:06 ChangeLog.md: List CVE ID fixed by previous commit
DRC 70040cb7 2020-06-02T15:05:43 Merge branch 'master' into dev
DRC 3de15e0c 2020-06-02T14:15:37 rdppm.c: Fix buf overrun caused by bad binary PPM This extends the fix in 1e81b0c3ea26f4ea8f56de05367469333de64a9f to include binary PPM files with maximum values < 255, thus preventing a malformed binary PPM input file with those specifications from triggering an overrun of the rescale array and potentially crashing cjpeg, TJBench, or any program that uses the tjLoadImage() function. Fixes #433
Andrew Childs a2291b25 2020-05-05T14:38:39 Build: Add missing jpegtran-icc test dependency The jpegtran-icc test must run after the cjpeg-rgb-islow test, since the latter generates testout_rgb_islow.jpg.
DRC 219e8e8f 2020-04-02T22:26:19 Merge branch 'master' into dev
DRC a36deef5 2020-04-02T22:23:02 rdswitch.c: Eliminate spaces before semicolons (detected with a modified version of checkstyle)
DRC b0f92a1d 2020-03-04T11:06:45 Merge branch 'master' into dev
DRC 8cc1277b 2020-02-24T13:29:50 TJCompressor.compress(int): Fix YUV-to-JPEG error Due to an oversight, the TJCompressor.compress(int) method did not handle YUV source images. Fixes #413
DRC 77ff3bd6 2020-02-18T12:56:01 Merge branch 'master' into dev
DRC ecf5f9a9 2020-02-18T10:43:23 Bump version to 2.0.5; Document previous commit
DRC 00d48d7e 2020-02-17T18:14:10 Merge branch 'master' into dev
DRC 035262a1 2020-02-17T18:03:10 MIPS DSPr2: Work around various 'make test' errors Referring to #408, this commit #ifdefs DSPr2 SIMD functions that only work on little endian processors, and it completely excludes jsimd_h2v1_downsample_dspr2() and jsimd_h2v2_downsample_dspr2(). The latter two functions fail with the TJBench tiling regression tests, most likely because the implementation of the functions predates those tests.
DRC ed7cab47 2020-02-17T16:35:00 MIPS DSPr2: Fix compiler warning with -mdspr2 If -mdspr2 is passed to the compiler, __mips_dsp will be defined, and __mips_dsp_rev will be >= 2, so parse_proc_cpuinfo() will not be used.
DRC 42d679b9 2020-02-17T15:19:32 MIPS SIMD: Always honor JSIMD_FORCE* env vars Previously, these environment variables were not honored unless a 74K CPU was detected, but this detection doesn't work properly with QEMU's user mode emulation. With all other CPU types, libjpeg-turbo honors JSIMD_FORCE* regardless of CPU detection.
DRC 044c22e1 2020-02-17T13:41:26 Test: Honor CMAKE_CROSSCOMPILING_EMULATOR variable This CMake variable is intended to define a wrapper program for executing cross-compiled executables. However, CTest doesn't use CMAKE_CROSSCOMPILING_EMULATOR, because it isn't obvious which tests should be executed with the wrapper and which tests are scripts that don't need it. This commit manually prepends ${CMAKE_CROSSCOMPILING_EMULATOR} to all unit test command lines that execute a program built by the libjpeg-turbo build system. Thus, one can set CMAKE_CROSSCOMPILING_EMULATOR in a CMake toolchain file to (for instance) "qemu-{architecture} {qemu_arguments}") in order to execute all eligible unit tests using QEMU.
DRC 9a2cf323 2020-02-11T13:41:43 Build: Enable separate iOS pkg/DMG w/ sim support Refer to #406
DRC 6aabca86 2020-02-11T12:47:12 Merge branch 'master' into dev
DRC 70327296 2020-02-07T17:04:30 makemacpkg.in: Allow universal DMG w/o ARMv8 arch (buglet)
DRC 379edfd8 2020-01-16T20:52:58 AppVeyor: Use Visual C++ 2015 instead of 2010 Visual C++ < 2015 is no longer under mainstream support, and Visual C++ 2010 will not be supported at all after July of this year. (https://docs.microsoft.com/en-us/visualstudio/releases/2019/servicing)
DRC ada6ea51 2020-01-16T20:52:15 BUILDING.md: Update Visual C++ recommendations