kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
DRC 7884e245 2016-10-07T04:51:29 Merge branch 'master' into dev
DRC 0df2e218 2016-10-07T04:28:02 Add AppVeyor config for Windows pre-release builds
DRC be908ac0 2016-10-05T14:42:35 Travis CI: Fixes to support AVX2 code -- Use trusty for SIMD builds. Ubuntu 12.04 is still using NASM 2.09.x, which isn't new enough to support AVX2. -- Add a special test for the SSE2 code path, since it is no longer the default.
DRC ed21f4bd 2016-10-05T14:41:14 Merge branch 'master' into dev
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 f34f2f5b 2016-10-05T13:36:35 Fix 'make dist'
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
DRC 6c365686 2016-09-20T18:09:15 Merge branch 'master' into dev
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 3924ebce 2016-07-13T16:03:36 AVX2: Perform additional checks for O/S support cpuid tells us whether the O/S uses extended state management via XSAVE/XRSTOR, but we have to call xgetbv to verify that it is using XSAVE/XRSTOR to manage the state of XMM/YMM registers.
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 3dcb85ee 2016-07-11T20:21:46 AVX2: Verify O/S support for AVX2 before enabling This fixes crashes that would occur when attempting to use libjpeg-turbo's AVX2 extensions on older O/S's (such as Windows XP or RHEL 5.) Even if the CPU supports AVX2, the O/S has to also support saving/restoring YMM registers when switching contexts.
DRC 1be87b62 2016-07-11T19:42:37 Reformat jsimdcpu[-64].asm to improve readability
DRC b331385e 2016-07-11T13:11:25 Merge branch 'master' into dev
DRC b2921f1b 2016-07-08T21:28:48 32-bit AVX2 implementation of integer quantization
DRC eaae2cdb 2016-07-08T13:56:30 64-bit AVX2 implementation of integer quantization
DRC a7c2f979 2016-07-08T20:10:24 AVX2: Avoid expensive AVX-SSE transitions Refer to https://software.intel.com/sites/default/files/m/d/4/1/d/8/11MC12_Avoiding_2BAVX-SSE_2BTransition_2BPenalties_2Brh_2Bfinal.pdf for more information. This eliminates all AVX-SSE transitions detected with the Intel SDE tool.
DRC e06ccbe3 2016-07-08T13:00:13 64-bit AVX2: Fix bug in IS_ALIGNED_AVX() macro 32 = 1 << 5, not 1 << 8
DRC 67de29b5 2016-07-07T22:04:25 32-bit AVX2 impl. of h2v2 & h2v1 merged upsampling
DRC c22e42e9 2016-07-07T20:36:15 Optimize 64-bit AVX2 h2v2 fancy upsampler Reduce register usage and eliminate unnecessary mov instructions
DRC 6d765524 2016-07-07T20:34:08 32-bit AVX2 impl. of h2v2 & h2v1 upsampling (Fancy & Plain)
DRC 421d34fd 2016-07-05T17:20:20 32-bit AVX2 impl. of YCC->RGB color conversion
DRC c6300ffe 2016-07-05T15:50:50 32-bit AVX2 impl. of h2v2 & h2v1 downsampling
DRC 6448a5e5 2016-07-05T16:21:10 32-bit AVX2 impl. of RGB->YCC/RGB->Gray color conv
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 7ee3ce9a 2016-07-05T16:19:26 Lay the groundwork for 32-bit AVX2 SIMD support
DRC b5426c52 2016-06-10T16:03:49 64-bit AVX2 SIMD: Restore instructive comments This commit adds back instructive comments in the image-space algorithms, similar to those in the SSE2 code. These comments make it easier to follow the flow of data through the algorithms.
DRC 621b29f5 2016-05-31T15:19:53 64-bit AVX2 impl. of h2v2 & h2v1 merged upsampling
DRC f1cbc328 2016-05-29T08:09:27 64-bit AVX2 impl. of h2v2 & h2v1 upsampling (Fancy & Plain)
DRC 72c837da 2016-05-29T06:54:56 64-bit AVX2 impl. of YCC->RGB color conversion
DRC 1c8a475c 2016-05-28T19:53:44 64-bit AVX2 impl. of h2v2 & h2v1 downsampling
DRC 8880e087 2016-05-28T19:15:18 64-bit AVX2 impl. of RGB->Gray color conversion
DRC 426d787c 2016-05-28T16:42:44 64-bit AVX2 impl. of RGB->YCC color conversion
DRC 2cf199cb 2016-05-20T10:45:32 Lay the groundwork for 64-bit AVX2 SIMD support
DRC 16b12189 2016-05-29T10:51:16 x86-64 SIMD: Optimize argument collection Expand collect_args/uncollect_args macros so that the number of arguments can be specified. This prevents unnecessary push and mov instructions. NOTE: On Windows, the push/pop of xmm6 and xmm7 had to be moved to the other end of the macro to ensure that rsp is aligned on a 16-byte boundary.
DRC 6cb27c31 2016-05-09T20:28:17 Bump version to 1.6 alpha1 (to prepare for new features)
DRC ff5685d5 2016-05-27T16:58:23 Reformat SSE/SSE2 SIMD code to improve readability
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().)
DRC 1959e28b 2016-04-21T10:22:36 Increase severity of tjDecompressToYUV2() bug desc Actually, what happened was that the longjmp() call within my_error_exit() acted 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 jumped 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.)
DRC dec79952 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 can call tjDecompressToYUV2() without first checking the JPEG header using tjDecompressHeader3(), and if the header is corrupt, tjDecompressToYUV2() will abort without triggering an error. Fixes #72
DRC 2628c562 2016-04-14T14:19:19 BUILDING.md: Fix "... OR ..." indentation again <sigh> GitHub doesn't render indented text the same as my local MarkDown viewer (MacDown), so it's necessary to indent "... OR ..." by 3 spaces so both will display it on the same indentation level as "Visual C++ 2005 or later" and "MinGW".
DRC 28d1a130 2016-04-14T14:12:46 BUILDING.md: Fix confusing Windows build reqs Indent "... OR ..." to make it clear that the choice is between Visual C++ and MinGW, not Visual C++ and MinGW + NASM. Move NASM to the top of the list to make that even more clear. Make it clear that nasm.exe should be in the PATH. Addresses concerns raised in #70
DRC 1a3aebd8 2016-03-31T10:02:44 Merge branch '1.4.x'
DRC 1e81b0c3 2016-03-31T09:49:49 cjpeg: Fix buf overrun caused by bad bin PPM input This extends the fix in 6709e4a0cfa44d4f54ee8ad05753d4aa9260cb91 to include binary PPM/PGM files, thus preventing a malformed binary PPM/PGM input file from triggering an overrun of the rescale array and potentially crashing cjpeg. Note that this issue affected only cjpeg and not the underlying libjpeg-turbo libraries, and thus it did not represent a security threat. Thanks to @hughdavenport for the discovery.
DRC b2817f52 2016-03-16T07:18:30 Merge branch '1.4.x'
DRC 6f241d4d 2016-03-16T07:10:35 Add version/build info to global string table This is a common practice in other infrastructure libraries, such as OpenSSL and libpng, because it makes it easy to examine an application binary and determine which version of the library the application was linked against. Closes #66
DRC 1385f8b2 2016-03-14T13:32:00 ChangeLog.md: Improve readability of plain text
DRC 742fb37d 2016-03-13T18:28:14 change.log: Refer users to ChangeLog.md change.log is included only to document the changes that we have merged from libjpeg.
DRC a839a7a9 2016-03-13T16:24:48 Markdown version of ChangeLog.txt This will make it easier to crib ChangeLog information into release notes, since both SourceForge and GitHub support MD.
DRC 3f56bd59 2016-03-13T12:36:06 Rename ChangeLog.txt ... in preparation for creating a MarkDown version (Git will not preserve history unless you rename the file prior to modifying it.)
DRC e5f280c4 2016-03-11T11:14:28 README.md: Link to BUILDING.md Addresses a concern expressed in #56 and #58.
DRC 4f581231 2016-03-09T17:23:45 BUILDING.md and README.md: Cosmetic tweaks
DRC 622d6678 2016-03-06T08:34:48 ChangeLog: "1.5 beta1" --> "1.4.90 (1.5 beta1)" (for consistency with other beta release headings)
DRC b3247c7d 2016-03-06T08:33:02 Merge branch '1.4.x'
DRC a572622d 2016-03-06T08:15:04 Ensure that default Huffman tables are initialized This prevents a malformed motion-JPEG frame (MJPEG frames lack Huffman tables) from causing the "fast path" of the Huffman decoder to read uninitialized memory. Essentially, this is doing the same thing for MJPEG frames as 43d8cf4d4572fa50a37cccadbe71b9bee37de55d did for regular images.
DRC 7cb8de4a 2016-03-02T09:53:11 Java: Fix parallel make with autotools Running 'make -j{jobs}' on a build that was configured with Java (--with-java) would previously cause an error: make: *** No rule to make target `TJExample.class', needed by `turbojpeg.jar'. It seems that parallel make doesn't understand that the files in $(JAVA_CLASSES) are all generated from the same invocation of javac, so it tries to parallelize the building of those files (which of course doesn't work.) This patch instead makes turbojpeg.jar depend on classnoinst.stamp. This effectively creates a synchronization fence, since that file is only created when all of the class files have been built. Fixes #62
DRC 056536f6 2016-02-29T17:21:02 Win/x64: Fix improper callee save of xmm8-xmm11 The x86-64 SIMD accelerations for Huffman encoding used incorrect stack math to save xmm8-xmm11 on Windows. This caused TJBench to always report 1 Mpixel/sec for the compression performance, and it likely would have caused other application issues as well.
DRC 7c202f76 2016-02-29T13:18:01 Bump TurboJPEG C API revision to 1.5 The changes relative to 1.4.x are only cosmetic (using const pointers) and should not affect API/ABI compatibility, but our practice is to synchronize the API revision with the most recent release that provides user-visible changes to the API.
DRC fa722636 2016-02-29T12:06:33 ChangeLog: Mention jpeg_crop_scanline() function
DRC 2354810a 2016-02-29T11:12:44 1.5 beta1
DRC 45c1e3a8 2016-02-25T17:15:21 Merge branch '1.4.x'
mayeut f57bae0d 2016-02-25T23:14:45 Fix memory leak when running tjunittest -yuv Closes #61
DRC 025c1f66 2016-02-22T10:00:19 Fix v7/v8-compatible build Broken by 3ab68cf563f6edc2608c085f5c8b2d5d5c61157e Fixes #60
DRC 3ab68cf5 2016-02-19T18:32:10 libjpeg API: Partial scanline decompression This, in combination with the existing jpeg_skip_scanlines() function, provides the ability to crop the image both horizontally and vertically while decompressing (certain restrictions apply-- see libjpeg.txt.) This also cleans up the documentation of the line skipping feature and removes the "strip decompression" feature from djpeg, since the new cropping feature is a superset of it. Refer to #34 for discussion. Closes #34
DRC 5f972324 2016-02-19T13:16:56 Build: Make the NASM autoconf variable persistent Previously, if a custom value of this variable was specified when running configure, then that value would be lost if configure was automatically re-run (as a result of changes to configure.ac, for instance.) As a bonus, the NASM variable is now also listed when running 'configure --help', so it is obvious how to override the default NASM command.
DRC f76c01d0 2016-02-19T10:56:13 Use consistent/modern code formatting for dbl ptrs
DRC d4be4236 2016-02-19T10:35:41 usage.txt: Restore accidentally deleted phrase It somehow got lost when merging the jpeg-9+ documentation changes.
kmx.io     mail     discord kmxgit v0.4.0