kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
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.
DRC e621dfc5 2016-02-19T10:35:09 More minor code formatting tweaks
DRC 9100b67a 2016-02-19T09:25:44 Clean up a couple of copyright messages
DRC bd49803f 2016-02-19T08:53:33 Use consistent/modern code formatting for pointers The convention used by libjpeg: type * variable; is not very common anymore, because it looks too much like multiplication. Some (particularly C++ programmers) prefer to tuck the pointer symbol against the type: type* variable; to emphasize that a pointer to a type is effectively a new type. However, this can also be confusing, since defining multiple variables on the same line would not work properly: type* variable1, variable2; /* Only variable1 is actually a pointer. */ This commit reformats the entirety of the libjpeg-turbo code base so that it uses the same code formatting convention for pointers that the TurboJPEG API code uses: type *variable1, *variable2; This seems to be the most common convention among C programmers, and it is the convention used by other codec libraries, such as libpng and libtiff.
DRC ae411288 2016-02-18T16:02:28 Reorder copyright messages in cjpeg/djpeg/jpegtran Place the authors in the following order: * libjpeg-turbo authors (2009-) in descending order of the date of their most recent contribution to the project, then in ascending order of the date of their first contribution to the project * Upstream authors in descending order of the date of the first inclusion of their code (this indicates that their code serves as the foundation of this code.) This also adds Siarhei to the author list, since he contributed ARM SIMD code both as a Nokia employee and more recently as an independent developer.
DRC 54e6b8e8 2016-02-18T15:16:17 Include some comments/doc tweaks from jpeg-9+
DRC 83aeb7b2 2016-02-17T20:05:44 Wordsmith GIF limitations in cjpeg.1/djpeg.1
Guido Vollbeding a560e4b4 2016-01-17T00:00:00 The Independent JPEG Group's JPEG software v9b
Guido Vollbeding fc11193e 2014-01-19T00:00:00 The Independent JPEG Group's JPEG software v9a
Guido Vollbeding e7f88aec 2013-01-13T00:00:00 The Independent JPEG Group's JPEG software v9
DRC aefd8b79 2016-02-14T17:20:30 Clean up pkgconfig dir when removing RPM & Mac pkg
DRC 18dcac46 2016-02-14T09:01:07 Fix compiler warning
DRC 03841e6e 2016-02-09T18:27:27 Win: Display effective C/LD flags in CMake output
DRC d123c125 2016-02-09T01:35:39 Java: Avoid OOM error when running 'make test' We need to garbage collect between iterations of the outside loop in bufSizeTest() in order to avoid exhausting the heap when running with Java 6 (which is still used on Linux to test the 32-bit version of libjpeg-turbo in automated builds.)
DRC 8632f1b2 2016-02-09T00:38:58 ARM64: Avoid tbl instruction on Cortex-A53/A57 Full-color compression speedups relative to previous commits: Cortex-A53 (Nexus 5X), Android, 64-bit: 0.91-3.0% (avg. 1.8%) Cortex-A57 (Nexus 5X), Android, 64-bit: -0.35-1.5% (avg. 0.65%)
DRC bba79789 2016-02-08T16:10:28 ChangeLog: Mention ARM64 Huffman & adj perf claims
DRC 28f00bf2 2016-02-08T15:15:11 Fix iOS/ARMv8 build Broken by 46ecffa324be43aab80f6160dc57d98b0a54a704. gas-preprocessor.pl and/or the clang assembler apparently don't like default values in macro arguments, and we need to use a separate const section for each function (because of our use of adr, also necessitated by the broken clang assembler.)
DRC ab80273b 2016-02-08T14:41:07 BUILDING.md: Update OS X Java information The Apple Java Developer Package is only necessary on OS X < 10.7. When building on Lion and later, the Oracle JDK is preferred.
DRC 53c635b8 2016-02-08T14:03:13 Fix 'make dist'; Include LICENSE.md in packages
DRC 46ecffa3 2016-02-07T22:05:56 ARM64: Avoid LD3/ST3 at run time, not compile time ... and only if ThunderX is detected. This can be easily expanded later on to include other CPUs that are known to suffer from slow LD3/ST3, but it doesn't make sense to disable LD3/ST3 for all non-Android Linux platforms just because ThunderX is slow.
DRC 219470d6 2016-02-07T20:36:02 ARM64 NEON SIMD implementation of Huffman encoding Full-color compression speedups relative to previous commits: Cortex-A53 (Nexus 5X), Android, 64-bit: 1.1-13% (avg. 6.0%) Cortex-A57 (Nexus 5X), Android, 64-bit: 0.0-22% (avg. 6.3%) Refer to #47 and #50 for discussion Closes #50 Note that this commit introduces a similar /proc/cpuinfo parser to that of the ARM32 implementation. It is used to specifically check whether the code is running on Cavium ThunderX and, if so, disable the ARM64 SIMD Huffman routines (which slow performance by an average of 8% on that CPU.) Based on: https://github.com/mayeut/libjpeg-turbo/commit/a8c282e5e5ac10a715d6d6a9ab22121982b485f6
DRC 15aaa7f7 2016-02-07T17:39:33 ARM SIMD: Comment tweaks
DRC 45bbe06e 2016-02-06T16:04:29 Un*x: Enable testing cross-compiled builds Don't include the all: target as a dependency of the tests when cross-compiling, and ensure that the files generated by the tests are removed, even if they were created read-only (or if the tests are being run on a different type of system that doesn't correctly interpret the file permissions.) This allows one to easily build the code on one machine and run 'make test' on another.
DRC 2d623257 2016-02-06T16:03:57 Fix Visual C++ compiler warnings Somehow this got reverted with aa769febf25c64f115c2a237516b0c7d65f651cd. Oops.
DRC f9134384 2016-02-06T14:09:20 Win: Enable testing cross-compiled builds When cross-compiling, CMakeLists.txt now generates the CTest script using relative paths, so that CTest can more easily be executed on a different machine from the build machine. Furthermore, Windows builds are now tested using md5cmp, just like on Linux, rather than a CMake script. This prevents issues with differing CMake locations between the build and test machines. This also removes some trailing spaces from the md5cmp code and improves the readability of the test code in CMakeLists.txt.
DRC ce0dd949 2016-02-06T12:18:44 Fix MinGW build jinclude.h can't be safely included multiple times, so instead of including it in the shared (broken-out) headers, it should instead be included by the source files that include one or more of those headers.
DRC 8ff67fdb 2016-02-06T12:17:40 Update MinGW Linux build recipe
DRC 55a18d40 2016-02-04T18:52:23 Merge branch '1.4.x'
DRC 2d56acb8 2016-02-04T18:47:07 Merge branch '1.3.x' into 1.4.x
DRC c454c595 2016-02-04T18:46:13 Merge branch '1.2.x' into 1.3.x
DRC 0463f7c9 2016-02-04T18:34:38 Prevent overread when decoding malformed JPEG The accelerated Huffman decoder was previously invoked if there were > 128 bytes in the input buffer. However, it is possible to construct a JPEG image with Huffman blocks > 430 bytes in length (http://stackoverflow.com/questions/2734678/jpeg-calculating-max-size). While such images are pathological and could never be created by a JPEG compressor, it is conceivable that an attacker could use such an artifially-constructed image to trigger an input buffer overrun in the libjpeg-turbo decompressor and thus gain access to some of the data on the calling program's heap. This patch simply increases the minimum buffer size for the accelerated Huffman decoder to 512 bytes, which should (hopefully) accommodate any possible input. This addresses a major issue (LJT-01-005) identified in a security audit by Cure53.
DRC 04dd34c1 2016-02-04T10:59:21 Guard against wrap-around in alloc functions Because of the exposed nature of the libjpeg API, alloc_small() and alloc_large() can potentially be called by external code. If an application were to call either of those functions with sizeofobject > SIZE_MAX - ALIGN_SIZE - 1, then the math in round_up_pow2() would wrap around to zero, causing that function to return a small value. That value would likely not exceed MAX_ALLOC_CHUNK, so the subsequent size checks in alloc_small() and alloc_large() would not catch the error. A similar problem could occur in 32-bit builds if alloc_sarray() were called with samplesperrow > SIZE_MAX - (2 * ALIGN_SIZE / sizeof(JSAMPLE)) - 1 This patch simply ensures that the size argument to the alloc_*() functions will never exceed MAX_ALLOC_CHUNK (1 billion). If it did, then subsequent size checks would eventually catch that error, so we are instead catching the error before round_up_pow2() is called. This addresses a minor concern (LJT-01-001) expressed in a security audit by Cure53.
DRC 3ee3d879 2016-02-04T10:58:10 Fix Visual C++ compiler warnings
DRC 6c8a71ef 2016-02-04T10:51:22 rdppm.c: formatting tweaks
DRC 271b0bf0 2016-02-04T10:08:38 jmemmgr.c: formatting tweaks
DRC 6e053525 2016-02-04T09:20:41 TurboJPEG: Avoid dangling pointers This addresses a minor concern (LJT-01-002) expressed in a security audit by Cure53. _tjInitCompress() and _tjInitDecompress() call (respectively) jpeg_mem_dest_tj() and jpeg_mem_src_tj() with a pointer to a dummy buffer, in order to set up the destination/source manager. The dummy buffer should never be used, but it's still better to make it static so that the pointer in the destination/source manager always points to a valid region of memory.
DRC fe11699d 2016-02-03T14:02:13 Adjust performance claims Document the latest benchmarks on the Nexus 5X and change the "2-4x" overall claim to "2-6x". The peak performance on x86 platforms was already closer to 5x, and the addition of SIMD-accelerated Huffman encoding gave it that extra push over the cliff.
DRC cf888486 2016-02-02T23:17:06 Use consistent formatting in ARM NEON SIMD code There aren't really any best practices to follow here. I tried as best as I could to adopt a standard that would ease any future maintenance burdens. The basic tenets of that standard are: * Assembly instructions always start on Column 5, and operands always start on Column 21, except: - The instruction and operand can be indented (usually by 2 spaces) to indicate a separate instruction stream. - If the instruction is within an enclosing .if block in a macro, it should always be indented relative to the .if block. * Comments are placed with an eye toward readability. There are always at least 2 spaces between the end of a line of code and the associated in-line comment. Where it made sense, I tried to line up the comments in blocks, and some were shifted right to avoid overlap with neighboring instruction lines. Not an exact science. * Assembler directives and macros use 2-space indenting rules. .if blocks are indented relative to the macro, and code within the .if blocks is indented relative to the .if directive. * No extraneous spaces between operands. Lining up the operands vertically did not really improve readability-- personally, I think it made it worse, since my eye would tend to lose its place in the uniform columns of characters. Also, code with a lot of vertical alignment is really hard to maintain, since changing one line could necessitate changing a bunch of other lines to avoid spoiling the alignment. * No extraneous spaces in #defines or other directives. In general, the only extraneous spaces (other than indenting spaces) are between: - Instructions and operands - Operands and in-line comments This standard should be more or less in keeping with other formatting standards used within the project.
DRC cb49bb00 2016-02-02T23:10:27 Opt. ARM64 SIMD decompr. for in-order pipelines Decompression speedup relative to libjpeg-turbo 1.4.2 (ISLOW IDCT): 48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 60-113% (avg. 86%) Cortex-A53 (Nexus 5X), Android, 64-bit: 6.8-27% (avg. 14%) Cortex-A57 (Nexus 5X), Android, 64-bit: 2.0-14% (avg. 6.8%) Decompression speedup relative to libjpeg-turbo 1.4.2 (IFAST IDCT): 48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 51-98% (avg. 75%) Minimal speedup (1-5%) observed on iPhone 5S (Cortex-A7) NOTE: This commit avoids the st3 instruction for non-Android and non-Apple builds, which may cause a performance regression against libjpeg-turbo 1.4.x on ARM64 systems that are running plain Linux. Since ThunderX is the only platform known to suffer from slow ld3 and st3 instructions, it is probably better to check for the CPU type at run time and disable ld3/st3 only if ThunderX is detected. This commit also enables the use of ld3 on Android platforms, which should be a safe bet, at least for now. This speeds up compression on the afore-mentioned Nexus Cortex-A53 by 5.5-19% (avg. 12%) and on the Nexus Cortex-A57 by 1.2-14% (avg. 6.3%), relative to the previous commits. This commit also removes unnecessary macros. Refer to #52 for discussion. Closes #52. Based on: https://github.com/mayeut/libjpeg-turbo/commit/6bad905034e6e73b33ebf07a74a6b72f58319f62 https://github.com/mayeut/libjpeg-turbo/commit/488dd7bf1726e2f6af6e9294ccf77b729fec1f20 https://github.com/mayeut/libjpeg-turbo/commit/4f4d057c1fb31d643536e6effb46a5946e15c465 https://github.com/mayeut/libjpeg-turbo/commit/d3198afc43450989a4fc63d2dcbe3272c8a0a3c1
DRC cbfa696f 2016-02-01T11:28:55 Update Android build instr. for ARMv8, PIE, etc. * Include information on how to do a 64-bit ARMv8 build with the latest NDK * Suggest -fPIE and -pie as default CFLAGS (required for android-16 and later. * Remove -fstrict-aliasing flag (-Wall already includes it)
DRC f5cd71c5 2016-02-01T11:19:06 Merge branch '1.4.x'
DRC da047e8b 2016-02-01T11:17:41 Makefile.am: formatting tweak
DRC 6c3fc97b 2016-02-01T11:12:22 Update Android build instr. for ARMv8, PIE, etc. * Include information on how to do a 64-bit ARMv8 build with the latest NDK * Suggest -fPIE and -pie as default CFLAGS (required for android-16 and later. * Remove -fstrict-aliasing flag (-Wall already includes it)
DRC 31280613 2016-02-01T11:03:39 TJBench: Fix segfault on Android For whatever reason, the "write" global variable in tjbench.c was overriding the linkage with the write() system function. This may have affected other platforms as well but was not known to.
DRC 8af3f8a9 2016-01-18T16:40:07 Provide pkg-config (.pc) scripts This allows a project to use PKG_CHECK_MODULES() in its configure.ac file to easily check for the presence of libjpeg-turbo and modify the compiler/linker flags accordingly. Note that if a project relies solely on pkg-config to check for libjpeg-turbo, then it will not be possible to build that project using libjpeg or an earlier version of libjpeg-turbo. Closes #53 Based on: https://github.com/cberner/libjpeg-turbo/commit/496713871939b550d00005b4042420da41641a0a
DRC d38b4f21 2016-01-16T01:53:32 Optimize ARM64 SIMD code for Cavium ThunderX Per @ssvb: ThunderX is an ARM64 chip that dedicates most of its transistor real estate to providing 48 cores, so each core is not as fast as a result. Each core is dual-issue & in-order for scalar instructions and has only a single-issue half-width NEON unit, so the peak throughput is one 128-bit instruction per 2 cycles. So careful instruction scheduling is important. Furthermore, ThunderX has an extremely slow implementation of ld2 and ld3, so this commit implements the equivalent of those instructions using ld1. Compression speedup relative to libjpeg-turbo 1.4.2: 48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 58-85% (avg. 74%) relative to jpeg-6b: 1.75-2.14x (avg. 1.95x) Refer to #49 and #51 for discussion. Closes #51. This commit also wordsmiths the ChangeLog entry (the ARMv8 SIMD implementation is "complete" only for compression-- it still lacks some decompression algorithms, as does the ARMv7 implementation.) Based on: https://github.com/mayeut/libjpeg-turbo/commit/9405b5fd031558113bdfeae193a2b14baa589a75 which is based on: https://github.com/libjpeg-turbo/libjpeg-turbo/commit/f561944ff70adef65bb36212913bd28e6a2926d6 https://github.com/libjpeg-turbo/libjpeg-turbo/commit/962c8ab21feb3d7fc2a7a1ec8d26f6b985bbb86f
DRC e8aa5fa9 2016-01-15T13:15:54 Add JSIMD_NOHUFFENC environment variable for ARM Useful in regression/performance testing
DRC ec6941f7 2016-01-15T09:29:11 Complete the ARM64 NEON SIMD implementation This adds 64-bit NEON coverage for all of the algorithms that are covered by the 32-bit NEON implementation, except for h2v1 (4:2:2) fancy upsampling (used when decompressing 4:2:2 JPEG images.) It also adds 64-bit NEON SIMD coverage for: * slow integer forward DCT (compressor) * h2v2 (4:2:0) downsampling (compressor) * h2v1 (4:2:2) downsampling (compressor) which are not covered in the 32-bit implementation. Compression speedups relative to libjpeg-turbo 1.4.2: Apple A7 (iPhone 5S), iOS, 64-bit: 113-150% (reported) 48-core ThunderX (RunAbove ARM Cloud), Linux, 64-bit: 2.1-33% (avg. 15%) Refer to #44 and #49 for discussion This commit also removes the unnecessary if (simd_support & JSIMD_ARM_NEON) statements from the jsimd* algorithm functions. Since the jsimd_can*() functions check for the existence of NEON, the corresponding algorithm functions will never be called if NEON isn't available. Based on: https://github.com/mayeut/libjpeg-turbo/commit/dcd9d84f10fae192c0e3935818dc289bca9c3e29 https://github.com/mayeut/libjpeg-turbo/commit/b0d87b811f37bd560083deea8c6e7d704e5cd944 https://github.com/mayeut/libjpeg-turbo/commit/70cd5c8a493a67f4d54dd2067ae6dedb65d95389 https://github.com/mayeut/libjpeg-turbo/commit/3e58d9a064648503c57ec2650ee79880f749a52b https://github.com/mayeut/libjpeg-turbo/commit/837b19542f53fa81af83e6ba002d559877aaf597 https://github.com/mayeut/libjpeg-turbo/commit/73dc43ccc870c2e10ba893e9764b8e48d6836585 https://github.com/mayeut/libjpeg-turbo/commit/a82b71a261b4c0213f558baf4bc745f1c27356d8 https://github.com/mayeut/libjpeg-turbo/commit/c1b1188c2106d6ea7b76644b6023b57edeb602e1 https://github.com/mayeut/libjpeg-turbo/commit/305c89284e1bb222b34fbc7261f697a0cc452a41 https://github.com/mayeut/libjpeg-turbo/commit/7f443f99950b4d7d442b9b879648eca5273209bd https://github.com/mayeut/libjpeg-turbo/commit/4c2b53b77da5a20e30e2aadaeddb0efbfe24e06d Unified version with fixes: https://github.com/mayeut/libjpeg-turbo/commit/1004a3cd05870612a194b410efeaa1b4da76d246
DRC 499c470b 2016-01-13T03:13:20 ARM32 NEON SIMD implementation of Huffman encoding Full-color compression speedups relative to libjpeg-turbo 1.4.2: 800 MHz ARM Cortex-A9, iOS, 32-bit: 26-44% (avg. 32%) Refer to #42 and #47 for discussion. This commit also removes the unnecessary if (simd_support & JSIMD_ARM_NEON) statements from the jsimd* algorithm functions. Since the jsimd_can*() functions check for the existence of NEON, the corresponding algorithm functions will never be called if NEON isn't available. Removing those if statements improved performance across the board by a couple of percent. Based on: https://github.com/mayeut/libjpeg-turbo/commit/fc023c880ce1d6c908fb78ccc25f5d5fd910ccc5
DRC 9c8cee8c 2016-01-13T13:01:45 tjbench: Further tweaks to -nowrite feature * Do not compute compression error if -nowrite is specified * Adjust formatting of -nowrite usage description
DRC 4e356a92 2016-01-13T12:25:03 BUILDING.md: Restore autotools processing instr. Partially reverts 54014d9c2a41905b7b766057af6728834da64b59. When building from a git sandbox, as opposed to from an official source tarball, it is still necessary to run autoreconf. Closes #48
DRC 93eaa37a 2015-06-20T16:27:51 Update build instructions for new autoconf, GitHub The Linux build machine has been upgraded to autoconf 2.69, automake 1.15, m4 1.4.17, and libtool 2.4.6, so it is no longer necessary to recommend running autoreconf prior to building the source, if one is building from an official source tarball (as opposed to from a git sandbox.) Also, there is no SVN repository anymore (oops.)
DRC f3a8684c 2016-01-07T00:19:43 SSE2 SIMD implementation of Huffman encoding Full-color compression speedups relative to libjpeg-turbo 1.4.2: 2.8 GHz Intel Xeon W3530, Linux, 64-bit: 2.2-18% (avg. 9.5%) 2.8 GHz Intel Xeon W3530, Linux, 32-bit: 10-25% (avg. 17%) 2.3 GHz AMD A10-4600M APU, Linux, 64-bit: 4.9-17% (avg. 11%) 2.3 GHz AMD A10-4600M APU, Linux, 32-bit: 8.8-19% (avg. 15%) 3.0 GHz Intel Core i7, OS X, 64-bit: 3.5-16% (avg. 10%) 3.0 GHz Intel Core i7, OS X, 32-bit: 4.8-14% (avg. 11%) 2.6 GHz AMD Athlon 64 X2 5050e: Performance-neutral (give or take a few percent) Full-color compression speedups relative to IPP: 2.8 GHz Intel Xeon W3530, Linux, 64-bit: 4.8-34% (avg. 19%) 2.8 GHz Intel Xeon W3530, Linux, 32-bit: -19%-7.0% (avg. -7.0%) Refer to #42 for discussion. Numerous other approaches were attempted, but this one proved to be the most performant across all platforms. This commit also fixes #3 (works around, really-- the clang-compiled version of jchuff.c still performs 20% worse than its GCC-compiled counterpart, but that code is now bypassed by the new SSE2 Huffman algorithm.) Based on: https://github.com/mayeut/libjpeg-turbo/commit/2cb4d41330e1edc4469f6b97ba73b73abfbeb02f https://github.com/mayeut/libjpeg-turbo/commit/36c94e050d117912adbff9fbcc6fe307df240168
DRC eb59b6e7 2016-01-11T22:27:38 Add -nowrite arg to TJBench to improve consistency Prevents any images from being written to disk, thus making the performance of the benchmark as CPU-bound as possible.
DRC 368cd52d 2016-01-11T22:03:16 Allow JSIMD_FORCENONE=1 env to disable x86-64 SIMD Traditionally, the x86-64 code did not call init_simd() because it had no need to (only SSE2 was supported.) However, having the ability to disable SIMD at run time is a useful testing tool, and all of the other SIMD implementations have this ability.
DRC e7f14185 2016-01-06T19:25:28 1.4.3
DRC 2111c5ac 2016-01-06T19:24:55 Merge branch '1.4.x'
DRC 5a3b4fed 2016-01-06T19:17:54 Regression: Allow co-install of 32-bit/64-bit RPMs Fix a regression introduced in 1.4.1 that prevented 32-bit and 64-bit libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora distributions. This was due to the addition of the SIZEOF_SIZE_T macro in jconfig.h, which allows the Huffman codec to determine the word size at compile time. Since that macro differs between 32-bit and 64-bit builds, this caused a conflict between the i386 and x86_64 RPMs (any differing files, other than executables, are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.) Since the macro is used only internally, it has been moved into jconfigint.h.
DRC 5f2cbbd0 2016-01-06T14:02:27 Fix iOS ARM64 build broken by removal of .arch The unnecessary .arch directive was removed from the ARM64 SIMD code in d70a5c12fcb72443483456a2cc8dd18a4c238618, thus allowing clang's integrated assembler to assemble the code on Linux systems. However, this broke the detection mechanism in acinclude.m4 that tells the build system whether it needs to use gas-preprocessor.pl. Since one of the primary motivators for using gas-preprocessor.pl with ARM64 builds is the lack of .req/.unreq directives in Apple's implementation of clang, acinclude.m4 now checks whether .req/.unreq can be properly assembled and uses gas-preprocessor.pl if not. Closes #33.
DRC fbe5007f 2015-12-19T14:29:46 Merge branch '1.4.x'
DRC 71e971fb 2015-12-19T14:18:21 Build: Use FILEPATH type for NASM CMake variable This causes cmake-gui to to display the proper file chooser dialog (as opposed to the directory chooser.) Fixes #40
DRC 6fa5ebdc 2015-12-17T10:41:51 cjpeg: Adjust claims RE: image quality settings Quality values > 95 are not useless. They just may not provide as good of a size vs. perceptual quality tradeoff as lower quality values. This also displays the default quality value in the cjpeg usage. Closes #39
DRC d70a5c12 2015-12-14T16:59:43 Remove unnecessary .arch directive in ARM64 code This directive was preventing the code from assembling using the integrated assembler in clang. Fixes #33
DRC aa769feb 2015-10-15T02:25:00 Fix compiler warnings under Visual C++ A few of these are long-standing, but most were exposed when switching from INT32 to JLONG.
DRC d65e768b 2015-10-14T22:26:25 Fix additional issues reported by UB sanitizers Most of these involved overrunning the signed 32-bit JLONG type whenever building libjpeg-turbo with a 32-bit compiler. These issues are not believed to represent actual security threats, but eliminating them makes it easier to detect such threats should they arise in the future.
DRC 1e32fe31 2015-10-14T17:32:39 Replace INT32 with a new internal datatype (JLONG) These days, INT32 is a commonly-defined datatype in system headers. We cannot eliminate the definition of that datatype from jmorecfg.h, since the INT32 typedef has technically been part of the libjpeg API since version 5 (1994.) However, using INT32 internally is risky, because the inclusion of a particular header (Xmd.h, for instance) could change the definition of INT32 from long to int on 64-bit platforms and thus change the internal behavior of libjpeg-turbo in unexpected ways (for instance, failing to correctly set __INT32_IS_ACTUALLY_LONG to match the INT32 typedef-- perhaps as a result of including the wrong version of jpeglib.h-- could cause libjpeg-turbo to produce incorrect results.) The library has always been built in environments in which INT32 is effectively long (on Windows, long is always 32-bit, so effectively it's the same as int), so it makes sense to turn INT32 into an explicitly long datatype. This ensures that libjpeg-turbo will always behave consistently, regardless of the headers included at compile time. Addresses a concern expressed in #26.
DRC 250c8877 2015-10-13T13:37:32 ChangeLog: acknowledge existence of 1.4.2
DRC e42032ba 2015-10-10T10:56:58 README.md: create link for jcstest.c
DRC 17de5183 2015-10-10T10:34:55 Markdown versions of README, LICENSE, BUILDING
DRC 7e3acc0e 2015-10-10T10:25:46 Rename README, LICENSE, BUILDING text files The IJG README file has been renamed to README.ijg, in order to avoid confusion (many people were assuming that that was our project's README file and weren't reading README-turbo.txt) and to lay the groundwork for markdown versions of the libjpeg-turbo README and build instructions.
DRC ac85335c 2015-10-09T20:03:59 Merge branch '1.4.x'
DRC bf04316e 2015-10-09T20:02:31 Comment formatting tweaks
DRC d8da49ef 2015-09-21T13:45:45 Fix 'make dist'
DRC 30ebafda 2015-09-21T13:43:36 1.4.2
DRC 60efb896 2015-09-21T13:13:44 Merge branch '1.4.x'
DRC 8e9cef2e 2015-09-21T12:57:41 Fix various issues reported by the UB sanitizers Most of these involved left shifting a negative number, which is technically undefined (although every modern compiler I'm aware of will implement this by treating the signed integer as a 2's complement unsigned integer-- the LEFT_SHIFT() macro just makes this behavior explicit in order to shut up ubsan.) This also fixes a couple of non-issues in the entropy codecs, whereby the sanitizer reported an out-of-bounds index in the 4th argument of jpeg_make_d_derived_tbl(). In those cases, the index was actually out of bounds (caused by a malformed JPEG image), but jpeg_make_d_derived_tbl() would have caught the error and aborted prior to actually using the invalid address. Here again, the fix was to make our intentions explicit so as to shut up ubsan.
DRC 870b4f28 2015-09-16T23:26:13 Fix ChangeLog numbering biffed by previous merge
DRC b961f0bf 2015-09-16T23:16:38 Merge branch '1.4.x'
James Cowgill 54792ba3 2015-09-16T23:05:46 Fix MIPS DSPr2 4:2:0 upsample bug w/ small images The DSPr2 code was errantly comparing the residual (t9, width & 0xF) with the end pointer (t4, out + width) instead of the width directly (a1). This would give the wrong results with any image whose output width was less than 16. The other small changes (ulw to lw and removal of the nop) are just some easy optimizations around this code. This issue caused a buffer overrun and subsequent segfault on images whose scaled output height was 1 pixel and whose scaled output width was < 16 pixels. Note that the "plain" (non-fancy and non-merged) upsample routine, which was affected by this bug, is normally not used except when decompressing a non-YCbCr JPEG image, but it is also used when decompressing a single-row image (because the other upsampling algorithms require at least two rows.) Closes #16.
Chandler Carruth 498d9bc9 2015-09-15T11:57:03 Fix x86-64 ABI conformance issue in SIMD code (descriptions cribbed by DRC from discussion in #20) In the x86-64 ABI, the high (unused) DWORD of a 32-bit argument's register is undefined, so it was incorrect to use a 64-bit mov instruction to transfer a JDIMENSION argument in the 64-bit SSE2 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-- for the past 6 years, on every x86-64 compiler previously known to mankind. The bleeding-edge Clang/LLVM compiler has 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. Also enhance the documentation of JDIMENSION to explain that its size is significant to the implementation of the SIMD code. Closes #20. Refer also to http://crbug.com/532214.
DRC b4922b42 2015-09-08T19:02:18 Merge branch '1.4.x'
DRC 465a9fe0 2015-09-08T18:59:37 Add file that explains the libjpeg-turbo licenses Previously this information was found in a page on libjpeg-turbo.org, but there was still some confusion, because README-turbo.txt wasn't clear as to which license applied to what.
DRC 00d82c42 2015-08-29T18:15:25 Merge branch '1.4.x'
DRC b5a55e6d 2015-08-29T18:05:43 Fix negative shift with IFAST FDCT and qual=100 With certain images, compressing using quality=100 and the fast integer forward DCT will cause the divisor passed to compute_reciprocal() to be 1. In those cases, the library already disables the SIMD quantization algorithm to avoid 16-bit overflow. However, compute_reciprocal() doesn't properly handle the divisor==1 case, so we need to use special values in that case so that the C quantization algorithm will behave like an identity function.
James Cowgill f62dbccf 2015-08-15T13:30:14 Fix build error when compiling MIPS SIMD w/ -mfpxx When compiled with -mfpxx (which is now the default on Debian), there are some restrictions on the use of odd-numbered FP registers. More details about FPXX can be found here: https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking This commit simply changes all uses of FP registers to an even-numbered equivalent like this: f0 -> f0 f1 -> f2 f2 -> f4 ... f8 -> f16 This commit should have no observable effect except that the MIPS assembly will now compile with -mfpxx. Closes #11
DRC b6576319 2015-08-26T20:31:13 Merge branch '1.4.x'
DRC 58ae401e 2015-08-26T20:29:36 Eliminate cppcheck false positive in turbojpeg.c
DRC 333f3cf7 2015-08-15T17:04:58 Fix 'make dist'
DRC 73befdb1 2015-08-14T11:48:05 Merge branch '1.4.x'
Frank Bossen 6709e4a0 2014-12-29T19:42:20 Check range of integer values in PPM text file Add checks to ensure values are within the specified range. Fixes mozilla/mozjpeg#141, closes #8
Frank Bossen 82923eb9 2014-12-29T18:38:36 Check image size when reading targa file Throw an error when image width or height is 0. Fixes mozilla/mozjpeg#140, closes #7.
DRC a3ef34c6 2015-08-13T11:09:05 Fix cjpeg segfault when Windows BMP width/height<0 rdbmp.c used the ambiguous INT32 datatype, which is sometimes typedef'ed to long. Windows bitmap headers use 32-bit signed integers for the width and height, because height can sometimes be negative (this indicates a top-down bitmap.) If biWidth or biHeight was negative and INT32 was a 64-bit long, then biWidth and biHeight were read as a positive integer > INT32_MAX, which failed the test in line 385: if (biWidth <= 0 || biHeight <= 0) ERREXIT(cinfo, JERR_BMP_EMPTY); This commit refactors rdbmp.c so that it uses the datatypes specified by Microsoft for the Windows BMP header. This closes #9 and also provides a better solution for mozilla/mozjpeg#153.
DRC 6fa14b37 2015-08-13T20:06:03 Declare source buffers in TurboJPEG C API as const This reassures the caller that the buffers will not be modified and also allows read-only buffers to be passed to the functions. Partially reverts 3947a19f25fc8186d3812dbcf8e70baea36ef652.
DRC ce4ff407 2015-08-13T18:09:20 Merge branch '1.4.x'
DRC b1682fb7 2015-08-13T18:05:32 Tabs to spaces in turbojpeg.h This was a formatting regression in 1.4.x introduced when the new TurboJPEG functions were added.
DRC b2db23c4 2015-08-13T16:51:08 Merge pull request #10 from pornel/const Declare inbuffer arg in jpeg_mem_src() to be const This reassures the caller that the buffer will not be modified and also allows read-only buffers to be passed to the function.
kmx.io     mail     discord kmxgit v0.4.0