kc3-lang/libjpeg-turbo/ChangeLog.md

ChangeLog.md

Log

Author Commit Date CI Message
DRC 087c29e0 2018-10-22T10:05:18 Optimize Huffman encoding This commit improves the C and SSE2 Huffman encoding implementations in the following ways: - Avoid using xmm8-xmm15 in the x86-64 SSE2 implementation. There is no actual need to use those registers, and avoiding them produces a cleaner WIN64 function entry/exit-- as well as shorter code, since REX prefixes can be avoided (this is helpful on certain CPUs, such as Intel Atom, for which instruction fetch and decoding can be a bottleneck.) - Optimize register usage so that fewer REX prefixes and register-register moves are needed. - Use the bit counter to store the number of free bits in the bit buffer rather than the number of bits in the bit buffer. This changes the method for inserting a code into the bit buffer to: (put_buffer |= code << (free_bits -= code_size)); As a result: * Only one bit counter needs to stay in a register (we just keep it in cl.) * The bit buffer contents are already properly aligned to be written out (after a byte swap.) * Adjusting the free bits counter and checking if the bit buffer is full can be combined into a single operation. * We can wait to flush the bit buffer until the buffer is actually full and not just in danger of becoming full. Thus, eight bytes can be flushed at a time. - Speed is quite sensitive to the alignment of branch target labels, so insert some padding and remove branches from the flush code. (Flushing this way isn't actually faster when compared to using branches, but the branchless code doesn't need extra alignment and is thus smaller.) - Speculatively write out the bit buffer as a single 8-byte write, falling back to a byte-by-byte write only if there are any 0xFF bytes in the bit buffer that need to be encoded as 0xFF 0x00. - Use MMX registers for the 32-bit implementation (so the bit buffer can be 64 bits wide.) - Slightly reduce overall function code size. - Eliminate or combine a few SSE instructions. - Make some minor improvements to instruction scheduling. - Adjust flush_bits() in jchuff.c to handle cases in which the bit buffer has less than 7 free bits (apparently that couldn't happen before.) Based on: https://github.com/1camper/libjpeg-turbo/commit/947a09defa2ec848322b1bae050d1b57b316a32a https://github.com/1camper/libjpeg-turbo/commit/262ebb6b816fd8a49ff4d7185f6c5153dddde02f https://github.com/1camper/libjpeg-turbo/commit/6e9a091221bb244c8ba232a942650e94254ffcf0 See change log for performance claims. Closes #292
DRC 95f4d6ef 2019-10-24T02:13:23 Merge branch 'master' into dev
DRC 708f013f 2019-10-22T20:08:57 Win packaging: Fix 64-bit VC/GCC co-install issue
DRC 2ae2bd66 2019-10-04T16:05:11 Remove support for Apple's Java implementation (AKA "Java for OS X systems.") This implementation of Java 1.6 is long obsolete and not supported on any version of macOS past High Sierra. Oracle no longer provides a 32-bit JVM on macOS, so it is no longer necessary to provide a 32-bit version of the TurboJPEG Java wrapper on macOS.
DRC b4110b65 2019-09-04T18:58:12 Merge branch 'master' into dev
DRC ded5a504 2019-08-15T13:24:25 tjDecodeYUV*: Fix err if TJ inst used for prog dec If the TurboJPEG instance passed to tjDecodeYUV[Planes]() was previously used to decompress a progressive JPEG image, then we need to disable the progressive decompression parameters in the underlying libjpeg instance before calling jinit_master_decompress(). This commit also modifies the build system so that the "tjtest" target will test for this issue, and it corrects a previous oversight in the build system whereby tjbenchtest did not test progressive compression/decompression unless WITH_JAVA was true.
DRC 8ef53b10 2019-08-14T22:08:59 Merge branch 'master' into dev
DRC c0d0fe86 2019-08-14T22:08:44 ChangeLog.md: Wordsmithing
DRC a81a8c13 2019-08-14T13:17:11 SSE2 SIMD: Fix prog Huffman enc. error if Sl%16==0 (regression introduced by 5b177b3cab5cfb661256c1e74df160158ec6c34e) The SSE2 implementation of progressive Huffman encoding performed extraneous iterations when the scan length was a multiple of 16. Based on: https://github.com/rouault/libjpeg-turbo/commit/bb7f1ef98305da915e581b59bd0ec2ef7bdb8468 Fixes #335 Closes #367
DRC 7fbfe29c 2019-07-18T15:18:27 Merge branch 'master' into dev
DRC 2a9e3bd7 2019-07-11T15:30:04 TurboJPEG: Properly handle gigapixel images Prevent several integer overflow issues and subsequent segfaults that occurred when attempting to compress or decompress gigapixel images with the TurboJPEG API: - Modify tjBufSize(), tjBufSizeYUV2(), and tjPlaneSizeYUV() to avoid integer overflow when computing the return values and to return an error if such an overflow is unavoidable. - Modify tjunittest to validate the above. - Modify tjCompress2(), tjEncodeYUVPlanes(), tjDecompress2(), and tjDecodeYUVPlanes() to avoid integer overflow when computing the row pointers in the 64-bit TurboJPEG C API. - Modify TJBench (both C and Java versions) to avoid overflowing the size argument to malloc()/new and to fail gracefully if such an overflow is unavoidable. In general, this allows gigapixel images to be accommodated by the 64-bit TurboJPEG C API when using automatic JPEG buffer (re)allocation. Such images cannot currently be accommodated without automatic JPEG buffer (re)allocation, due to the fact that tjAlloc() accepts a 32-bit integer argument (oops.) Such images cannot be accommodated in the TurboJPEG Java API due to the fact that Java always uses a signed 32-bit integer as an array index. Fixes #361
Jonathan Wright 509c2680 2019-05-09T13:46:53 Use bias pattern for 4:4:0 (h1v2) fancy upsampling This commit modifies h1v2_fancy_upsample() so that it uses an ordered dither pattern, similar to that of h2v1_fancy_upsample(), rounding up or down the result for alternate pixels rather than always rounding down. This ensures that the decompression error pattern for a 4:4:0 JPEG image will be similar to the rotated decompression error pattern for a 4:2:2 JPEG image. Thus, the final result will be similar regardless of whether a 4:2:2 JPEG image is rotated or transposed before or after decompression. Closes #356
DRC c055c880 2019-05-09T20:36:51 Discontinue support for 32-bit iOS builds
DRC f36d5315 2019-04-23T14:54:23 Merge branch 'master' into dev
Chris Blume aa9db616 2019-04-15T17:55:47 x86 SIMD: Check for CPUID leaf 07H before using According to Intel's manual [1], "If a value entered for CPUID.EAX is higher than the maximum input value for basic or extended function for that processor then the data for the highest basic information leaf is returned." Right now, libjpeg-turbo doesn't first check that leaf 07H is supported before attempting to use it, so the ostensible AVX2 bit (Bit 05) of the CPUID result might actually be Bit 05 from a lower leaf. That bit might be set, even if the CPU doesn't support AVX2. This commit modifies the x86 and x86-64 SIMD feature detection code so that it first checks whether CPUID leaf 07H is supported before attempting to use it to check for AVX2 instruction support. DRC: This commit should fix https://bugzilla.mozilla.org/show_bug.cgi?id=1520760 However, I have not personally been able to reproduce that issue, despite using a Nehalem (pre-AVX2) CPU on which the maximum CPUID leaf has been limited via a BIOS setting. Closes #348 [1] "Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (2A, 2B, 2C & 2D): Instruction Set Reference, A-Z", https://software.intel.com/sites/default/files/managed/a4/60/325383-sdm-vol-2abcd.pdf, page 3-192.
DRC 8a0e35b2 2019-04-15T13:41:45 Merge branch 'master' into dev
DRC 2b05d47b 2019-04-15T13:38:15 ChangeLog.md: Document 33011754
DRC 3ca6dba9 2019-02-17T09:33:57 Merge branch 'master' into dev
DRC a4aa30d9 2019-02-13T22:03:31 ChangeLog.md: "floating-point"="floating point"
DRC 2f9e7c84 2019-01-31T21:24:13 Loongson MMI h2v1 and h2v2 merged upsampling Based on: https://github.com/zhanglixia-hf/libjpeg-turbo/commit/e8f5cee5aa83e2d1b0af3a7bd0aaa2391c930fb2
DRC 674343ab 2019-01-31T15:30:25 Merge branch 'master' into dev
DRC 1c2d3cfa 2019-01-30T12:43:45 MMI: Fix comp. perf. issue w/ unaligned image rows Using ldc1 with a non-64-bit-aligned memory location causes as much as a 10x slow-down in overall compression performance.
DRC 2d0b675a 2019-01-25T16:46:02 Build: Fix install of static build w/ VStudio IDE Unfortunately, this hack is necessary because: - install(TARGETS, ...) doesn't support the RENAME option. - We can't modify OUTPUT_NAME for the "-static" targets without breaking the regression tests. - ${CMAKE_CFG_INTDIR} doesn't seem to work properly in an install() command. Refer to #307
DRC 42d62bf1 2019-01-23T11:20:11 Merge branch 'master' into dev
DRC 1ee87a9e 2019-01-21T16:25:02 djpeg: Fix PPM output regression w/ color quant. Regression caused by aa7459050d7a50e1d8a99488902d41fbc118a50f Fix based on: https://github.com/sinic/libjpeg-turbo/commit/03fbacb8ebf1fffc3f2d2db26ddf4db8b1f6aa7b Closes #310
DRC 479501b0 2019-01-21T13:57:55 TurboJPEG: Decompress 4:4:4 JPEGs with unusual SFs Normally, 4:4:4 JPEGs have horizontal x vertical luminance & chrominance sampling factors of 1x1. However, it is technically legal to create 4:4:4 JPEGs with sampling factors of 2x1, 1x2, 3x1, or 1x3, since the sums of the products of those sampling factors are still <= 10. The libjpeg API correctly decodes such images, so the TurboJPEG API should as well. Fixes #323
DRC 12f3d0be 2019-01-01T21:52:21 Merge branch 'master' into dev
DRC 1ff90822 2019-01-01T21:08:27 TJBench: Fix FPE when decompressing 0-width JPEG Fixes #319
DRC f8cca819 2019-01-01T20:32:40 wrbmp.c: Don't allow quantization w/ non-RGB CS If cinfo->quantize_colors == 1, then jpeg_calc_output_dimensions() will set cinfo->output_components to 1, and if cinfo->out_color_space is not RGB (or extended RGB), hilarity will ensue. Fixes #305
DRC 3d9c64e9 2019-01-01T18:57:36 tjLoadImage(): Fix int overflow/segfault w/big BMP Fixes #304
DRC c868e41b 2019-01-01T14:26:48 Build: Fix regr. that nuked RPATH in Mac/iOS build Caused by 950580eb0c020598a4c6c8aa46c86e31062e1ddc. Since the code that sets CMAKE_INSTALL_RPATH now depends on ENABLE_SHARED, that code needed to be moved to after the point at which ENABLE_SHARED is defined.
DRC 2cc4f93c 2018-11-12T14:40:19 Merge branch 'master' into dev
DRC 950580eb 2018-11-12T11:22:07 Build: Fix install error with fully static build Closes #273
DRC d00d7d8c 2018-10-05T16:13:07 cjpeg: Fix OOB read caused by malformed 8-bit TGA ... in which one or more of the color indices is out of range for the number of palette entries. Fix partly borrowed from jpeg-9c. Fixes #295
DRC aaffc14f 2018-09-30T11:56:08 Clarify that Win7 SP0 crash was a regression
DRC d5f281b7 2018-09-28T15:46:35 SIMD: Fix c000001d exception on Win 7 w/o SP1 Apparently Windows 7 without SP1 has O/S support for XSAVE but not for YMM registers, and this exposed a bug in our usage of xgetbv. The test instruction will set ZF only if none of the bits match between the two operarands, so in effect, we were enabling AVX2 instructions if the O/S supported XSAVE and the CPU supported AVX2 but the O/S only supported XMM registers. This bug was not exposed on, for instance, Windows XP or RHEL 5 because those O/S's do not support XSAVE. Fixes #288
DRC 133e4af0 2018-09-04T16:56:22 Add x32 ABI support on Linux The x32 ABI is similar to the x86-64 ABI but uses 32-bit pointers. (Refer to https://sites.google.com/site/x32abi) Based on: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/8da8fc5213d87336d6c7200aaeeca925603e12cf https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/1e33dfea8042230e266b453f53d69a6e37b7f0de https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/24ffea78da0f18d0d467d16e02dfb903e6c0181e https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/dedcf76753c8913ef5c3c6e4ea329d29494b6065 https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/d04228a7b58b9aed5bcbec383630ec1a14a3c9ca https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/b4ad38316ae1899c8a00b6568bb0325d82edcd7a Closes #274
DRC 3bef88f6 2018-09-04T17:33:12 Fix MIPS DSPr2 build when using soft float ABI (for instance, when passing -msoft-float to the compiler) The instructions used by jsimd_quantize_float_dspr2() and jsimd_convsamp_float_dspr2() don't work with the soft float ABI, so disable those functions when soft float is enabled. Based on: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/272/commits/129a739bfabe1568d078eb2719691a76db128185 Closes #272
DRC 2260b66e 2018-08-31T12:55:33 jconfig.h: restore Autotools compatibility (regression introduced with the CMake-based Un*x build system) Refer to change log for more details. Based on: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/275/commits/d992d12bc7631c29ab4adc42a7c5b4273fe2d56e Closes #275
DRC a6289526 2018-07-24T18:36:51 Fix JPEG spec references per ISO/ITU-T suggestions - When referring to specific clauses, annexes, tables, and figures, a "timed reference" (a reference that includes the year) must be used in order to avoid confusion. - "CCITT" = "ITU-T" - Replace ambiguous "JPEG spec" with the specific document number.
Even Rouault 9ab569e6 2018-07-20T18:04:15 Fix int overflow when decompr. corrupt prog. JPEG No discernible performance regression Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9447 Credit to OSS Fuzz Closes #259
DRC 9c78a04d 2018-07-20T17:21:36 cjpeg: Fix OOB read caused by malformed 8-bit BMP ... in which one or more of the color indices is out of range for the number of palette entries. Fix partly borrowed from jpeg-9c. This commit also adopts Guido's JERR_PPM_OUTOFRANGE enum value in lieu of our project-specific JERR_PPM_TOOLARGE enum value. Fixes #258
DRC 6d8caa9f 2018-06-29T12:45:57 Build: Detect whether compiler supports DSPr2 This is basically the same test that was performed in acinclude.m4 in the old autotools-based build system. It was not ported to the CMake-based build system because I previously had no way of testing a non-DSPr2 build environment. Fixes #248
Darrell Walisser 398c1e9a 2018-06-16T18:31:35 Fix jpeg_skip_scanlines() segfault w/merged upsamp Fixes NULL pointer reference when decompressing 4:2:2 or 4:2:0 JPEG images with cinfo.do_fancy_upsampling = FALSE. Closes #244
DRC 26f10929 2018-06-24T17:31:15 Fix infinite loop in partial image decompression ... caused by using certain specific combinations of jpeg_skip_scanlines() and jpeg_read_scanlines() calls with progressive, vertically-subsampled JPEG images. Fixes #237
DRC 43e84cff 2018-06-12T20:27:00 tjLoadImage(): Fix FPE triggered by malformed BMP In rdbmp.c, it is necessary to guard against 32-bit overflow/wraparound when allocating the row buffer, because since BMP files have 32-bit width and height fields, the value of biWidth can be up to 4294967295. Specifically, if biWidth is 1073741824 and cinfo->input_components = 4, then the samplesperrow argument in alloc_sarray() would wrap around to 0, and a division by zero error would occur at line 458 in jmemmgr.c. If biWidth is set to a higher value, then samplesperrow would wrap around to a small number, which would likely cause a buffer overflow (this has not been tested or verified.)
DRC 696e754e 2018-06-12T18:49:37 TurboJPEG: Handle JERR_BMP*,JERR_PPM* error codes ... in tjLoadImage()/tjSaveImage(). These error codes require an add-on message table, and if it isn't initialized, then format_message() produces "Bogus message code XXXX" instead.
DRC 909a8cfc 2018-06-12T16:08:26 Fix CVE-2018-11813 Refer to change log for details. Fixes #242
DRC 2401e4d1 2018-04-26T18:01:52 TurboJPEG: Handle CMYK JPEGs w/ subsampled M, Y Arguably it doesn't make much sense for non-chroma components to be subsampled (which is why this type of image was overlooked in cd7c3e6672cce3779450c6dd10d0d70b0c2278b2-- I didn't realize it was a thing), but certain Adobe applications apparently generate these images. Fixes #236
DRC d66dc70d 2018-03-22T17:15:53 ChangeLog.md: bump revision to prepare for beta
DRC c0ca354e 2018-03-22T16:04:29 Label this release 2.0 instead of 1.6 This also pulls the formatting changes from 19c791cdac6df84418c66eb9d67cfa9703bc2461 into the TurboJPEG C API docs.
DRC 2e90ccac 2018-03-22T15:56:09 ChangeLog.md: clarification regarding AVX2
mayeut 5b177b3c 2018-03-22T11:36:43 C/SSE2 optimization of encode_mcu_AC_first() This commit adds C and SSE2 optimizations for the encode_mcu_AC_first() function used in progressive Huffman encoding. The image used for testing can be retrieved from this page: https://blog.cloudflare.com/doubling-the-speed-of-jpegtran All timings done on `Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz` clang version is `Apple LLVM version 9.0.0 (clang-900.0.39.2)` gcc-5 version is `gcc-5 (Homebrew GCC 5.5.0) 5.5.0` gcc-7 version is `gcc-7 (Homebrew GCC 7.2.0) 7.2.0` Here are the results in comparison to libjpeg-turbo@293263c using `time ./jpegtran -outfile /dev/null -progressive -optimise -copy none print_poster_0025.jpg` C clang x86_64: +19% gcc-5 x86_64: +80% gcc-7 x86_64: +57% clang i386: +5% gcc-5 i386: +59% gcc-7 i386: +51% SSE2 clang x86_64: +79% gcc-5 x86_64: +158% gcc-7 x86_64: +122% clang i386: +71% gcc-5 i386: +134% gcc-7 i386: +135% Discussion in libjpeg-turbo/libjpeg-turbo#46
DRC 84fbd4f1 2018-03-17T00:27:49 Merge branch 'master' into dev
Cameron Cawley c7430097 2018-03-06T22:10:14 Fix build with older MinGW releases Some MinGW implementations need stdint.h in order to define SIZE_MAX. Regression caused by a09ba29a55b9a43d346421210d94370065eeaf53 and not fully fixed by a0047bdea4d11dfeefb9ea797865b1a2ea0a665e. Closes #220
DRC 33ce0b5e 2018-03-01T10:38:17 Loongson MMI SIMD extensions Based on: https://github.com/zhuchen1911/libjpeg-turbo/commit/42aff4497bdaca3258279cafc74511e3c25454b8 Closes #158
DRC 367a8386 2018-02-26T19:41:59 Make SIMD syms private for x86[-64]/Mach-O builds ... if building with YASM. NASM doesn't currently support the necessary directives. Closes #212
mayeut b6909ab3 2018-02-24T00:02:27 Make SIMD symbols private for MIPS ELF builds Closes #210
DRC 9cdec16c 2018-02-23T13:58:24 32-bit AVX2 implementation of slow int inverse DCT
DRC 4e240795 2018-02-13T16:34:21 Merge branch 'master' into dev
DRC d4859558 2018-02-13T16:14:03 Fix dithering bug in merged 4:2:0/RGB565 algorithm d0 should always be used for the first row, and d1 should always be used for the second row. Addresses concerns raised in #95, #81.
DRC bd544e28 2017-12-16T09:34:28 Merge branch 'master' into dev
DRC 0e2bca07 2017-12-15T20:37:02 jdarith.c: Fix two signed integer overflows I guess I have to fix these, or Google Autofuzz is going to keep bugging me about them. Fixes #171 Fixes #197 Fixes #198
DRC afdd7999 2017-12-06T12:20:24 Merge branch 'master' into dev + acknowledge 1.5.3 release
DRC c308d434 2017-12-06T11:59:04 jpeg_crop_scanlines: Handle gray images w/ samp!=1 Since the sampling factor has no meaning for single-component images, the decompressor ignores it, and jpeg_crop_scanlines() should as well. Fixes #195
DRC 773040f9 2017-12-05T15:27:34 Fix lib state when skipping to end of 1-scan image If jpeg_skip_scanlines() is used to skip to the end of a single-scan image, then we need to change the library state such that subsequent calls to jpeg_consume_input() will return JPEG_REACHED_EOI rather than JPEG_SUSPENDED. (NOTE: not necessary for multi-scan images, since the scans are processed prior to any call to jpeg_skip_scanlines().) Unless I miss my guess, using jpeg_skip_scanlines() in this manner will prevent any markers at the end of the JPEG image from being read, but I don't think there is any way around that without actually reading the data, which would defeat the purpose of jpeg_skip_scanlines(). Fixes #194
DRC 8c40ac8a 2017-11-16T18:46:01 Add TurboJPEG C example and clean up Java example Also rename example.c --> example.txt and add a disclaimer to that file so people will stop trying to compile it.
DRC dc4b9002 2017-11-16T20:43:12 TurboJPEG: Add alpha offset array/method Also, set the red/green/blue offsets for TJPF_GRAY to -1 rather than 0. It was undefined behavior for an application to use those arrays/methods with TJPF_GRAY anyhow, and this makes it easier for applications to programmatically detect whether a given pixel format has red, green, and blue components.
DRC aa745905 2017-11-16T18:09:07 TurboJPEG C API: Add BMP/PPM load/save functions The main justification for this is to provide new libjpeg-turbo users with a quick & easy way of developing a complete JPEG compression/decompression program without requiring them to build libjpeg-turbo from source (which was necessary in order to use the project-private bmp API) or to use external libraries. These new functions build upon significant enhancements to rdbmp.c, wrbmp.c, rdppm.c, and wrppm.c which allow those engines to convert directly between the native pixel format of the file and a pixel format ("colorspace" in libjpeg parlance) specified by the calling program. rdbmp.c and wrbmp.c have also been modified such that the calling program can choose to read or write image rows in the native (bottom-up) order of the file format, thus eliminating the need to use an inversion array. tjLoadImage() and tjSaveImage() leverage these new underlying features in order to significantly improve upon the performance of the old bmp API. Because these new functions cannot work without the libjpeg-turbo colorspace extensions, the libjpeg-compatible code in turbojpeg.c has been removed. That code was only there to serve as an example of how to use the TurboJPEG API on top of libjpeg, but more specific, buildable examples now exist in the https://github.com/libjpeg-turbo/ijg repository.
DRC 4893e5d8 2017-11-17T19:00:53 Merge branch 'master' into dev
DRC 19b393b6 2017-11-17T18:45:08 TJExample: Fix array index OOB w/ 4:1:1 JPEG input
DRC 5fce2e94 2017-11-14T15:30:06 tjbench.exe: Fix decompression access violation The program crashed when a JPEG image was passed on the command line, because we were mixing our metaphors vis-a-vis malloc()/free() and tjAlloc()/tjFree() (malloc()/free() uses the tjbench.exe heap, whereas tjAlloc()/tjFree() uses the turbojpeg.dll heap.)
DRC 907dd683 2017-11-13T21:46:07 ChangeLog.md: buglet
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 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 7106ffe5 2017-09-02T04:20:03 Merge branch 'master' into dev
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 c0f3512d 2017-08-31T20:57:19 Merge branch 'master' into dev
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 e5c1613c 2017-07-07T15:15:19 x86: Fix "short jump is out of range" w/ NASM<2.04
DRC dadebcd7 2017-06-28T11:43:08 TurboJPEG: Add "copy none", progressive xform opts Allow progressive entropy coding to be enabled on a transform-by-transform basis, and implement a new transform option for disabling the copying of markers. Closes #153
DRC dedce66e 2017-06-28T15:30:41 Merge branch 'master' into dev
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 aba6ae59 2017-06-27T13:24:08 TurboJPEG: Opt. enable progressive entropy coding Fulfills part of the feature request in #153. Also paves the way for SIMD-accelerated progressive Huffman coding (refer to #46.)
DRC d4092f6b 2017-06-27T10:54:21 TurboJPEG: Improve error handling - Provide a new C API function and TJException method that allows calling programs to query the severity of a compression/decompression/ transform error. - Provide a new flag that instructs the library to immediately stop compressing/decompressing/transforming if a warning is encountered. Fixes #151
DRC b9ab64d8 2017-05-11T21:02:29 TurboJPEG: Thread-safe error message retrieval Introduce a new C API function (tjGetErrorStr2()) that can be used to retrieve compression/decompression/transform error messages in a thread-safe (i.e. instance-specific) manner. Retrieving error messages from global functions is still thread-unsafe. Addresses a concern expressed in #151.
DRC 2ac4e9d9 2017-06-26T21:58:32 Merge branch 'master' into dev
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 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 44b2399a 2017-01-19T15:18:57 libjpeg API: Support reading/writing ICC profiles This commit does the following: -- Merges the two glueware functions (read_icc_profile() and write_icc_profile()) from iccjpeg.c, which is contained in downstream projects such as LCMS, Ghostscript, Mozilla, etc. These functions were originally intended for inclusion in libjpeg, but Tom Lane left the IJG before that could be accomplished. Since then, programs and libraries that needed to embed/extract ICC profiles in JPEG files had to include their own local copy of iccjpeg.c, which is suboptimal. -- The new functions were prefixed with jpeg_ and split into separate files for the compressor and decompressor, per the existing libjpeg coding standards. -- jpeg_write_icc_profile() was made slightly more fault-tolerant. It will now trigger a libjpeg error if it is called before jpeg_start_compress() or if it is passed NULL arguments. -- jpeg_read_icc_profile() was made slightly more fault-tolerant. It will now trigger a libjpeg error if it is called before jpeg_read_header() or if it is passed NULL arguments. It will also now trigger libjpeg warnings if the ICC profile data is corrupt. -- The code comments have been wordsmithed. -- Note that the one-line setup_read_icc_profile() function was not included. Instead, libjpeg.txt now documents the need to call jpeg_save_markers(cinfo, JPEG_APP0 + 2, 0xFFFF) prior to calling jpeg_read_header(), if jpeg_read_icc_profile() is to be used. -- Adds documentation for the new functions to libjpeg.txt. -- Adds an -icc switch to cjpeg and jpegtran that allows those programs to embed an ICC profile in the JPEG files they generate. -- Adds an -icc switch to djpeg that allows that program to extract an ICC profile from a JPEG file while decompressing. -- Adds appropriate unit tests for all of the above. -- Bumps the SO_AGE of the libjpeg API library to indicate the presence of new API functions. Note that the licensing information was obtained from: https://github.com/mm2/Little-CMS/issues/37#issuecomment-66450180
DRC d34d2559 2017-01-19T19:05:21 Merge branch 'master' into dev
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 8a9b042b 2016-12-10T09:35:30 Merge branch 'master' into dev
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.
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 6abd3916 2016-11-15T08:47:43 Unified CMake-based build system See #56 for discussion. Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73 Obviates #82 See also: https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/ https://sourceforge.net/p/libjpeg-turbo/patches/5/
DRC 0ff7da71 2016-11-16T15:55:12 Advertise the new AVX2 SIMD extensions (our story so far ...)
kmx.io     mail     discord kmxgit v0.4.0