kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
DRC d6d6ac73 2022-12-16T14:13:52 Win: Add jpeg16* functions to DLL module def files (oversight from previous commit)
DRC 2241434e 2022-12-15T12:20:50 16-bit lossless JPEG support
DRC ad4e2ad8 2022-12-07T15:57:15 CONTRIBUTING.md: Include lossless JPEG in policy
DRC 80352340 2022-12-07T14:11:37 Merge branch 'main' into dev
DRC dc4a93fa 2022-12-07T13:37:16 jpegtran: Fix FPE w/ -drop & -trim on corrupt JPEG requant_comp() in transupp.c, a function that supports the jpegtran -drop option, borrows code from the C quantization function in order to re-quantize the coefficients from the dropped image. However, the function does not guard against the possibility that a corrupt source image could inject quantization table values equal to 0, thus causing a divide-by-zero error. Since this error affected only jpegtran and not any of the libraries (the tjTransform() function in the TurboJPEG API does not expose the image drop feature), it did not represent a security risk. In fact, this commit does not change the output of jpegtran when attempting to transform the aforementioned corrupt source image. It merely eliminates the floating point exception. Like most issues of this type, however, eliminating the error prevents it from hiding legitimate security issues that may later be introduced. Fixes #635 Fixes #636
DRC 5da86f74 2022-12-07T09:45:33 ChangeLog.md: List CVE ID fixed by 9120a247
DRC 7bb5cb56 2022-12-07T09:39:03 ChangeLog.md: List CVE ID fixed by f35fd27e
DRC 0f047a57 2022-11-30T18:45:50 Merge branch 'main' into dev
DRC 7f2eb09d 2022-11-30T18:16:14 BUILDING.md: Add Arm64 iOS sim build instructions Unfortunately, iOS builds cannot be used with the iOS simulator on Macs with Apple silicon CPUs. Even more unfortunately, universal binaries can only have one slice for each CPU architecture, so it would not be possible to add a dedicated Arm64 iOS simulator slice to the existing libjpeg-turbo iOS binaries. (It would be necessary to release a separate package solely for the iOS simulator.) Because the Arm Neon SIMD extensions for libjpeg-turbo now use compiler intrinsics when building with Xcode, it is easy to build libjpeg-turbo from source when targeting Arm64-based Apple platforms. Thus, for the moment, I have chosen to document how to avoid the pothole rather than to fill it in.
DRC e2a98701 2022-11-30T11:06:37 turbojpeg.c: Fix build if !C_LOSSLESS_SUPPORTED
DRC 73ca9712 2022-11-30T11:03:43 Merge branch 'main' into dev
DRC 403cfad6 2022-11-30T10:43:29 djpeg.c: Fix build if !SAVE_MARKERS_SUPPORTED
DRC c4105ba7 2022-11-30T10:40:48 turbojpeg.c: Fix build if !C_PROGRESSIVE_SUPPORTED
DRC e7a248eb 2022-11-29T01:08:27 Merge branch 'main' into dev
DRC 45cd2ded 2022-11-28T21:02:42 12-bit: Prevent RGB-to-YCC table overrun/underrun cjpeg relies on the various file I/O modules to range-limit the input samples, but no range limiting is performed by the jpeg_write_scanlines() function itself. With 8-bit samples, that isn't a problem, because sample values > MAXJSAMPLE will overflow the data type and wrap around to 0. With 12-bit samples, however, it is possible to pass sample values < 0 or > 4095 to jpeg_write_scanlines(), which would cause the RGB-to-YCbCr color converter to underflow or overflow the RGB-to-YCbCr conversion tables. That issue has existed in libjpeg all along. This commit mitigates the issue by masking off all but the lowest 12 bits of each 12-bit input sample prior to using the input sample value to index the RGB-to-YCbCr conversion tables. Fixes #633
DRC 8b9bc4b9 2022-11-23T16:26:42 jconfig.h: Restore BITS_IN_JSAMPLE macro Because of e8b40f3c2ba187ba95c13c3e8ce21c8534256df7, we now support multiple data precisions in the same libjpeg API library, so BITS_IN_JSAMPLE is no longer used to specify the data precision at build time. However, some downstream software expects the macro to be defined. Since 12-bit data precision is an opt-in feature that requires explicitly calling 12-bit-specific libjpeg API functions and using 12-bit-specific data types, the unmodified portion of the libjpeg API still behaves as if it were built for 8-bit precision, and JSAMPLE is still literally an 8-bit data type. Thus, it is correct to externally define BITS_IN_JSAMPLE to 8 in jconfig.h. Since the build system also uses BITS_IN_JSAMPLE internally to build both 8-bit and 12-bit versions of relevant modules, the definition of BITS_IN_JSAMPLE in jconfig.h is now guarded by #ifndef BITS_IN_JSAMPLE. (Hopefully that doesn't cause any problems.) Fixes #632
DRC 4afa4d3e 2022-11-23T15:53:30 jconfig.h: Restore MEM_SRCDST_SUPPORTED macro That macro has been defined in jconfig.h since libjpeg-turbo 1.3.x, so it is possible that some downstream software conditions the use of the jpeg_mem_*() functions on whether MEM_SRCDST_SUPPORTED is defined or JPEG_LIB_VERSION >= 80 (as libjpeg-turbo 2.1.x and prior did internally.)
DRC 140a1ea3 2022-11-22T10:37:19 tjEncodeYUVPlanes(): Ignore TJFLAG_LOSSLESS TJFLAG_LOSSLESS is irrelevant to planar YUV encoding, and setting the flag caused tjEncode*() to fail with "Invalid lossless parameters" because tjEncodeYUVPlanes() passes a JPEG quality value of -1 to setCompDefaults(). This commit modifies setCompDefaults() so that it takes no action related to the jpegQual parameter unless jpegQual >= 0.
DRC 382563a5 2022-11-21T22:46:30 Build: Add missing tjbenchtest -arithmetic tests ... if WITH_JAVA=0. (Oversight from 6002720c37ec724dc20971ec77d73547a0feed9f)
DRC 98ff1fd1 2022-11-21T20:57:39 TurboJPEG: Add lossless JPEG detection capability Add a new TurboJPEG C API function (tjDecompressHeader4()) and Java API method (TJDecompressor.getFlags()) that return the bitwise OR of any flags that are relevant to the JPEG image being decompressed (currently TJFLAG_PROGRESSIVE, TJFLAG_ARITHMETIC, TJFLAG_LOSSLESS, and their Java equivalents.) This allows a calling program to determine whether the image being decompressed is a lossless JPEG image, which means that the decompression scaling feature will not be available and that a full-sized destination buffer should be allocated. More specifically, this fixes a buffer overrun in TJBench, TJExample, and the decompress* fuzz targets that occurred when attempting (in vain) to decompress a lossless JPEG image with decompression scaling enabled.
DRC b85b028d 2022-11-17T11:32:11 OSS-Fuzz: Fix argument error in cjpeg12 target Smoothing can only be used with 4:2:0 subsampling.
DRC db9dd93d 2022-11-17T11:31:29 Lossless: Fix innocuous UBSan warnings
DRC 07129256 2022-11-16T17:44:43 OSS-Fuzz: Add fuzz target for lossless JPEG
DRC 1a31176e 2022-11-21T22:42:46 Merge branch 'main' into dev
DRC 74d5b168 2022-11-21T22:41:46 Build: Update tjtest target dependencies
DRC 25ccad99 2022-11-16T15:57:25 TurboJPEG: 8-bit lossless JPEG support
DRC 3fb10c35 2022-11-16T12:18:45 Merge branch 'ijg.lossless' into dev Lossless: Accommodate LJT colorspace/SIMD exts In libjpeg-turbo, grayscale_convert() and null_convert() aren't the only lossless color conversion algorithms. We can also losslessly convert RGB to and from any of the extended RGB colorspaces, and some platforms have SIMD-accelerated null color conversion. This commit also disallows RGB565 output in lossless mode, and it moves the IsExtRGB() macro from cdjpeg.h to jpegint.h and repurposes it to make jinit_color_converter() and jinit_color_deconverter() more readable.
DRC af618ffe 2022-11-08T15:01:18 Clean up the lossless JPEG feature - Rename jpeg_simple_lossless() to jpeg_enable_lossless() and modify the function so that it stores the lossless parameters directly in the Ss and Al fields of jpeg_compress_struct rather than using a scan script. - Move the cjpeg -lossless switch into "Switches for advanced users". - Document the libjpeg API and run-time features that are unavailable in lossless mode, and ensure that all parameters, functions, and switches related to unavailable features are ignored or generate errors in lossless mode. - Defer any action that depends on whether lossless mode is enabled until jpeg_start_compress()/jpeg_start_decompress() is called. - Document the purpose of the point transform value. - "Codec" stands for coder/decoder, so it is a bit awkward to say "lossless compression codec" and "lossless decompression codec". Use "lossless compressor" and "lossless decompressor" instead. - Restore backward API/ABI compatibility with libjpeg v6b: * Move the new 'lossless' field from the exposed jpeg_compress_struct and jpeg_decompress_struct structures into the opaque jpeg_comp_master and jpeg_decomp_master structures, and allocate the master structures in the body of jpeg_create_compress() and jpeg_create_decompress(). * Remove the new 'process' field from jpeg_compress_struct and jpeg_decompress_struct and replace it with the old 'progressive_mode' field and the new 'lossless' field. * Remove the new 'data_unit' field from jpeg_compress_struct and jpeg_decompress_struct and replace it with a locally-computed data unit variable. * Restore the names of macros and fields that refer to DCT blocks, and document that they have a different meaning in lossless mode. (Most of them aren't very meaningful in lossless mode anyhow.) * Remove the new alloc_darray() method from jpeg_memory_mgr and replace it with an internal macro that wraps the alloc_sarray() method. * Move the JDIFF* data types from jpeglib.h and jmorecfg.h into jpegint.h. * Remove the new 'codec' field from jpeg_compress_struct and jpeg_decompress_struct and instead reuse the existing internal coefficient control, forward/inverse DCT, and entropy encoding/decoding structures for lossless compression/decompression. * Repurpose existing error codes rather than introducing new ones. (The new JERR_BAD_RESTART and JWRN_MUST_DOWNSCALE codes remain, although JWRN_MUST_DOWNSCALE will probably be removed in libjpeg-turbo, since we have a different way of handling multiple data precisions.) - Automatically enable lossless mode when a scan script with parameters that are only valid for lossless mode is detected, and document the use of scan scripts to generate lossless JPEG images. - Move the sequential and shared Huffman routines back into jchuff.c and jdhuff.c, and document that those routines are shared with jclhuff.c and jdlhuff.c as well as with jcphuff.c and jdphuff.c. - Move MAX_DIFF_BITS from jchuff.h into jclhuff.c, the only place where it is used. - Move the predictor and scaler code into jclossls.c and jdlossls.c. - Streamline register usage in the [un]differencers (inspired by similar optimizations in the color [de]converters.) - Restructure the logic in a few places to reduce duplicated code. - Ensure that all lossless-specific code is guarded by C_LOSSLESS_SUPPORTED or D_LOSSLESS_SUPPORTED and that the library can be built successfully if either or both of those macros is undefined. - Remove all short forms of external names introduced by the lossless JPEG patch. (These will not be needed by libjpeg-turbo, so there is no use cleaning them up.) - Various wordsmithing, formatting, and punctuation tweaks - Eliminate various compiler warnings.
DRC 918ace63 2022-11-16T10:36:57 example.c: Fix compiler warning
DRC 766910e8 2022-11-16T01:03:15 Merge branch 'ijg.lossless' into dev Fix segfault when decomp lossless JPEG w/ restarts The predict_process_restart() method in jpeg_lossless_decompressor was unset, because we now use the start_pass() method in jpeg_inverse_dct instead. Thus, a segfault occurred when attempting to decompress a lossless JPEG that contained restart markers.
DRC b56e8b28 2022-11-08T15:01:18 Clean up the lossless JPEG feature - Rename jpeg_simple_lossless() to jpeg_enable_lossless() and modify the function so that it stores the lossless parameters directly in the Ss and Al fields of jpeg_compress_struct rather than using a scan script. - Move the cjpeg -lossless switch into "Switches for advanced users". - Document the libjpeg API and run-time features that are unavailable in lossless mode, and ensure that all parameters, functions, and switches related to unavailable features are ignored or generate errors in lossless mode. - Defer any action that depends on whether lossless mode is enabled until jpeg_start_compress()/jpeg_start_decompress() is called. - Document the purpose of the point transform value. - "Codec" stands for coder/decoder, so it is a bit awkward to say "lossless compression codec" and "lossless decompression codec". Use "lossless compressor" and "lossless decompressor" instead. - Restore backward API/ABI compatibility with libjpeg v6b: * Move the new 'lossless' field from the exposed jpeg_compress_struct and jpeg_decompress_struct structures into the opaque jpeg_comp_master and jpeg_decomp_master structures, and allocate the master structures in the body of jpeg_create_compress() and jpeg_create_decompress(). * Remove the new 'process' field from jpeg_compress_struct and jpeg_decompress_struct and replace it with the old 'progressive_mode' field and the new 'lossless' field. * Remove the new 'data_unit' field from jpeg_compress_struct and jpeg_decompress_struct and replace it with a locally-computed data unit variable. * Restore the names of macros and fields that refer to DCT blocks, and document that they have a different meaning in lossless mode. (Most of them aren't very meaningful in lossless mode anyhow.) * Remove the new alloc_darray() method from jpeg_memory_mgr and replace it with an internal macro that wraps the alloc_sarray() method. * Move the JDIFF* data types from jpeglib.h and jmorecfg.h into jpegint.h. * Remove the new 'codec' field from jpeg_compress_struct and jpeg_decompress_struct and instead reuse the existing internal coefficient control, forward/inverse DCT, and entropy encoding/decoding structures for lossless compression/decompression. * Repurpose existing error codes rather than introducing new ones. (The new JERR_BAD_RESTART and JWRN_MUST_DOWNSCALE codes remain, although JWRN_MUST_DOWNSCALE will probably be removed in libjpeg-turbo, since we have a different way of handling multiple data precisions.) - Automatically enable lossless mode when a scan script with parameters that are only valid for lossless mode is detected, and document the use of scan scripts to generate lossless JPEG images. - Move the sequential and shared Huffman routines back into jchuff.c and jdhuff.c, and document that those routines are shared with jclhuff.c and jdlhuff.c as well as with jcphuff.c and jdphuff.c. - Move MAX_DIFF_BITS from jchuff.h into jclhuff.c, the only place where it is used. - Move the predictor and scaler code into jclossls.c and jdlossls.c. - Streamline register usage in the [un]differencers (inspired by similar optimizations in the color [de]converters.) - Restructure the logic in a few places to reduce duplicated code. - Ensure that all lossless-specific code is guarded by C_LOSSLESS_SUPPORTED or D_LOSSLESS_SUPPORTED and that the library can be built successfully if either or both of those macros is undefined. - Remove all short forms of external names introduced by the lossless JPEG patch. (These will not be needed by libjpeg-turbo, so there is no use cleaning them up.) - Various wordsmithing, formatting, and punctuation tweaks - Eliminate various compiler warnings.
DRC 6002720c 2022-11-15T23:10:35 TurboJPEG: Opt. enable arithmetic entropy coding
DRC bc086c44 2022-11-15T23:38:47 Merge branch 'main' into dev
DRC eb1fd4ad 2022-11-15T23:38:19 Build: Fix typo in tjtest target
DRC ed73fdc9 2022-11-15T21:28:01 Merge branch 'main' into dev
Erin Melucci 37dd973b 2022-11-02T09:33:55 Win: Use wchar_t for copyright string in RC files llvm-rc doesn't like the copyright symbol in the LegalCopyright string. Possible solutions: 1. Replace the copyright symbol with "(C)". 2. Prefix the string literal with L, thus making it a wide character string. 3. Pass -c65001 to the resource compiler to enable the UTF-8 code page. Option 2 is the least disruptive, since it doesn't change the behavior of the official builds or require any build system modifications. Closes #627
DRC 78a36f6d 2022-11-15T17:01:17 Fix buffer overrun in 12-bit prog Huffman encoder Regression introduced by 16bd984557fa2c490be0b9665e2ea0d4274528a8 and 5b177b3cab5cfb661256c1e74df160158ec6c34e The pre-computed absolute values used in encode_mcu_AC_first() and encode_mcu_AC_refine() were stored in a JCOEF (signed short) array. When attempting to losslessly transform a specially-crafted malformed 12-bit JPEG image with a coefficient value of -32768 into a progressive 12-bit JPEG image, the progressive Huffman encoder attempted to store the absolute value of -32768 in the JCOEF array, thus overflowing the 16-bit signed data type. Therefore, at this point in the code: https://github.com/libjpeg-turbo/libjpeg-turbo/blob/8c5e78ce292c1642057102eac42f12ab57964293/jcphuff.c#L889 the absolute value was read as -32768, which caused the test at https://github.com/libjpeg-turbo/libjpeg-turbo/blob/8c5e78ce292c1642057102eac42f12ab57964293/jcphuff.c#L896 to fail, falling through to https://github.com/libjpeg-turbo/libjpeg-turbo/blob/8c5e78ce292c1642057102eac42f12ab57964293/jcphuff.c#L908 with an overly large value of r (46) that, when shifted left four places, incremented, and passed to emit_symbol(), exceeded the maximum index (255) for the derived code tables. Fortunately, the buffer overrun was fully contained within phuff_entropy_encoder, so the issue did not generate a segfault or other user-visible errant behavior, but it did cause a UBSan failure that was detected by OSS-Fuzz. This commit introduces an unsigned JCOEF (UJCOEF) data type and uses it to store the absolute values of DCT coefficients computed by the AC_first_prepare() and AC_refine_prepare() methods. Note that the changes to the Arm Neon progressive Huffman encoder extensions cause signed 16-bit instructions to be replaced with equivalent unsigned 16-bit instructions, so the changes should be performance-neutral. Based on: https://github.com/mayeut/libjpeg-turbo/commit/bbf61c0382c4f8bd1f1cfc666467581496c2fb7c Closes #628
DRC aa3dd0bd 2022-11-15T15:41:07 TurboJPEG: Nix unneeded setDecodeDefaults ret val The return value was inherited from setDecompDefaults() in 34dca052271f4a75b3c0f7b11a2c5024159628d4, but it was never needed.
DRC 1926ab41 2022-11-14T16:31:41 ChangeLog.md: Multi-precision feature wordsmithing - Because of b5a9ef64ea299423b7fb46c47f4a70697a442dd4, "by default" is no longer applicable. (12-bit-per-component JPEG support is now part of the core libjpeg-turbo functionality and cannot be disabled.) - Change awkward "can be used to enable the creation of" to less awkward "can be used to create".
DRC 99866007 2022-11-14T16:20:46 jclhuff.c: Fix innocuous UBSan left shift warning This applies the progressive Huffman encoder fixes from aa769febf25c64f115c2a237516b0c7d65f651cd and d65e768b2e802c2a182203f5644904cfcd7e5240 to the new lossless mode Huffman encoder.
DRC 8fc93565 2022-11-14T16:11:30 usage.txt: Move -precision into advanced switches (to match cjpeg man page and usage screen)
DRC 97772cba 2022-11-14T15:36:25 Merge branch 'ijg.lossless' into dev Refer to #402
DRC 217d1a75 2022-11-08T15:01:18 Clean up the lossless JPEG feature - Rename jpeg_simple_lossless() to jpeg_enable_lossless() and modify the function so that it stores the lossless parameters directly in the Ss and Al fields of jpeg_compress_struct rather than using a scan script. - Move the cjpeg -lossless switch into "Switches for advanced users". - Document the libjpeg API and run-time features that are unavailable in lossless mode, and ensure that all parameters, functions, and switches related to unavailable features are ignored or generate errors in lossless mode. - Defer any action that depends on whether lossless mode is enabled until jpeg_start_compress()/jpeg_start_decompress() is called. - Document the purpose of the point transform value. - "Codec" stands for coder/decoder, so it is a bit awkward to say "lossless compression codec" and "lossless decompression codec". Use "lossless compressor" and "lossless decompressor" instead. - Restore backward API/ABI compatibility with libjpeg v6b: * Move the new 'lossless' field from the exposed jpeg_compress_struct and jpeg_decompress_struct structures into the opaque jpeg_comp_master and jpeg_decomp_master structures, and allocate the master structures in the body of jpeg_create_compress() and jpeg_create_decompress(). * Remove the new 'process' field from jpeg_compress_struct and jpeg_decompress_struct and replace it with the old 'progressive_mode' field and the new 'lossless' field. * Remove the new 'data_unit' field from jpeg_compress_struct and jpeg_decompress_struct and replace it with a locally-computed data unit variable. * Restore the names of macros and fields that refer to DCT blocks, and document that they have a different meaning in lossless mode. (Most of them aren't very meaningful in lossless mode anyhow.) * Remove the new alloc_darray() method from jpeg_memory_mgr and replace it with an internal macro that wraps the alloc_sarray() method. * Move the JDIFF* data types from jpeglib.h and jmorecfg.h into jpegint.h. * Remove the new 'codec' field from jpeg_compress_struct and jpeg_decompress_struct and instead reuse the existing internal coefficient control, forward/inverse DCT, and entropy encoding/decoding structures for lossless compression/decompression. * Repurpose existing error codes rather than introducing new ones. (The new JERR_BAD_RESTART and JWRN_MUST_DOWNSCALE codes remain, although JWRN_MUST_DOWNSCALE will probably be removed in libjpeg-turbo, since we have a different way of handling multiple data precisions.) - Automatically enable lossless mode when a scan script with parameters that are only valid for lossless mode is detected, and document the use of scan scripts to generate lossless JPEG images. - Move the sequential and shared Huffman routines back into jchuff.c and jdhuff.c, and document that those routines are shared with jclhuff.c and jdlhuff.c as well as with jcphuff.c and jdphuff.c. - Move MAX_DIFF_BITS from jchuff.h into jclhuff.c, the only place where it is used. - Move the predictor and scaler code into jclossls.c and jdlossls.c. - Streamline register usage in the [un]differencers (inspired by similar optimizations in the color [de]converters.) - Restructure the logic in a few places to reduce duplicated code. - Ensure that all lossless-specific code is guarded by C_LOSSLESS_SUPPORTED or D_LOSSLESS_SUPPORTED and that the library can be built successfully if either or both of those macros is undefined. - Remove all short forms of external names introduced by the lossless JPEG patch. (These will not be needed by libjpeg-turbo, so there is no use cleaning them up.) - Various wordsmithing, formatting, and punctuation tweaks - Eliminate various compiler warnings.
DRC b5a9ef64 2022-11-13T13:00:26 Don't allow 12-bit JPEG support to be disabled In libjpeg-turbo 2.1.x and prior, the WITH_12BIT CMake variable was used to enable 12-bit JPEG support at compile time, because the libjpeg API library could not handle multiple JPEG data precisions at run time. The initial approach to handling multiple JPEG data precisions at run time (7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac) created a whole new API, library, and applications for 12-bit data precision, so it made sense to repurpose WITH_12BIT to allow 12-bit data precision to be disabled. e8b40f3c2ba187ba95c13c3e8ce21c8534256df7 made it so that the libjpeg API library can handle multiple JPEG data precisions at run time via a handful of straightforward API extensions. Referring to 6c2bc901e27b047440ed46920c4d3f0480b48268, it hasn't been possible to build libjpeg-turbo with both forward and backward libjpeg API/ABI compatibility since libjpeg-turbo 1.4.x. Thus, whereas we retain full backward API/ABI compatibility with libjpeg v6b-v8, forward libjpeg API/ABI compatibility ceased being realistic years ago, so it no longer makes sense to provide compile-time options that give a false sense of forward API/ABI compatibility by allowing some (but not all) of our libjpeg API extensions to be disabled. Such options are difficult to maintain and clutter the code with #ifdefs.
DRC 9ca7919a 2022-11-07T10:22:06 OSS-Fuzz: Fix bug in the new cjpeg12 fuzzer cjpeg doesn't accept image format arguments other than -targa (it auto-detects the others), and since Targa images aren't supported with 12-bit precision, we don't need a second pass.
DRC bf01ed2f 2022-11-04T13:08:08 Fix build when SIMD extensions are disabled (Broken by previous commit)
DRC e8b40f3c 2022-11-01T21:45:39 Vastly improve 12-bit JPEG integration The Gordian knot that 7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac attempted to unravel was caused by the fact that there are several data-precision-dependent (JSAMPLE-dependent) fields and methods in the exposed libjpeg API structures, and if you change the exposed libjpeg API structures, then you have to change the whole API. If you change the whole API, then you have to provide a whole new library to support the new API, and that makes it difficult to support multiple data precisions in the same application. (It is not impossible, as example.c demonstrated, but using data-precision-dependent libjpeg API structures would have made the cjpeg, djpeg, and jpegtran source code hard to read, so it made more sense to build, install, and package 12-bit-specific versions of those applications.) Unfortunately, the result of that initial integration effort was an unreadable and unmaintainable mess, which is a problem for a library that is an ISO/ITU-T reference implementation. Also, as I dug into the problem of lossless JPEG support, I realized that 16-bit lossless JPEG images are a thing, and supporting yet another version of the libjpeg API just for those images is untenable. In fact, however, the touch points for JSAMPLE in the exposed libjpeg API structures are minimal: - The colormap and sample_range_limit fields in jpeg_decompress_struct - The alloc_sarray() and access_virt_sarray() methods in jpeg_memory_mgr - jpeg_write_scanlines() and jpeg_write_raw_data() - jpeg_read_scanlines() and jpeg_read_raw_data() - jpeg_skip_scanlines() and jpeg_crop_scanline() (This is subtle, but both of those functions use JSAMPLE-dependent opaque structures behind the scenes.) It is much more readable and maintainable to provide 12-bit-specific versions of those six top-level API functions and to document that the aforementioned methods and fields must be type-cast when using 12-bit samples. Since that eliminates the need to provide a 12-bit-specific version of the exposed libjpeg API structures, we can: - Compile only the precision-dependent libjpeg modules (the coefficient buffer controllers, the colorspace converters, the DCT/IDCT managers, the main buffer controllers, the preprocessing and postprocessing controller, the downsampler and upsamplers, the quantizers, the integer DCT methods, and the IDCT methods) for multiple data precisions. - Introduce 12-bit-specific methods into the various internal structures defined in jpegint.h. - Create precision-independent data type, macro, method, field, and function names that are prefixed by an underscore, and use an internal header to convert those into precision-dependent data type, macro, method, field, and function names, based on the value of BITS_IN_JSAMPLE, when compiling the precision-dependent libjpeg modules. - Expose precision-dependent jinit*() functions for each of the precision-dependent libjpeg modules. - Abstract the precision-dependent libjpeg modules by calling the appropriate precision-dependent jinit*() function, based on the value of cinfo->data_precision, from top-level libjpeg API functions.
DRC 6c2bc901 2022-11-03T14:39:19 Don't allow disabling in-memory src/dest managers By default, libjpeg-turbo 1.3.x and later have enabled the in-memory source/destination manager functions from libjpeg v8 when emulating the libjpeg v6b or v7 API/ABI, which has allowed operating system distributors to provide those functions without adopting the backward-incompatible libjpeg v8 API/ABI. Prior to libjpeg-turbo 1.5.x, it made sense to allow users to disable the in-memory source/destination manager functions at build time and thus retain both backward and forward API/ABI compatibility relative to libjpeg v6b or v7. Since then, however, we have introduced several new libjpeg API functions that break forward API/ABI compatibility, so it no longer makes sense to allow the in-memory source/destination managers to be disabled. libjpeg-turbo only claims to be backward-API/ABI-compatible, i.e. to allow applications built against libjpeg or an older version of libjpeg-turbo to work properly with the current version of libjpeg-turbo.
DRC 664b64a9 2022-11-03T14:25:35 Merge branch 'main' into dev
DRC 4f7a8afb 2022-11-03T13:37:55 Build: Fix issues w/ Ninja Multi-Config generator - Fix an issue whereby a build with ENABLE_SHARED=0 could not be installed when using the Ninja Multi-Config CMake generator. - Fix an issue whereby a Windows installer could not be built when using the Ninja Multi-Config CMake generator. - Fix an issue whereby the Java regression tests failed when using the Ninja Multi-Config CMake generator. Based on: https://github.com/stilllman/libjpeg-turbo/commit/4f169deeb092a0513472b04f05f57bfe42b31ceb Closes #626
DRC 8c5e78ce 2022-11-03T11:22:50 Build: Document SO_AGE and TURBOJPEG_SO_AGE vars
DRC 8917c548 2022-11-03T14:20:22 ChangeLog.md: Add colons to sub-headers For some reason, I failed to add a colon to the "Significant changes relative to 2.1 beta1" sub-header, and the mistake propagated from there.
DRC cb3642cb 2022-11-03T12:22:51 Bump version to 2.1.5 to prepare for new commits
DRC ec6e451d 2022-10-21T16:45:25 Lossless JPEG support: Add copyright attributions Referring to https://github.com/libjpeg-turbo/libjpeg-turbo/issues/402#issuecomment-768348440 and https://github.com/libjpeg-turbo/libjpeg-turbo/issues/402#issuecomment-770221584 Ken Murchison clarified that it was his intent to release the lossless JPEG patch under the IJG License and that adding his name to the copyright headers would be sufficient to acknowledge that any derivatives are based on his work.
DRC 2df43f51 2022-10-21T16:30:49 Lossless JPEG support: Fix build (Modern compilers require function prototypes.)
Ken Murchison 2e8360e0 1999-04-27T00:00:00 IJG's JPEG software v6b with lossless JPEG support Patch obtained from: https://sourceforge.net/projects/jpeg/files/ftp.oceana.com Author date taken from original announcement and timestamp of patch tarball: https://groups.google.com/g/comp.protocols.dicom/c/rrkP8BxoMRk/m/Ij4dfprggp8J
DRC 4d269d7c 2022-10-21T12:22:28 Merge branch 'main' into dev
DRC 51f1924e 2022-10-21T11:36:29 wizard.txt: Clarify scan script restrictions The Wallace paper is not entirely clear on these restrictions, and the spec itself requires some digging. Closes #624
DRC 5acd9f20 2022-10-04T12:58:11 Merge branch 'main' into dev
DRC eb0a024a 2022-10-04T12:51:38 Remove redundant jconfigint.h #includes Because of 607b668ff96e40fdc749de9b1bb98e7f40c86d93, jconfigint.h is included by jinclude.h.
DRC 543bfc25 2022-10-03T21:38:15 Merge branch 'main' into dev
DRC f579cc11 2022-10-03T19:46:09 Make SIMD capability variables thread-local ... ... on platforms that support TLS, which should include all currently-supported platforms (https://libjpeg-turbo.org/Documentation/OfficialBinaries) Addresses a concern raised in #87 Although it is still my opinion that the data race in init_simd() was innocuous, we can now fix it for free thanks to ae87a958613b69628b92088b313ded0d4f59a716, so why not?
DRC 2fd634b8 2022-09-12T23:36:34 Merge branch 'main' into dev
DRC 2cad2169 2022-09-12T21:54:35 BUILDING.md: Acknowledge RHEL 9
DRC b3d3cbf4 2022-09-12T14:41:34 JNI: Remove deprecated methods (oversight from 931884e78dc8777e6477451e984af8b263e450b1)
DRC fdfba495 2022-09-02T15:11:25 Merge branch 'main' into dev
DRC c5db99e1 2022-09-02T14:48:58 GitHub Actions: Specify Big Sur for macOS build The Catalina hosted runner is now fully deprecated.
DRC 513f9e66 2022-08-09T04:27:33 Merge branch 'main' into dev
DRC 8162eddf 2022-08-08T16:02:34 Fix issues w/ partial img decompr + buf img mode Fixes #611
DRC 931884e7 2022-08-08T15:41:01 Java: Remove deprecated fields, ctors, and methods Most of these have been deprecated since libjpeg-turbo 1.4.x. It's time.
DRC 280784f7 2022-08-08T15:07:45 Merge branch 'main' into dev
DRC 2e136a71 2022-08-08T14:17:51 Re-fix buf img mode decompr err w/short prog JPEGs This commit reverts 4dbc293125b417f97e5b1ca9e7260c82ff199a06 and 9f8f683e745972720433406cff4b31e95bd6a33e (the previous two commits) and fixes #613 the correct way. The crux of the issue wasn't the size of the whole_image virtual array but rather that, since last_iMCU_row is unsigned, (last_iMCU_row - 1) wrapped around to 0xFFFFFFFF when last_iMCU_row was 0. This caused the interblock smoothing algorithm introduced in 6d91e950c871103a11bac2f10c63bf998796c719 to erroneously try to access the next two iMCU rows, neither of which existed. The first attempt at a fix (4dbc293125b417f97e5b1ca9e7260c82ff199a06) exposed a NULL dereference, detected by OSS-Fuzz, that occurred when attempting to decompress a specially-crafted malformed JPEG image to a YUV buffer using tjDecompressToYUV*() with 1/4 IDCT scaling. Fixes #613 (again) Also fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49898
DRC f6273192 2022-08-07T14:16:28 Merge branch 'main' into dev
DRC 9f8f683e 2022-08-07T14:15:03 jdcoefct.c: Fix signed/unsigned mismatch VC++ wrng (introduced by previous commit)
DRC 9a60181b 2022-08-07T13:48:31 Merge branch 'main' into dev
DRC 4dbc2931 2022-08-07T09:24:57 Fix buf image mode decompr err w/ short prog JPEGs Regression introduced by 6d91e950c871103a11bac2f10c63bf998796c719 Because we're now using a 5x5 smoothing window when decompressing progressive JPEG images, we need to ensure that the whole_image virtual array contains at least five rows. Previously that was not always the case unless the progressive JPEG image being decompressed had at least five iMCU rows. Since an iMCU has a height of (8 * the vertical sampling factor), attempting to decompress 4:2:2 and 4:4:4 images <= 32 pixels in height or 4:2:0 images <= 64 pixels in height triggered a JERR_BAD_VIRTUAL_ACCESS error in decompress_smooth_data(), because access_rows exceeded the number of rows in the virtual array. Fixes #613
DRC fc224c48 2022-07-07T13:11:05 Merge branch 'main' into dev
Donovan Watteau 59337a67 2022-07-06T12:11:50 PowerPC: Detect AltiVec support on OS X libjpeg-turbo's AltiVec SIMD extensions previously assumed that AltiVec instructions were available on all Power Macs that supported OS X 10.4 "Tiger" (the earliest version of OS X that libjpeg-turbo has ever supported), but Tiger can actually run on PowerPC G3 processors, which lack AltiVec instructions. This commit enables run-time detection of AltiVec instructions on OS X/PowerPC systems if AltiVec instructions are not force-enabled at compile time (using -maltivec). This allows the same build of libjpeg-turbo to support G3, G4, and G5 Power Macs. Closes #609
DRC 8a3b0f70 2022-06-24T15:21:51 Implement 12-bit-specific error/warn/trace macros The macros in jerror.h refer to j_common_ptr, so it is unfortunately necessary to introduce a 12-bit-specific version of that header file (j12error.h) with 12-bit specific ERREXIT*(), WARNMS*(), and TRACEMS*() macros. (The message table is still shared between 8-bit and 12-bit implementations.) Fixes #607
DRC aa5a3599 2022-06-24T14:21:33 Merge branch 'main' into dev
DRC ba22c0f7 2022-06-24T14:03:03 tjDecompressHeader3(): Accept tables-only streams Inspired by: https://github.com/amyspark/libjpeg-turbo/commit/b3b15cfe74cf07914122e26cf1e408a9a9cf3135 Closes #604 Closes #605
DRC 225781af 2022-06-14T14:25:11 jchuff.c: Clean up aadd60ae + add code comments Based on: https://github.com/fhanau/libjpeg-turbo/commit/4d73f52032a608262f8b286dd4584836ddc73180 https://github.com/fhanau/libjpeg-turbo/commit/184f10703eeb214177b02f88939af237267a8d66 Refer to #602
DRC faa7c74a 2022-05-31T13:07:00 ChangeLog.md: Acknowledge 2.1.4 release
Felix Hanau aadd60ae 2022-05-25T19:51:52 Speed up computation of optimal Huffman tables Closes #602
DRC 0000dadf 2022-05-27T12:15:04 Merge branch 'main' into dev
DRC a405519e 2022-05-27T11:59:56 Fix build if UPSAMPLE_MERGING_SUPPORTED undefined Although it is uncommon, some downstream implementations undefine one or more of the *_SUPPORTED macros in jmorecfg.h in order to reduce the size of the library. In the interest of maintaining backward compatibility with libjpeg, this is still a supported use case. Regression introduced by 9120a247436e84c0b4eea828cb11e8f665fcde30 Based on: https://github.com/fhanau/libjpeg-turbo/commit/74c4d032f0448edb0c8898b6e096123ae1aa093f Closes #601
Jiaxun Yang fac83814 2022-05-14T14:34:43 Build: Don't enable Loongson MMI with MIPS R6+ MIPS R6 removed some instructions, so Loongson MMI cannot be built with MIPS R6+ toolchains. Closes #598
DRC 0f5d31e6 2022-04-28T20:04:53 Merge branch 'main' into dev
modbw 290ddbf7 2022-04-22T08:30:21 MinGW: Fix str*casecmp() macro redef. warning MinGW defines strcasecmp() and strncasecmp() as macros in string.h if __CRT__NO_INLINE is defined, which will be the case when including any of the Win32 API headers. Closes #594
DRC b98dabac 2022-04-27T12:38:58 Merge branch 'main' into dev
DRC 9171fd4b 2022-04-26T10:42:35 OSS-Fuzz: '.' --> '_' in fuzzer suffix Referring to https://github.com/google/oss-fuzz/issues/7575, if the fuzzer suffix contains periods, it can cause ClusterFuzz to misinterpret the file extension of the fuzzer executables and thus misidentify them.
DRC d0e7c454 2022-04-18T11:34:07 Don't install libturbojpeg.pc if WITH_TURBOJPEG=0 Fixes #593
Alex Richardson dfc63d42 2022-03-28T22:30:54 Fix non-SIMD alignment if void* bigger than double When building without the SIMD extensions, memory allocations are currently aligned to sizeof(double). However, this may be insufficient on architectures such as Arm Morello or 64-bit CHERI-RISC-V where pointers require 16-byte rather than 8-byte alignment. This patch causes memory allocations to be aligned to MAX(sizeof(void *), sizeof(double)) when building without the SIMD extensions. (NOTE: With C11 we could instead use alignof(max_align_t), but C89 compatibility is still necessary in libjpeg-turbo.) Closes #587
DRC 82081337 2022-04-06T11:16:09 Merge branch 'main' into dev
DRC 67cb0590 2022-04-06T10:50:33 OSS-Fuzz: Allow fuzzer suffix to be specified This facilitates fuzzing multiple branches of the code.
DRC 5c8cac97 2022-04-06T10:51:58 CI: Un-integrate CIFuzz Referring to the conversation in https://github.com/google/oss-fuzz/issues/7479 and #559, there was a misunderstanding regarding how CIFuzz works. It cannot be used to fuzz arbitrary PRs or code branches, and it has a 90-day delay in downloading corpora from OSS-Fuzz. That makes it unsuitable for libjpeg-turbo.
DRC 89a369de 2022-03-31T10:33:26 Merge branch 'main' into dev
DRC df3c3dcb 2022-03-31T10:22:06 BUILDING.md: Generify PowerTools repo advice This advice applies to CentOS Stream as well as to popular CentOS 8 replacements, such as Rocky Linux and AlmaLinux.
DRC 1b9edb5c 2022-03-10T23:57:11 Build: Fix 12-bit FP tests w/ 32-bit builds With x86-64 builds, the default value of FLOATTEST works with both the 8-bit-per-sample and 12-bit-per-sample flavors of the libjpeg API library. However, that is not the case with x86 builds. Thus, we need separate 8-bit-per-sample and 12-bit-per-sample FLOATTEST variables.
DRC cb715fe1 2022-03-11T17:12:37 example.c: Fix compiler warning with GCC 4.4.7
kmx.io     mail     discord kmxgit v0.4.0