kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
DRC 5bc43c78 2017-11-13T21:01:53 Further partial image decompression fixes - Referring to 073b0e88a192adebbb479ee2456beb089d8b5de7 and #185, the reason why BMP and RLE didn't (and won't) work with partial image decompression is that the output engines for both formats maintain a whole-image buffer, which is used to reverse the order of scanlines. However, it was straightforward to add -crop support for GIF and Targa, which is useful for testing partial image decompression along with color quantization. - Such testing reproduced a bug reported by Mozilla (refer to PR #182) whereby jpeg_skip_scanlines() would segfault if color quantization was enabled. To fix this issue, read_and_discard_scanlines() now sets up a dummy quantize function in the same manner that it sets up a dummy color conversion function. Closes #182
DRC f3ad13e3 2017-11-13T16:00:35 TJBench/TJUnitTest: Don't ignore mistyped args
DRC 94e152b1 2017-11-13T08:15:50 TurboJPEG C: Code formatting tweaks
DRC 073b0e88 2017-11-08T21:01:57 djpeg -crop: Exit gracefully with non-PPM formats ... and document that only PPM/PGM output images are supported with the -crop option for the moment. I investigated the possibility of supporting -crop with -bmp, but even after resetting the buffer dimensions, I still kept getting virtual array access errors. It seems that doing this the "right way" would require creating a re-initialization function for each image format's destination manager. I'm disinclined to do that right now, given that this feature was Google's baby (developed as a prerequisite for including libjpeg-turbo in Android), and the -crop option in djpeg is intended only as an example of how to use the partial image decompression API. Real-world applications would need to handle this in their own destination managers. It would probably be possible to make this work with Targa by employing a similar hack to the one we used with PPM, but Targa isn't popular enough to bother. Fixes #185
DRC 1b385f37 2017-09-20T16:52:48 Prevent "unmappable character" error in Java build This was causing the build to fail when rebuilding libjpeg-turbo from a source RPM.
DRC fd778bba 2017-09-19T20:01:34 Fix PowerPC 32-bit RPM build
DRC 8d403aeb 2017-09-19T13:03:49 Fix 32-bit RPM build w/ newer RHEL/Fedora releases The version of RPM on RHEL 5 and older platforms defines _libdir as %{_exec_prefix}/%{_lib}, so defining _lib in the spec file redefined _libdir. However, newer versions of RPM (probably >= 4.6, since that was the version that introduced the ISA macros) define _libdir as either %{_prefix}/lib or %{_prefix}/lib64. Thus, we need to explicitly override _libdir in our spec file.
DRC 01b74c10 2017-09-11T10:06:22 Packaging: Use parallel make when rebuilding SRPM
DRC db0dec3c 2017-09-11T09:48:33 Travis: Limit parallel make jobs to # of CPU cores This tends to be faster than 'make -j', since it is making more wise use of the available resources.
nyg ba6e9d8a 2017-09-05T18:23:04 wrjpgcom: Fix comment typo Comment was copied/pasted from skip_variable() without making the necessary modifications.
DRC 5426a4cb 2017-09-02T04:08:06 TJUnitTest: Usage formatting tweaks
DRC d0bac69a 2017-09-02T03:40:46 Java: Fix TJUnitTest on big endian platforms It is necessary for the C code to be aware of the machine's endianness, which is why the TurboJPEG Java wrapper sets a different pixel format for integer BufferedImages depending on ByteOrder.nativeOrder(). However, it isn't necessary to handle endianness in pure Java code such as TJUnitTest (d'oh!) This was a product of porting the C version of TJUnitTest too literally, and of insufficient testing (historically, the big endian systems I had available for testing didn't have Java.)
DRC 59322e09 2017-09-01T21:57:48 Build: Change ppc64le DEB arch to ppc64el This is the convention among Debian-based distros.
DRC 4ded4dfa 2017-09-01T09:01:00 Build: Fix AltiVec detection on OS X Leopard The ability to directly access elements of an AltiVec vector is apparently a more recent thing.
DRC 02fa8f24 2017-09-01T01:10:08 Fix build on PowerPC SPE systems SPE systems don't support AltiVec instructions. Fixes #172
DRC 32120054 2017-08-14T10:54:27 Java: Fix NullPointerException in YUVImage planes == null is a valid argument to setBuf() if alloc == true, so we need to make sure that planes is non-null before validating its length. We also need to allocate one dimension of the planes array if it's null. Fixes #168
DRC 14783612 2017-08-14T11:18:35 Bump version to 1.5.3 to prepare for new commits
DRC e5c1613c 2017-07-07T15:15:19 x86: Fix "short jump is out of range" w/ NASM<2.04
DRC b0971e47 2017-06-28T14:47:45 TurboJPEG: Document xform issue w/ big marker data If the source image for a transform operation has a lot of EXIF or ICC data embedded in it, then it may cause the output image size to exceed the worst-case size returned by tjBufSize() (because tjTransform() transfers all markers to the output image.) This is only a problem if TJFLAG_NOREALLOC is passed to the function. Since the TurboJPEG C API doesn't require the destination image size to be set in this case, it makes the documented assumption that the calling program has allocated the destination buffer to exactly the size returned by tjBufSize(). Changing this assumption would change the API behavior and necessitate a new function name (tjTransform2().) At the moment, it's easier to just document this as a known issue, since it's easy to work around in the C API. The Java API is unfortunately a different story, since it must always use TJFLAG_NOREALLOC (because, when using the TurboJPEG Java API, all buffers are allocated on the Java heap, and thus they can't be reallocated by the C code.) There is no easy way to work around this without changing the C API as discussed above, because if the source image contains large amounts of marker data, it's virtually impossible to determine how big the output image will be.
DRC e248d430 2017-06-28T14:40:35 Java TJBench: Fix parsing of -warmup argument Due to an oversight, this wasn't included in 1db1ce45da2e78d87ff05119b674c71d630926aa.
DRC acb63493 2017-06-27T19:45:35 Build: Disable warmup in TJBench regression tests Fixes slow-down in 'make test' caused by previous commit.
DRC 1db1ce45 2017-06-27T14:22:39 TJBench: Improve consistency of results Given that libjpeg-turbo can often process hundreds of megapixels/second on modern hardware, the default of one warmup iteration was essentially meaningless. Furthermore, the -warmup option was a bit clunky, since it required some foreknowledge of how fast the benchmarks were going to execute. This commit introduces a 1-second warmup interval for each benchmark by default, and the -warmup option has been retasked to control the length of that interval.
DRC d0c3aa90 2017-06-27T11:36:25 TurboJPEG: C API documentation buglet TJFLAG_NOREALLOC, tjAlloc(), and tjFree() apply to all TurboJPEG compression functions, not just tjCompress2().
DRC 6a2b0674 2017-05-11T18:33:47 TJBench: Code formatting tweaks Spaces-->tab + remove stray control character that was introduced in 95e4cb206085c3a715f0f017c174fdf367a2c1ff
DRC 11eec4a3 2017-06-26T20:48:02 TJBench: Fix errors when decomp. files w/ ICC data Embedded ICC profiles can cause the size of a JPEG file to exceed the size returned by tjBufSize() (which is really meant to be used for compression anyhow, not for decompression), and this was causing a segfault (C) or an ArrayIndexOutOfBoundsException (Java) when decompressing such files with TJBench. This commit modifies the benchmark such that, when tiled decompression is disabled, it re-uses the source buffer as the primary JPEG buffer.
DRC 301ba4f3 2017-06-26T15:15:08 BUILDING.md: Include Android/x86 build recipes Addresses a concern raised in #155.
DRC 70f236dd 2017-05-08T08:15:11 Travis: Fix OS X build The Travis xcode7.3 image now apparently includes GnuPG 1.4.x by default, so use it instead of installing GnuPG 2. Using GnuPG 2.1.x, the default version in Homebrew as of this writing, is problematic for this reason: https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase
DRC 2a4f1894 2017-05-05T20:45:40 Restore compatibility with older autoconf releases (broken by f06cc1200fd5f61b63479d7099ccf4a7457a89bd) Fixes #149
DRC 9d64f3c6 2017-04-24T14:42:58 Attribute ARM runtime detection code to Nokia This code was submitted in the initial ARM NEON patches (https://sourceforge.net/p/libjpeg-turbo/patches/7/) by Siarhei while he was still a Nokia employee.
DRC da2a27ef 2017-03-18T16:15:14 Honor max_memory_to_use/JPEGMEM/-maxmemory This re-introduces a feature of the obsolete system-specific libjpeg memory managers-- namely the ability to limit the amount of main memory used by the library during decompression or multi-pass compression. This is mainly beneficial for two reasons: - Works around a 2 GB limit in libFuzzer - Allows security-sensitive applications to set a memory limit for the JPEG decoder so as to work around the progressive JPEG exploit (LJT-01-004) described here: http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf This commit also removes obsolete documentation regarding the MS-DOS memory manager (which itself was removed long ago) and changes the documentation of the -maxmemory switch and JPEGMEM environment variable to reflect the fact that backing stores are never used in libjpeg-turbo. Inspired by: https://github.com/caolanm/libjpeg-turbo/commit/066fee2e7d6834f24838bc1896aa38ca77209e3c Closes #143
DRC c082dc03 2017-03-18T13:24:50 AppVeyor: Fix CI build Something changed in the CI build environment, and our previous trick of setting the Git URL to file://c:/projects/libjpeg-turbo no longer works. Using cygpath to translate the Windows path to a MinGW-friendly format is a better solution anyhow.
DRC d4c41fe0 2017-03-18T12:56:36 TurboJPEG: Fix potential memory leaks Referring to https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=746, it seems that the values of local buffer pointers in TurboJPEG API functions aren't always preserved if longjmp() returns control to a point prior to the allocation of the local buffers. This is known to be an issue with GCC 4.x and clang with -O1 and higher optimization levels but not with GCC 5.x and later. It is unknown why GCC 5.x and 6.x do not suffer from the issue, but possibly the local buffer pointers are not allocated on the stack when using those more recent compilers. In any case, this commit modifies the TurboJPEG API library code such that the jump buffer is always updated after any local buffer pointers are allocated but before any subsequent libjpeg API functions are called.
DRC a0b7de9a 2017-01-19T18:51:41 Always tweak EXIF w/h tags w/ lossless transforms ... even if using libjpeg v6b emulation. Previously adjust_exif_parameters() was only called with libjpeg v7/v8 emulation, but due to a bug (which this commit also fixes), it only worked properly with libjpeg v8 emulation.
DRC 22527955 2017-01-19T17:50:59 Fix error w/ lossless crop & libjpeg v7 emulation The JPEG_LIB_VERSION #ifdef in jtransform_adjust_parameters() was incorrect, which caused a "Bogus virtual array access" error when attempting to use the lossless crop feature. Introduced in c04bd3cc97f44fd9030de1e141754c8775d4e5a5. This also adds libjpeg v7 API/ABI emulation to the Travis CI tests.
DRC eb38b61b 2017-01-19T16:44:10 Include jpeg_skip/crop_scanlines() in jpeg7.dll ... when the in-memory source/destination managers are included. Oversight in 306e1d2d778cf5a4d2a22ac847a31722b9fc2845 and 3ab68cf563f6edc2608c085f5c8b2d5d5c61157e.
DRC 47b29e8c 2017-01-19T15:36:58 libjpeg.txt: Include partial decomp. in TOC (oversight)
DRC e1e816e6 2017-01-19T15:33:48 Slightly de-confusify cjpeg, jpegtran usage info + bump copyright year
DRC 64410181 2016-12-10T09:32:23 LICENSE.md: Include text of BSD/zlib licenses LICENSE.md is included in the binary distributions as well, so it doesn't make much sense to refer to license headers in source files that aren't necessarily going to be there.
DRC fcfc6c5e 2016-12-05T14:02:59 Fix build when CFLAGS contains -std=c89 (or -ansi) This is a subtle point, but AC_C_INLINE defines "inline" to be either "inline", "__inline__", or "__inline". The subsequent test for "inline __attribute__((always_inline))" uses this definition. The attribute is irrespective of the inline keyword, so whereas "__inline__ __attribute__((always_inline))" works under C89, "inline __attribute__((always_inline))" doesn't, and defining INLINE to the latter causes the build to fail. The easiest way around this is simply to define "inline" ahead of "INLINE" in jconfigint.h, which causes the inline keyword detected by AC_C_INLINE to modify the INLINE macro if necessary.
DRC 786b6493 2016-12-05T12:39:49 Reorg AltiVec detection code + advertise that full AltiVec SIMD acceleration is now available on OpenBSD. The relevant compilers probably all support C99 or GNU's variation of C90 that allows variables to be declared anywhere, but our policy is to conform to the C90 standard, if for no other reason than that it improves code readability.
Donovan Watteau f4ba09b3 2016-12-03T15:46:49 Detect AltiVec support on OpenBSD
Colin Cross 0f4fcced 2016-12-01T16:56:18 Fix sign mismatch comparison warnings Fixes: rdppm.c:257:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] if (temp > maxval) ~~~~ ^ ~~~~~~ rdppm.c:284:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] if (temp > maxval) ~~~~ ^ ~~~~~~ rdppm.c:289:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] if (temp > maxval) ~~~~ ^ ~~~~~~ rdppm.c:294:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] if (temp > maxval)
DRC 82bf7f58 2016-12-01T18:23:32 Fix md5cmp on AmigaOS 4 (PowerPC big-endian) + Document AmigaOS support in the change log. Based on: https://github.com/chris-y/libjpeg-turbo/commit/b4f3b757970cd9dd448af9d2713b6bcdd9929147 Closes #119
DRC 3582ce90 2016-12-01T01:58:34 Travis: Use xcode7.3 image The xcode7.2 image is verfallen, verlumpt, verblunget, verkackt This also ensures that the build scripts are checked out from a branch matching the libjpeg-turbo repository branch (not strictly necessary when building from master, but it keeps the code in sync with dev.)
DRC d6d7b539 2016-11-21T22:58:18 AppVeyor: Use built-in MSYS2 MinGW compilers AppVeyor already has MinGW32 and MinGW64 flavors of GCC 5.3.0 installed under MSYS2, so there is no need to install our own builds of MinGW. MinGW-builds is no longer an active project, and we were getting occasional timeouts while wgetting those files from SourceForge. Furthermore, GCC 5.3.0 should produce faster code than GCC 4.8.1.
DRC f9f0c75b 2016-11-20T20:59:55 BUILDING.md: Clarifications and wordsmithing Updated out-of-date information, wordsmithed and clarified many sections, and generally cleaned up the build recipes (including a complete overhaul of the iOS recipes.)
DRC 3da94de2 2016-11-20T19:10:54 Windows build: Add an "uninstall" target
DRC ab664e35 2016-11-18T09:09:41 BUILDING.md/README.md: Increment libjpeg SO age Documentation buglet. This should have been changed in 6ed4d9d11085acd04dc7f2f899848693976dc010 to reflect the addition of libjpeg API functions in libjpeg-turbo 1.5.
DRC ce26e83f 2016-11-18T09:08:52 README.md: Don't use trailing spaces as line break Makes it easier to maintain this file using editors that automatically remove trailing spaces.
DRC 74e4c793 2016-11-16T15:08:16 TJBench: Fix regression/-nowrite always enabled Introduced by eb59b6e72d8098a1f7b8c7e0c710b32eb6f5dc45
DRC a280fa63 2016-11-15T09:52:49 BUILDING.md: Don't use trailing spaces as line break Makes it easier to maintain this file using editors that automatically remove trailing spaces.
DRC 6aae0077 2016-11-15T08:37:04 CMake build system: Fix the "testclean" target Regression caused by f9134384b728d8943f252b27464d83c4b7b2d159 This commit also makes the "testclean" target clean up the 4:1:1 test images. This was implemented in the autotools build system in 1f3635c4969f2319a01c9fe561958815b733227f but was left out of the CMake build system due to an oversight.
Chris Young 4ad94b29 2016-11-18T19:03:28 Detect AltiVec support on AmigaOS 4
DRC 2d4b2f14 2016-10-20T17:55:55 Travis: Deploy to S3 rather than SourceForge This has the following advantages: -- It doesn't require checking a private SSH key into the repository. (With SourceForge, an SSH key is the "keys to the kingdom".) -- If the S3 key is compromised, it is very easy to revoke it and generate a new one. -- The S3 bucket is isolated, so even if it becomes compromised, then the damage that one could do is limited. -- It's much easier to manage files through S3's web interface than through SourceForge. -- The files are served via HTTPS. -- Travis fully supports S3 as a deployment target, so this simplifies .travis.yml somewhat.
DRC 9366cf0b 2016-10-20T01:01:27 Travis: GPG sign Linux binaries/source tarballs Since we're still deploying our Linux/macOS CI artifacts to a web server (specifically SourceForge Project Web Services) that doesn't support HTTPS, it's a good idea to sign them. But since the private key has to be checked into the repository, we use a different key for signing the pre-releases (per project policy, the private signing keys for our release binaries are never made available on any public server.)
DRC 13e6b151 2016-10-11T11:58:20 Win: Use YASM if it is in the PATH and NASM isn't Previously, simd/CMakeLists.txt was hard-coded to use NASM, and it was necessary to override the NASM variable in order to use YASM. This commit changes the behavior such that NASM is still preferred, but YASM will be used if it is in the PATH and NASM isn't available. This brings the actual behavior in line with the behavior described in BUILDING.md. Based on https://github.com/xpol/libjpeg-turbo/commit/b0799a1598782799d4876538eddca7ad8438d8a6 Closes #107
DRC 1ee329d6 2016-10-07T12:54:55 Travis: Fix deployment issue (2nd attempt)
DRC b47c5e73 2016-10-07T05:34:11 Travis: Fix deployment issue "Skipping a deployment with the script provider because this branch is not permitted"
DRC ce262eb5 2016-10-07T05:07:22 Fix AppVeyor build on non-master branches buildljt will clone the Git repository into the temp. directory, even if the repository is really a local sandbox, so we need to specify the branch.
DRC 27f817cd 2016-10-07T05:07:11 Travis: Use existing sandbox for official builds This eliminates the need to specify the remote repository and branch, and it prevents the code from being checked out twice.
DRC 0df2e218 2016-10-07T04:28:02 Add AppVeyor config for Windows pre-release builds
DRC 6d22430a 2016-10-05T14:36:46 Travis: use correct repo/branch for off. builds Pass the actual repository and branch that Travis is using into the builtljt script, so the official builds it generates will come from the same code base as the other tested builds.
DRC e9e3a2ed 2016-10-05T12:38:59 Travis CI: Use correct key for this repository
DRC 211c69f3 2016-10-02T09:13:23 Add Travis CI config for Un*x pre-release builds
DRC 1625253d 2016-10-04T13:41:48 Fix 32-bit non-SIMD FP regression tests - Introduce a new FLOATTEST value ("387") on Un*x systems that will compare the floating point DCT/IDCT algorithms against the expected results from the C algorithms when built using 32-bit code and -mfpmath=387. - Extend the Windows regression tests so that they work properly when building libjpeg-turbo with 32-bit code and without SIMD, using either Visual C++ (tested with 2008, 2010, 2015) or MinGW.
DRC a0047bde 2016-10-04T13:25:34 Fix broken build w/ Visual C++ < 2010 Regression introduced by dfefba77520ded5c5fd4864e76352a5f3eb23e74 (Windows doesn't always have stdint.h.)
DRC 7bfb22af 2016-09-26T17:59:14 Fix broken MIPS build Regression introduced by 9055fb408dcb585ce9392d395e16630d51002152 Fixes #104
DRC ac4a8995 2016-09-22T14:38:51 Fix UBSan warning in arithmetic decoder Very similar to the ones that were fixed in the Huffman decoders in 8e9cef2e6f5156c4b055a04a8f979b7291fc6b7a. These are innocuous. Refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1304567.
DRC dfefba77 2016-09-22T14:19:29 Fix broken build with NDK platforms < android-21 Regression introduced by a09ba29a55b9a43d346421210d94370065eeaf53 Fixes #103
DRC 4cf67f23 2016-09-22T14:14:05 Bump version to 1.5.2 to prepare for new commits
Roberto Civille Rodrigues 9407cf7f 2016-09-22T00:42:25 README.md: Fix typo Introduced in 17de51835735e319ada5ca139a64227423946a8a Closes #102
mayeut cb88e5da 2016-09-20T21:06:24 ARM64 NEON: Fix another ABI conformance issue Based on https://github.com/mayeut/libjpeg-turbo/commit/98a5a9dc899aa9265858a3cbe0a96289a31a1322 with wordsmithing by DRC. In the AArch64 ABI, as in many others, it's forbidden to read/store data below the stack pointer. Some SIMD functions were doing just that (stack pointer misuse) when trying to preserve callee-saved registers, and this resulted in those registers being restored with incorrect contents under certain circumstances. This patch fixes that behavior, and callee-saved registers are now stored above the stack pointer throughout the function call. The patch also removes register saving in places where it is unnecessary for this ABI, or it makes use of unused scratch regiters instead of callee-saved registers. Fixes #97. Closes #101. Refer also to https://bugzilla.redhat.com/show_bug.cgi?id=1368569
DRC e9d9c31f 2016-09-19T22:47:18 Build: Remove ARMv6 support from 'make iosdmg' The last iDevice to require ARMv6 was the iPhone 3G, which required iOS 4.2.1 or older. Our binaries have always required iOS 4.3 or newer, so I'm not sure if the ARMv6 fork of our binaries was ever useful to begin with. In any case, if it ever was useful, it no longer is. Fat binaries can still be generated with ARMv6 support by invoking {build_directory}/pkgscripts/makemacpkg manually.
DRC 077e5bb4 2016-09-08T21:49:02 Fix out-of-bounds write in partial decomp. feature Reported by Clang UBSan (refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1301252 for test image.) This appears to be a legitimate bug introduced by 3ab68cf563f6edc2608c085f5c8b2d5d5c61157e. Any component array, such as first_MCU_col and last_MCU_col, should always be able to accommodate MAX_COMPONENTS values. The aforementioned test image had 8 components, which was not enough to make the out-of-bounds write bust out of the jpeg_decomp_master struct (and fortunately the memory after last_MCU_col is an integer used as a boolean, so stomping on it will do nothing other than change the decoder state.) I crafted another special image that has 10 components (the maximum allowable), but that was apparently not enough to bust out of the allocated memory, either. Thus, it is posited that the security threat posed by this bug is either extremely minimal or non-existent.
DRC a1dd3568 2016-09-08T21:29:58 Silence additional UBSan warnings NOTE: The jdhuff.c/jdphuff.c warnings should have already been silenced by 8e9cef2e6f5156c4b055a04a8f979b7291fc6b7a, but apparently I need to be REALLY clear that I'm trying to do pointer arithmetic rather than dereference an array. Grrr... Refer to: https://bugzilla.mozilla.org/show_bug.cgi?id=1301250 https://bugzilla.mozilla.org/show_bug.cgi?id=1301256
DRC a09ba29a 2016-09-07T16:40:10 Fix unsigned int overflow in libjpeg memory mgr. When attempting to decode a malformed JPEG image (refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1295044) with dimensions 61472 x 32800, the maximum_space variable within the realize_virt_arrays() function will exceed the maximum value of a 32-bit integer and will wrap around. The memory manager subsequently fails with an "Insufficient memory" error (case 4, in alloc_large()), so this commit simply causes that error to be triggered earlier, before UBSan has a chance to complain. Note that this issue did not ever represent an exploitable security threat, because the POSIX-based memory manager that we use doesn't ever do anything meaningful with the value of maximum_space. jpeg_mem_available() simply sets avail_mem = maximum_space, so the subsequent behavior of the memory manager is the same regardless of whether maximum_space is correct or not. This commit simply removes a UBSan warning in order to make it easier to detect actual security issues.
DRC 8ce2c911 2016-08-01T11:22:24 TurboJPEG: Decomp. 4:2:2/4:4:0 JPEGs w/unusual SFs Normally, 4:2:2 JPEGs have horizontal x vertical luminance,chrominance sampling factors of 2x1,1x1, and 4:4:0 JPEGs have horizontal x vertical luminance,chrominance sampling factors of 1x2,1x1. However, it is technically legal to create 4:2:2 JPEGs with sampling factors of 2x2,1x2 and 4:4:0 JPEGs with sampling factors of 2x2,2x1, since the sums of the products of those sampling factors (2x2 + 1x2 + 1x2 and 2x2 + 2x1 + 2x1) are still <= 10. The libjpeg API correctly decodes such images, so the TurboJPEG API should as well. Fixes #92
DRC db044351 2016-07-14T13:36:47 Silence pedantic GCC6 code formatting warnings Apparently it's "misleading" to put two self-contained if statements on a single line. Who knew?
DRC 7723d7f7 2016-07-13T20:39:11 Use plain upsampling if merged isn't accelerated Currently, this only affects ARM, since it is the only platform that accelerates YCbCr-to-RGB conversion but not merged upsampling. Even if "plain" upsampling isn't accelerated, the combination of accelerated color conversion + unaccelerated plain upsampling is still faster than the unaccelerated merged upsampling algorithms. Closes #81
Kornel Lesiński 628c168c 2016-07-10T19:01:51 Implement h1v2 fancy upsampling This allows fancy upsampling to be used when decompressing 4:2:2 images that have been losslessly rotated or transposed. (docs and comments added by DRC) Based on https://github.com/pornel/libjpeg-turbo/commit/f63aca945debde07e7c6476a1f667b71728c3d44 Closes #89
DRC 1120ff29 2016-07-13T12:15:02 Fix AArch64 ABI conformance issue in SIMD code In the AArch64 ABI, the high (unused) DWORD of a 32-bit argument's register is undefined, so it was incorrect to use 64-bit instructions to transfer a JDIMENSION argument in the 64-bit NEON SIMD functions. The code worked thus far only because the existing compiler optimizers weren't smart enough to do anything else with the register in question, so the upper 32 bits happened to be all zeroes. The latest builds of Clang/LLVM have a smarter optimizer, and under certain circumstances, it will attempt to load-combine adjacent 32-bit integers from one of the libjpeg structures into a single 64-bit integer and pass that 64-bit integer as a 32-bit argument to one of the SIMD functions (which is allowed by the ABI, since the upper 32 bits of the 32-bit argument's register are undefined.) This caused the libjpeg-turbo regression tests to crash. This patch tries to use the Wn registers whenever possible. Otherwise, it uses a zero-extend instruction to avoid using the upper 32 bits of the 64-bit registers, which are not guaranteed to be valid for 32-bit arguments. Based on https://github.com/sebpop/libjpeg-turbo/commit/1fbae13021eb98f6fffdfaf8678fcdb00b0b04d9 Closes #91. Refer also to android-ndk/ndk#110 and https://llvm.org/bugs/show_bug.cgi?id=28393
DRC 1945ad96 2016-07-12T22:21:20 Don't install libturbojpeg.pc if TJPEG disabled
DRC 6e9d43e0 2016-07-06T16:58:28 Linux/PPC: Only enable AltiVec if CPU supports it This eliminates "illegal instruction" errors when running libjpeg-turbo under Linux on PowerPC chips that lack AltiVec support (e.g. the old 7XX/G3 models but also the newer e5500 series.)
DRC 9055fb40 2016-07-07T13:10:30 ARM/MIPS: Change the behavior of JSIMD_FORCE* The JSIMD_FORCE* environment variables previously meant "force the use of this instruction set if it is available but others are available as well", but that did nothing on ARM platforms, since there is only ever one instruction set available. Since the ARM and MIPS CPU feature detection code is less than bulletproof, and since there is only one SIMD instruction set (currently) supported on those platforms, it makes sense for the JSIMD_FORCE* environment variables on those platforms to actually force the use of the SIMD instruction set, thus bypassing the CPU feature detection code. This addresses a concern raised in #88 whereby parsing /proc/cpuinfo didn't work within a QEMU environment. This at least provides a workaround, allowing users to force-enable or force-disable SIMD instructions for ARM and MIPS builds of libjpeg-turbo.
DRC 9e6c6a14 2016-07-06T16:22:27 Bump version to 1.5.1 to prepare for new commits
DRC 3ff13e65 2016-05-31T22:53:17 1.5.0
DRC 1d50a8cd 2016-05-31T22:48:52 BUILDING.md: More NASM/YASM clarifications 28d1a1300c6be7fc8614ed827eb56cd97cf84e76 introduced the line "nasm.exe should be in your PATH". This commit corrects an oversight in 8f1c0a681cd34e8e80ba7b06f356d6080a7172c9 / e5091f2cf3b6ba747907012146df93df0d01ec85 whereby this line should have been extended to include yasm.exe.
DRC 123f7258 2016-05-24T10:23:56 Format copyright headers more consistently The IJG convention is to format copyright notices as: Copyright (C) YYYY, Owner. We try to maintain this convention for any code that is part of the libjpeg API library (with the exception of preserving the copyright notices from Cendio's code verbatim, since those predate libjpeg-turbo.) Note that the phrase "All Rights Reserved" is no longer necessary, since all Buenos Aires Convention signatories signed onto the Berne Convention in 2000. However, our convention is to retain this phrase for any files that have a self-contained copyright header but to leave it off of any files that refer to another file for conditions of distribution and use. For instance, all of the non-SIMD files in the libjpeg API library refer to README.ijg, and the copyright message in that file contains "All Rights Reserved", so it is unnecessary to add it to the individual files. The TurboJPEG code retains my preferred formatting convention for copyright notices, which is based on that of VirtualGL (where the TurboJPEG API originated.)
DRC e5091f2c 2016-05-28T18:19:45 Merge branch '1.4.x'
DRC 8f1c0a68 2016-05-28T18:08:22 BUILDING.txt: Clarify NASM build requirements The version requirements only apply to NASM (not YASM.) Also, 2.11.09 was never actually released (the first release containing the OS X fix is 2.12.)
DRC 68cf83db 2016-05-10T21:04:02 Don't allow opaque source/dest mgrs to be swapped Calling jpeg_stdio_dest() followed by jpeg_mem_dest(), or jpeg_mem_src() followed by jpeg_stdio_src(), is dangerous, because the existing opaque structure would not be big enough to accommodate the new source/dest manager. This issue was non-obvious to libjpeg-turbo consumers, since it was only documented in code comments. Furthermore, the issue could also occur if the source/dest manager was allocated by the calling program, but it was not allocated with enough space to accommodate the opaque stdio or memory source/dest manager structs. The safest thing to do is to throw an error if one of these functions is called when there is already a source/dest manager assigned to the object and it was allocated elsewhere. Closes #78, #79
DRC f06cc120 2016-05-10T19:36:34 Build: Add integer version macro to jconfig.h This makes it significantly easier to do conditional compilation based on the libjpeg-turbo version. Based on: https://github.com/hasinoff/libjpeg-turbo/commit/e6d5b3e50b8b07488cb7b4d26ab2061685bc6875 https://github.com/hasinoff/libjpeg-turbo/commit/1394a89ba6f3cd8abb556c1b65bac4a5f09760d0 Closes #80
DRC 5c064de1 2016-05-09T20:00:46 Build: Don't allow jpeg-7+ emul. w/o arith coding The jpeg-7/jpeg-8 APIs/ABIs require arithmetic coding, and the jpeg-8 API/ABI requires the memory source/destination manager, so this commit causes the build system to ignore --with-arith-enc/--without-arith-enc and --with-arith-dec/--without-arith-dec (and the equivalent CMake variables-- WITH_ARITH_ENC and WITH_ARITH_DEC) when v7/v8 API/ABI emulation is enabled. Furthermore, the CMake build system now ignores WITH_MEM_SRCDST whenever WITH_JPEG8 is specified (the autotools build system already did that.)
mattsarett 2e480fa2 2016-05-03T10:33:43 ARMv7 SIMD: Fix clang compatibility (Part 2) GCC does support UAL syntax (strbeq) if the ".syntax unified" directive is supplied. This directive is supported by all versions of GCC and clang going back to 2003, so it should not create any backward compatibility issues. Based on https://github.com/mattsarett/libjpeg-turbo/commit/1264349e2fa6f098178c37abfa7b059ad8b405a2 Closes #76
mattsarett 5e576386 2016-05-02T12:31:51 ARMv7 SIMD: Fix clang compatibility By design, clang only supports Unified Assembler Language (and not pre-UAL syntax): https://llvm.org/bugs/show_bug.cgi?id=23507 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/BABJIHGJ.html Thus, clang only supports the strbeq instruction and not streqb, but unfortunately some versions of GCC only support streqb. Go, go Gadget #ifdef... Based on https://github.com/mattsarett/libjpeg-turbo/commit/a82e63aac63f8fa3 95fa4caad4de6859623ee2e2 Closes #75
DRC 0d61e80a 2016-05-01T12:07:05 Merge branch '1.4.x'
DRC ee681aa3 2016-05-01T11:42:15 Fix CMake fallback BUILD var on non-U.S. machines If wmic.exe wasn't available, then CMakeLists.txt would call "cmd /C date /T" and parse the result in order to set the BUILD variable. However, the parser assumed that the date was in MM/DD/YYYY format, which is not generally the case unless the user's locale is U.S. English with the default region/language settings for that locale. This commit modifies CMakeLists.txt such that it uses the string(TIMESTAMP) function available in CMake 2.8.11 and later to set the BUILD variable, thus eliminating the need to use wmic.exe or any other platform-specific hack. This commit also modifies the build instructions to remove any reference to CMake 2.6 (which hasn't been supported by our build system since libjpeg-turbo 1.3.x.) Closes #74
DRC 346837ca 2016-04-25T19:08:47 Merge branch '1.4.x'
DRC eb7962a0 2016-04-25T18:16:46 CMakeLists.txt: Clarify that Un*x isn't supported At one time, it was possible to use CMake to build under Cygwin, but that hasn't worked since 1.4.1 (due to the Huffman codec changes that now require SIZEOF_SIZE_T to be defined for non-WIN32 platforms) and may have even been broken before that. Originally, we used the "date" command under MSYS in order to obtain the default build number, but that was rendered unnecessary by 5e3bb3e9 (v1.3 beta.) 9fe22dac (1.4 beta) further modified CMakeLists.txt so that the "date" command was only used on Cygwin, but for unexplained reasons, that commit also applied the (now vestigial) code to all non-WIN32 platforms. This prevented CMakeLists.txt from displaying an error if someone attempted to use the CMake build system on Un*x platforms, and that may have been behind the flurry of pull requests and issues-- including #21, #29, #37, #58, #73-- complaining that the CMake build system didn't work on Un*x platforms (although it was not until #73 that this bug came to light.) This commit removes all vestiges of Un*x support from the CMake build system and makes it clear that CMake cannot be used to build libjpeg-turbo on non-WIN32 platforms. It is our position that CMake will not be supported on non-WIN32 platforms until/unless the autotools build system is removed, and this will not happen without broad support from the community (including major O/S vendors.) If you are in favor of migrating the entire build system to CMake, then please make your voice heard by commenting on #56.
DRC 3c67d4f7 2016-04-20T11:27:42 Catch libjpeg errors in tjDecompressToYUV2() Even though tjDecompressToYUV2() is mostly just a wrapper for tjDecompressToYUVPlanes(), tjDecompressToYUV2() still calls jpeg_read_header(), so it needs to properly set up the libjpeg error handler prior to making this call. Otherwise, under very esoteric (and arguably incorrect) use cases, a program could call tjDecompressToYUV2() without first checking the JPEG header using tjDecompressHeader3(), and if the header was corrupt, then the libjpeg API would invoke my_error_exit(). my_error_exit() would in turn call longjmp() on the previous value of myerr->setjmp_buffer, which was probably set in a previous TurboJPEG function, such as tjInitDecompress(). Thus, when a libjpeg error was triggered within the body of tjDecompressToYUV2(), the PC would jump to the error handler of the previous TurboJPEG function, and this usually caused stack corruption in the calling program (because the signature and return type of the previous TurboJPEG function probably wasn't the same as that of tjDecompressToYUV2().)
kmx.io     mail     discord kmxgit v0.4.0