kc3-lang/libjpeg-turbo/CMakeLists.txt

CMakeLists.txt

Branch

Log

Author Commit Date CI Message
DRC 9bd98463 2025-10-08T10:37:57 Bump version to 3.1.3 to prepare for new commits
DRC f74989d8 2025-09-25T11:32:45 Clean up #include directives This is subtle, but #include <header.h> searches directories specified with -I, then system include directories. #include "header.h" searches the current source directory, then directories specified with -I, then system include directories. Using bracketed #include directives for jpeglib.h, jinclude.h, jerror.h, cdjpeg.h, and turbojpeg.h only worked because the build system explicitly passed -I{source_directory}/src/ to the compiler. Referring to 51cee0362998ec6f1eabac1e795f3b6e3ee639ea, it's better for the source code to have as few dependencies on our specific build system as possible. Since jpeglib.h, jinclude.h, jerror.h, and turbojpeg.h can be installed in system include directories, it's also better for internal references to those headers to resolve internally first, to avoid potential conflicts between the system-installed version of libjpeg-turbo and the version being built. (Such conflicts would never have occurred with our build system, but they might have occurred due to misintegration with a downstream build system.)
DRC c53932d1 2025-09-23T08:40:41 Win: Don't use GCC/Clang visibility attribute Symbols are hidden by default on Windows, so __attribute__((visibility("hidden"))) produced a warning ("visibility attribute not supported in this configuration; ignored") with certain versions of MinGW if libjpeg-turbo was built without SIMD extensions.
DRC f2d1f1cb 2025-08-08T12:12:40 Build, LICENSE.md: Update copyright year
DRC 81feffa6 2025-06-14T10:26:37 Build: Add dire warning to WITH_TESTS description (basically a CYA disclaimer that, if you don't build and run the regression tests, then we assume no responsibility for any incorrect JPEGage or other hilarity that may ensue.)
DRC 942ac87e 2025-06-14T07:45:48 Build: Allow disabling tests/command-line tools This is useful for downstream projects that include libjpeg-turbo via ExternalProject_Add(). Closes #818
DRC 91b3d4be 2025-06-14T07:19:17 CMakeLists.txt: Formatting tweak
DRC 51cee036 2025-06-13T14:52:09 Build: Use wrappers rather than CMake object libs Some downstream projects need to adapt the libjpeg-turbo source code to non-CMake build systems, and the use of CMake object libraries made that difficult. Referring to #754, the use of CMake object libraries also caused the libjpeg-turbo libraries to contain duplicate object names, which caused problems with certain development tools. This commit modifies the build system so that it uses wrappers, rather than CMake object libraries, to compile source files for multiple data precisions. For convenience, the wrappers are included in the source tree, but they can be re-generated by building the "wrappers" target. In addition to facilitating downstream integration, using wrappers improves code readability, since multiple data precisions are now handled at the source code level instead of at the build system level. Since this will be pushed to a bug-fix release, the goal was to avoid changing any existing source code. A future major release of libjpeg-turbo may restructure the libjpeg API source code so that only the functions that need to be compiled for multiple data precisions are wrapped. (That is how the TurboJPEG API source code is structured.) Closes #817
DRC c889b1da 2025-06-12T09:40:20 TJBench: Require additional argument with -copy (oversight from e4c67aff50420d7bacff503ceb4556c896128413)
DRC 7723f50f 2025-06-06T13:37:48 Build: Don't modify CMAKE_C_FLAGS_* if specified The build system originally force-enabled the maximum optimization level (-O3) with GCC because it significantly improved the performance of the C Huffman encoder on x86 platforms. Since libjpeg-turbo 1.5.x, the Huffman encoder has been SIMD-accelerated on x86 and Arm platforms, and in my testing on various Intel CPUs, the difference between -O2 and -O3 is no longer statistically significant. However, on certain Arm CPUs, I observe that grayscale decompression slows down by 16-27% with -O2 vs. -O3. Although modern versions of CMake use -O3 as the default optimization level for Release builds, -O2 is still the default optimization level for RelWithDebInfo builds. Thus, I am reluctant to change the default behavior of our build system. However, referring to #815, some users observe better performance with -O2 vs. -O3 on other Arm CPUs, so the build system needs to allow users to override the default behavior. Closes #815
DRC e0e18dea 2024-12-18T12:50:38 Ensure methods called by global funcs are init'd If a hypothetical calling application does something really stupid and changes cinfo->data_precision after calling jpeg_start_*compress(), then the precision-specific methods called by jpeg_write_scanlines(), jpeg_write_raw_data(), jpeg_finish_compress(), jpeg_read_scanlines(), jpeg_read_raw_data(), or jpeg_start_output() may not be initialized. Ensure that the first precision-specific method (which will always be cinfo->main->process_data*(), cinfo->coef->compress_data*(), or cinfo->coef->decompress_data()) called by any global function that may be called after jpeg_start_*compress() is initialized and non-NULL. This increases the likelihood (but does not guarantee) that a hypothetical stupid calling application will fail gracefully rather than segfault if it changes cinfo->data_precision after calling jpeg_start_*compress(). A hypothetical stupid calling application can still bork itself by changing cinfo->data_precision after initializing the source manager but before calling jpeg_start_compress(), or after initializing the destination manager but before calling jpeg_start_decompress().
DRC 20ade4de 2024-12-12T15:39:26 Build: Fix float test errors with Xcode 14.2/Arm Unlike other versions of Clang 14.0.0, AppleClang 14.0.0 in Xcode 14.2 retains the old -ffp-contract=off default. Apple didn't adopt -ffp-contract=on as the default until Xcode 14.3 (AppleClang 14.0.3.) This has been confirmed in the Xcode 14.3 release notes.
DRC c3446d64 2024-12-12T11:01:53 Bump version to 3.1.0
DRC ad9c02c6 2024-09-23T13:22:09 tj3Set(): Allow TJPARAM_LOSSLESSPT vals from 0..15 The target data precision isn't necessarily known at the time that the calling program sets TJPARAM_LOSSLESSPT, so tj3Set() needs to allow all possible values (from 0 to 15.) jpeg_enable_lossless(), which is called within the body of tj3Compress*(), will throw an error if the point transform value is greater than {data precision} - 1.
DRC 2351a2d5 2024-09-16T12:30:27 Build: Support LLVM/Windows Since LLVM/Windows emulates Visual Studio, CMake sets CMAKE_C_SIMULATE_ID="MSVC" but does not set MSVC. Thus, our build system needs to enable most (but not all) of the Visual Studio features when CMAKE_C_SIMLUATE_ID="MSVC". Support for LLVM/Windows is currently undocumented because it isn't a standalone build environment. (It requires the Visual Studio and Windows SDK headers and link libraries.) Closes #786
DRC a9f7490c 2024-09-14T16:09:15 Build: Fix typo
DRC 9d76821f 2024-09-14T16:00:53 3.1 beta1
DRC a2728582 2024-09-03T07:54:17 TurboJPEG: ICC profile support
DRC d43ed7a1 2024-09-04T08:38:13 Merge branch 'main' into dev
DRC 939f3814 2024-09-03T15:35:25 Test: Replace test2.icc with test3.icc test3.icc is smaller, and it is also an RGB profile rather than a CMYK profile. (test1.icc is a CMYK profile.)
DRC fad61007 2024-08-20T18:52:53 Replace TJExample with IJG workalike programs
DRC 9b119896 2024-08-31T17:46:37 Move test scripts into test/
DRC 64567381 2024-08-31T17:31:02 Merge branch 'main' into dev
DRC 0fb8fbe1 2024-08-31T15:39:34 CMakeLists.txt: libjpeg-turbo "2.2.x" = "3.0.x"
DRC 79b8d65f 2024-08-22T13:50:32 Java: Add official packed-pixel image I/O methods
DRC 4c0e5642 2024-08-02T09:09:34 Merge branch 'main' into dev
DRC 8db03126 2024-08-02T08:45:36 example.c: Write correct dimensions to PPM header The dimensions in the PPM header of the output file generated by 'example decompress' were always 640 x 480, regardless of the size of the JPEG image being decompressed. Our regression tests (which this commit also fixes) missed the bug because they decompressed the 640 x 480 image generated by 'example compress'. Fixes #778
DRC 6ec8e41f 2024-06-13T11:52:13 Handle lossless JPEG images w/2-15 bits per sample Closes #768 Closes #769
DRC 3290711d 2024-06-22T17:45:31 cjpeg: Only support 8-bit precision w/ GIF input Creating 12-bit-per-sample JPEG images from GIF input images was a useful testing feature when the data precision was a compile-time setting. However, now that the data precision is a runtime setting, it doesn't make sense for cjpeg to allow data precisions other than 8-bit with GIF input images. GIF images are limited to 256 colors from a palette of 8-bit-per-component RGB values, so they cannot take advantage of the additional gamut afforded by higher data precisions.
DRC 55bcad88 2024-06-24T22:16:07 Merge branch 'main' into dev
DRC 94c64ead 2024-06-17T20:27:57 Various doc tweaks - "bits per component" = "bits per sample" Describing the data precision of a JPEG image using "bits per component" is technically correct, but "bits per sample" is the terminology that the JPEG-1 spec uses. Also, "bits per component" is more commonly used to describe the precision of packed-pixel formats (as opposed to "bits per pixel") rather than planar formats, in which all components are grouped together. - Unmention legacy display technologies. Colormapped and monochrome displays aren't a thing anymore, and even when they were still a thing, it was possible to display full-color images to them. In 1991, when JPEG decompression time was measured in minutes per megapixel, it made sense to keep a decompressed copy of JPEG images on disk, in a format that could be displayed without further color conversion (since color conversion was slow and memory-intensive.) In 2024, JPEG decompression time is measured in milliseconds per megapixel, and color conversion is even faster. Thus, JPEG images can be decompressed, displayed, and color-converted (if necessary) "on the fly" at speeds too fast for human vision to perceive. (In fact, your TV performs much more complicated decompression algorithms at least 60 times per second.) - Document that color quantization (and associated features), GIF input/output, Targa input/output, and OS/2 BMP input/output are legacy features. Legacy status doesn't necessarily mean that the features are deprecated. Rather, it is meant to discourage users from using features that may be of little or no benefit on modern machines (such as low-quality modes that had significant performance advantages in the early 1990s but no longer do) and that are maintained on a break/fix basis only. - General wordsmithing, grammar/punctuation policing, and formatting tweaks - Clarify which data precisions each cjpeg input format and each djpeg output format supports. - cjpeg.1: Remove unnecessary and impolitic statement about the -targa switch. - Adjust or remove performance claims to reflect the fact that: * On modern machines, the djpeg "-fast" switch has a negligible effect on performance. * There is a measurable difference between the performance of Floyd- Steinberg dithering and no dithering, but it is not likely perceptible to most users. * There is a measurable difference between the performance of 1-pass and 2-pass color quantization, but it is not likely perceptible to most users. * There is a measurable difference between the performance of full-color and grayscale output when decompressing a full-color JPEG image, but it is not likely perceptible to most users. * IDCT scaling does not necessarily improve performance. (It generally does if the scaling factor is <= 1/2 and generally doesn't if the scaling factor is > 1/2, at least on my machine. The performance claim made in jpeg-6b was probably invalidated when we merged the additional scaling factors from jpeg-7.) - Clarify which djpeg switches/output formats cannot be used when decompressing lossless JPEG images. - Remove djpeg hints, since those involve quality vs. speed tradeoffs that are no longer relevant for modern machines. - Remove documentation regarding using color quantization with 16-bit data precision. (Color quantization requires lossy mode.) - Java: Fix typos in TJDecompressor.decompress12() and TJDecompressor.decompress16() documentation. - jpegtran.1: Fix truncated paragraph In a man page, a single quote at the start of a line is interpreted as a macro. Closes #775 - libjpeg.txt: * Mention J16SAMPLE data type (oversight.) * Remove statement about extending jdcolor.c. (libjpeg-turbo is not quite as DIY as libjpeg once was.) * Remove paragraph about tweaking the various typedefs in jmorecfg.h. It is no longer relevant for modern machines. * Remove caveat regarding systems with ints less than 16 bits wide. (ANSI/ISO C requires an int to be at least 16 bits wide, and libjpeg-turbo has never supported non-ANSI compilers.) - usage.txt: * Add copyright header. * Document cjpeg -icc, -memdst, -report, -strict, and -version switches. * Document djpeg -icc, -maxscans, -memsrc, -report, -skip, -crop, -strict, and -version switches. * Document jpegtran -icc, -maxscans, -report, -strict, and -version switches.
DRC bc491b16 2024-05-16T17:32:02 ChangeLog.md: Document previous commit
DRC e0d660f1 2024-05-08T11:42:39 Merge branch 'main' into dev
DRC 3f43bb33 2024-05-06T13:03:46 Build: Don't use COMPONENT w/install(INCLUDES ...) (Regression introduced by 24e09baaf024e71841a92d30d0e763242ed959ef) The install() INCLUDES option is not an artifact option. It specifies a list of directories that will be added to the INTERFACE_INCLUDE_DIRECTORIES target property when the target is exported using the install() EXPORT option, which occurs when CMake package config files are generated. Specifying 'COMPONENT include' with the install() INCLUDES option caused the INTERFACE_INCLUDE_DIRECTORIES properties in our CMake package config files to contain '${_IMPORT_PREFIX}/COMPONENT', which caused errors of the form 'Imported target "libjpeg-turbo::XXXX" includes non-existent path' when downstream build systems attempted to include libjpeg-turbo using find_package(). Fixes #759 Closes #760
Kleis Auke Wolthuizen 24e09baa 2024-04-12T11:46:21 Build: Add COMPONENT to all install() commands This makes it possible for downstream packagers and other integrators of libjpeg-turbo to include only specific directories from the libjpeg-turbo installation (or to install specific directories under a different prefix, etc.) The names of the components correspond to the directories into which they will be installed. Refer to libvips/libvips#3931, #265, #338 Closes #756
DRC 3405d189 2024-03-18T12:59:33 Merge branch 'main' into dev
DRC 710865cf 2024-03-18T12:56:42 Build: Don't explicitly set CMP0065 to NEW This is no longer necessary, because of 1644bdb7d2fac66cd0ce25adef7754e008b5bc1e.
DRC cf357e81 2024-03-18T12:46:54 Merge branch 'main' into dev
DRC fe218ca1 2024-03-18T11:27:30 Build: Handle CMAKE_C_COMPILER_ID=AppleClang Because of 1644bdb7d2fac66cd0ce25adef7754e008b5bc1e, we are now effectively using the NEW behavior for all CMake policies introduced in all CMake versions up to and including CMake 3.28. The NEW behavior for CMP0025, introduced in CMake 3.0, sets CMAKE_C_COMPILER_ID to "AppleClang" instead of "Clang" when using Apple's variant of Clang (in Xcode), so we need to match all values of CMAKE_C_COMPILER_ID that contain "Clang". This fixes three issues: - -O2 was not replaced with -O3 in CMAKE_C_FLAGS_RELWITHDEBINFO. This was a minor issue, since -O3 is now the default in CMAKE_C_FLAGS_RELEASE, and we use CMAKE_BUILD_TYPE=Release in our official builds. - The build system erroneously set the default value of FLOATTEST8 and FLOATTEST12 to no-fp-contract when compiling for PowerPC or Arm using Apple Clang 14+ (effectively reverting 5b2beb4bc4f41dd9dd2a905cb931b8d5054d909b.) Because Clang 14+ now enables -ffp-contract=on by default, this issue caused floating point test failures unless FLOATTEST8 and FLOATTEST12 were overridden. - The build system set MD5_PPM_3x2_FLOAT_FP_CONTRACT as appropriate for GCC, not as appropriate for Clang (effectively reverting 47656a082091f9c9efda054674522513f4768c6c.) This also caused floating point test failures. Fixes #753 Closes #755
DRC dfde1f85 2024-03-08T12:09:23 Fix (and test) more Clang 14 compiler warnings -Woverlength-strings, -Wshift-negative-value, -Wsign-compare
DRC c8c5c2e5 2024-03-06T15:33:47 Merge branch 'main' into dev
DRC 34c05585 2024-03-06T15:12:31 Fix warnings with -Wmissing-variable-declarations
DRC 310a2436 2024-02-08T12:36:06 Merge branch 'main' into dev
DRC 26fc07c8 2024-02-08T12:03:37 Build: Set MSVC run-time lib based on IDE config
DRC 9b0f25a6 2024-01-30T18:31:31 Merge branch 'main' into dev
Alyssa Ross b6ee1016 2024-01-29T17:18:38 Build: Fix tests w/ emulators that don't check CWD While QEMU will run executables from the current working directory, other emulators may not. It is more reliable to pass the full executable path to the emulator. The add_test(NAME ... COMMAND ...) syntax automatically invokes the emulator (e.g. the command specified in CMAKE_CROSSCOMPILING_EMULATOR) and passes the full executable path to it, as long as the first COMMAND argument is the name of a target. This cleans up the CMake code somewhat as well, since it is no longer necessary to manually invoke CMAKE_CROSSCOMPILING_EMULATOR. Closes #747
DRC d59b1a3b 2024-01-30T15:40:51 Build: Reformat lines longer than 80 columns ... ... to ensure that no function argument starts beyond the 80th column.
DRC 1b5394bc 2024-01-26T18:07:01 Merge branch 'main' into dev
DRC 7d67c349 2024-01-26T10:34:04 Build/Win: Report CMAKE_MSVC_RUNTIME_LIBRARY value ... when using CMake 3.15+
DRC 98b6ed78 2024-01-26T09:56:14 Merge branch 'main' into dev
DRC 17df25f9 2024-01-25T13:52:58 Build/Win: Eliminate MSVC run-time DLL dependency (regression introduced by 1644bdb7d2fac66cd0ce25adef7754e008b5bc1e) Setting a maximum version in cmake_minimum_required() effectively sets the behavior to NEW for all policies introduced in all CMake versions up to and including that maximum version. The NEW behavior for CMP0091, introduced in CMake 3.15, uses CMake variables to specify the MSVC runtime library against which to link, rather than placing the relevant flags in CMAKE_C_FLAGS*. Thus, replacing /MD with /MT in CMAKE_C_FLAGS* no longer has any effect when using CMake 3.15+.
DRC 9f5a04b5 2024-01-24T11:30:40 Reorganize source tree, Part Deux - Move version scripts/map files into src/, since those files apply only to the C API libraries.
DRC e69dd40c 2024-01-23T13:26:41 Reorganize source to make things easier to find - Move all libjpeg documentation, except for README.ijg, into the doc/ subdirectory. - Move the TurboJPEG C API documentation from doc/html/ into doc/turbojpeg/. - Move all C source code and headers into a src/ subdirectory. - Move turbojpeg-jni.c into the java/ subdirectory. Referring to #226, there is no ideal solution to this problem. A semantically ideal solution would have involved placing all source code, including the SIMD and Java source code, under src/ (or perhaps placing C library source code under lib/ and C test program source code under test/), all header files under include/, and all documentation under doc/. However: - To me it makes more sense to have separate top-level directories for each language, since the SIMD extensions and the Java API are technically optional features. src/ now contains only the code that is relevant to the core C API libraries and associated programs. - I didn't want to bury the java/ and simd/ directories or add a level of depth to them, since both directories already contain source code that is 3-4 levels deep. - I would prefer not to separate the header files from the C source code, because: 1. It would be disruptive. libjpeg and libjpeg-turbo have historically placed C source code and headers in the same directory, and people who are familiar with both projects (self included) are used to looking for the headers in the same directory as the C source code. 2. In terms of how the headers are used internally in libjpeg-turbo, the distinction between public and private headers is a bit fuzzy. - It didn't make sense to separate the test source code from the library source code, since there is not a clear distinction in some cases. (For instance, the IJG image I/O functions are used by cjpeg and djpeg as well as by the TurboJPEG API.) This solution is minimally disruptive, since it keeps all C source code and headers together and keeps java/ and simd/ as top-level directories. It is a bit awkward, because java/ and simd/ technically contain source code, even though they are not under src/. However, other solutions would have been more awkward for different reasons. Closes #226
DRC 289df647 2024-01-23T17:35:53 Build: Add tjdoc target for building TurboJPEG dox
DRC 0ef07927 2024-01-23T10:46:04 Bump copyright year to 2024
DRC 1644bdb7 2024-01-22T14:33:31 BUILD: Silence CMake 3.28.x deprecation warning Closes #740
DRC fa2b6ea0 2024-01-12T18:21:41 Eliminate duplicate copies of jpeg_nbits_table ef9a4e05ba919494cbebe50e15f332de5ab97e82 (libjpeg-turbo 1.4.x), which was based on https://bug815473.bmoattachments.org/attachment.cgi?id=692126 (https://bugzilla.mozilla.org/show_bug.cgi?id=815473), modified the C baseline Huffman encoder so that it precomputes jpeg_nbits_table, in order to facilitate sharing the table among multiple processes. However, libjpeg-turbo never shared the table, and because the table was implemented as a static array, f3a8684cd1c28e557d394470962a7a224c76ddbc (libjpeg-turbo 1.5.x) and 37bae1a0e977ee1ba769e6f0aa27e519ab6e58c6 (libjpeg-turbo 2.0.x) each introduced a duplicate copy of the table for (respectively) the SSE2 baseline Huffman encoder and the C progressive Huffman encoder. This commit does the following: - Move the duplicated code in jchuff.c and jcphuff.c, originally introduced in 0cfc4c17b740cb2cbb11f9d85c8ab3745d5b913a and 37bae1a0e977ee1ba769e6f0aa27e519ab6e58c6, into a header (jpeg_nbits.h). - Credit the co-author of 0cfc4c17b740cb2cbb11f9d85c8ab3745d5b913a. (Refer to https://sourceforge.net/p/libjpeg-turbo/patches/57). - Modify the SSE2 baseline Huffman encoder so that the C Huffman encoders can share its definition of jpeg_nbits_table. - Move the definition of jpeg_nbits_table into a C source file (jpeg_nbits.c) rather than a header, and define the table only if USE_CLZ_INTRINSIC is undefined and the SSE2 baseline Huffman encoder will not be built. - Apply hidden symbol visibility to the shared definition of jpeg_nbits_table, if the compiler supports the necessary attribute. (In practice, only Visual C++ doesn't.) Closes #114 See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1501523
DRC 0e2d289f 2023-11-07T12:38:05 Bump version to 3.0.2 to prepare for new commits
DRC 5b2beb4b 2023-10-10T16:44:59 Build: Set FLOATTEST* by default for AArch64, PPC Because of 47656a082091f9c9efda054674522513f4768c6c, we can now reliably determine the correct default values for FLOATTEST8 and FLOATTEST12 when using Clang or GCC to build for AArch64 or PowerPC platforms. (Testing confirms that this is the case with GCC 5-13 and Clang 5-14 on Ubuntu/AArch64, GCC 4 on CentOS 7/PPC, and GCC 8-10 and Clang 6-12 on Ubuntu/PPCLE.) Other CPU architectures and compilers can be added on a case-by-case basis as they are tested.
DRC 47656a08 2023-10-02T18:03:50 Test: Fix float test errors w/ Clang & fp-contract The MD5 sums associated with FLOATTEST8=fp-contract and FLOATTEST12=fp-contract are appropriate for GCC (tested v5 through v13) with -ffp-contract=fast, which is the default when compiling for an architecture that has fused multiply-add (FMA) instructions. However, different MD5 sums are needed for Clang (tested v5 through v14) with -ffp-contract=on, which is now the default in Clang 14 when compiling for an architecture that has FMA instructions. Refer to #705, #709, #710
DRC e17fa3a2 2023-07-27T13:11:39 Bump version to 3.0.1 to prepare for new commits
DRC 63bd7188 2023-07-25T10:01:42 Build: Unset FLOATTEST* by default for non-x86 Because libjpeg-turbo 3.0.x now supports multiple data precisions in the same build, the regression test system can test the 8-bit and 12-bit floating point DCT/IDCT algorithms separately. The expected MD5 sums for those tests are communicated to the test system using the FLOATTEST8 and FLOATTEST12 CMake variables. Whereas it is possible to intelligently set a default value for FLOATTEST8 when building for x86[-64] and a default value for FLOATTEST12 when building for x86-64, it is not possible with other architectures. (Refer to #705, #709, and #710.) Clang 14, for example, now enables FMA (fused multiply-add) instructions by default on architectures that support them, but with AArch64 builds, the results are not the same as when using GCC/AArch64 with FMA instructions enabled. Thus, setting FLOATTEST12=fp-contract doesn't make the tests pass. It was already impossible to intelligently set a default for FLOATTEST8 with i386 builds, but referring to #710, that appears to be the case with other non-x86-64 builds as well. Back in 1991, when Tom Lane first released libjpeg, some CPUs had floating point units and some didn't. It could take minutes to compress or decompress a 1-megapixel JPEG image using the "slow" integer DCT/IDCT algorithms, and the floating point algorithms were significantly faster on systems that had an FPU. On systems without FPUs, floating point math was emulated and really slow, so Tom also developed "fast" integer DCT/IDCT algorithms to speed up JPEG performance, at the expense of accuracy, on those systems. Because of libjpeg-turbo's SIMD extensions, the floating point algorithms are now significantly slower than the "slow" integer algorithms without being significantly more accurate, and the "fast" integer algorithms fail the ISO/ITU-T conformance tests without being any faster than the "slow" integer algorithms on x86 systems. Thus, the floating point and "fast" integer algorithms are considered legacy features. In order for the floating point regression tests to be useful, the results of the tests must be validated against an independent metric. (In other words, it wouldn't be useful to use the floating point DCT/IDCT algorithms to determine the expected results of the floating point DCT/IDCT algorithms.) In the past, I attempted without success to develop a low-level floating point test that would run at configure time and determine the appropriate default value of FLOATTEST*. Barring that approach, the only other possibilities would be: 1. Develop a test framework that compares the floating point results with a margin of error, as TJUnitTest does. However, that effort isn't justified unless it could also benefit non-legacy features. 2. Compare the floating point results against an expected MD5 sum, as we currently do. However, as previously described, it isn't possible in most cases to determine an appropriate default value for the expected MD5 sum. For the moment, it makes the most sense to disable the 8-bit floating point tests by default except with x86[-64] builds and to disable the 12-bit floating point tests by default except with x86-64 builds. That means that the floating point algorithms will still be regression tested when performing x86[-64] builds, but other types of builds will have to opt in to the same regression tests. Since the floating point DCT/IDCT algorithms are unlikely to change ever again (the only reason they still exist at all is to maintain backward compatibility with libjpeg), this seems like a reasonable tradeoff.
DRC d6914b6b 2023-07-24T16:41:18 CMakeLists.txt: Fix comment buglet
DRC 035ea386 2023-07-06T12:04:22 Build: Fix regression test concurrency issues - The example-*bit-*-decompress test must run after the example-*bit-*-compress test, since the latter generates testout*-example.jpg. - Add -static to the filenames of all output files generated by the "static" regression tests, to avoid conflicts with the "shared" regression tests. - Add the PID to the filenames of all files generated by the tjunittest packed-pixel image I/O tests. - Check the return value of MD5File() in tjunittest to avoid a segfault if the file doesn't exist. (Prior to the fix described above, that could occur if two instances of tjunittest ran concurrently from the same directory with the same -bmp and -precision arguments.) Fixes #705
DRC bf9f319c 2023-06-29T16:07:42 Disallow color quantization with lossless decomp Color quantization is a legacy feature that serves little or no purpose with lossless JPEG images. 9f756bc67a84d4566bf74a0c2432aa55da404021 eliminated interaction issues between the lossless decompressor and the color quantizers related to out-of-range 12-bit samples, but referring to #701, other interaction issues apparently still exist. Such issues are likely, given the fact that the color quantizers were not designed with lossless decompression in mind. This commit reverts 9f756bc67a84d4566bf74a0c2432aa55da404021, since the issues it fixed are no longer relevant because of this commit and 2192560d74e6e6cf99dd05928885573be00a8208. Fixed #672 Fixes #673 Fixes #674 Fixes #676 Fixes #677 Fixes #678 Fixes #679 Fixes #681 Fixes #683 Fixes #701
DRC 0e9683c4 2023-06-12T14:36:18 Bump version to 3.0.0
DRC d491094b 2023-04-03T12:31:40 Build separate static/shared jpeg12/16 obj libs If PIC isn't enabled for the entire build (using CMAKE_POSITION_INDEPENDENT_CODE), then we need to enable it for any of the objects in the libjpeg-turbo shared libraries. Ideally, however, we don't want to enable PIC for any of the objects in the libjpeg-turbo static libraries, unless CMAKE_POSITION_INDEPENDENT_CODE is set. Thus, we need to build separate static and shared jpeg12 and jpeg16 object libraries. Fixes #684
DRC 58a3427f 2023-03-09T21:07:40 Bump version to 2.1.92 to prepare for new commits
DRC c13fe159 2023-02-23T09:35:12 Build: Clarify CMAKE_OSX_ARCHITECTURES error It's not that the build system doesn't support multiple values in CMAKE_OSX_ARCHITECTURES. It's that libjpeg-turbo, because of its SIMD extensions, *cannot* support multiple values in CMAKE_OSX_ARCHITECTURES.
DRC 2af984fd 2023-02-10T09:55:27 Build: Fail if included with add_subdirectory() Even though BUILDING.md and CONTRIBUTING.md explicitly state that the libjpeg-turbo build system does not and will not support being integrated into downstream build systems using add_subdirectory() (see 05655481917a2d2761cf2fe19b76f639b7f159ef), people continue to file bug reports, feature requests, and pull requests regarding that (see #265, #637, and #653 in addition to the issues listed in 05655481917a2d2761cf2fe19b76f639b7f159ef.) Responding to those issues wastes our project's limited resources. Hopefully people will get the hint if the build system explicitly tells them that it can't be included using add_subdirectory(), which will prompt them to read the comments in CMakeLists.txt explaining why. To anyone stumbling upon this commit message, please refer to the discussions under the issues listed above, as well as the issues listed in 05655481917a2d2761cf2fe19b76f639b7f159ef. Our project's position on this has been stated, explained, and defended numerous times.
DRC 6c610333 2023-02-08T09:23:51 ChangeLog.md: Document 4e028ecd + bump version to 3.0 beta2
DRC dd89ce6c 2023-02-01T11:54:09 Build: Define THREAD_LOCAL even if !WITH_TURBOJPEG The SIMD dispatchers use thread-local storage now as well, because of f579cc11b33e5bfeb9931e37cc74b4a33c95d2e6.
DRC fd8c4da0 2023-01-27T14:05:07 Bump revision to 2.1.90 to prepare for beta + acknowledge upcoming 2.1.5 release
DRC fc01f467 2023-01-05T06:36:46 TurboJPEG 3 API overhaul (ChangeLog update forthcoming) - Prefix all function names with "tj3" and remove version suffixes from function names. (Future API overhauls will increment the prefix to "tj4", etc., thus retaining backward API/ABI compatibility without versioning each individual function.) - Replace stateless boolean flags (including TJ*FLAG_ARITHMETIC and TJ*FLAG_LOSSLESS, which were never released) with stateful integer parameters, the value of which persists between function calls. * Use parameters for the JPEG quality and subsampling as well, in order to eliminate the awkwardness of specifying function arguments that weren't relevant for lossless compression. * tj3DecompressHeader() now stores all relevant information about the JPEG image, including the width, height, subsampling type, entropy coding type, etc. in parameters rather than returning that information in its arguments. * TJ*FLAG_LIMITSCANS has been reimplemented as an integer parameter (TJ*PARAM_SCANLIMIT) that allows the number of scans to be specified. - Use the const keyword for all pointer arguments to unmodified buffers, as well as for both dimensions of 2D pointers. Addresses #395. - Use size_t rather than unsigned long to represent buffer sizes, since unsigned long is a 32-bit type on Windows. Addresses #24. - Return 0 from all buffer size functions if an error occurs, rather than awkwardly trying to return -1 in an unsigned data type. - Implement 12-bit and 16-bit data precision using dedicated compression, decompression, and image I/O functions/methods. * Suffix the names of all data-precision-specific functions with 8, 12, or 16. * Because the YUV functions are intended to be used for video, they are currently only implemented with 8-bit data precision, but they can be expanded to 12-bit data precision in the future, if necessary. * Extend TJUnitTest and TJBench to test 12-bit and 16-bit data precision, using a new -precision option. * Add appropriate regression tests for all of the above to the 'test' target. * Extend tjbenchtest to test 12-bit and 16-bit data precision, and add separate 'tjtest12' and 'tjtest16' targets. * BufferedImage I/O in the Java API is currently limited to 8-bit data precision, since the BufferedImage class does not straightforwardly support higher data precisions. * Extend the PPM reader to convert 12-bit and 16-bit PBMPLUS files to grayscale or CMYK pixels, as it already does for 8-bit files. - Properly accommodate lossless JPEG using dedicated parameters (TJ*PARAM_LOSSLESS, TJ*PARAM_LOSSLESSPSV, and TJ*PARAM_LOSSLESSPT), rather than using a flag and awkwardly repurposing the JPEG quality. Update TJBench to properly reflect whether a JPEG image is lossless. - Re-organize the TJBench usage screen. - Update the Java docs using Java 11, to improve the formatting and eliminate HTML frames. - Use the accurate integer DCT algorithm by default for both compression and decompression, since the "fast" algorithm is a legacy feature, it does not pass the ISO compliance tests, and it is not actually faster on modern x86 CPUs. * Remove the -accuratedct option from TJBench and TJExample. - Re-implement the 'tjtest' target using a CMake script that enables the appropriate tests, depending on the data precision and whether or not the Java API is part of the build. - Consolidate the C and Java versions of tjbenchtest into one script. - Consolidate the C and Java versions of tjexampletest into one script. - Combine all initialization functions into a single function (tj3Init()) that accepts an integer parameter specifying the subsystems to initialize. - Enable decompression scaling explicitly, using a new function/method (tj3SetScalingFactor()/TJDecompressor.setScalingFactor()), rather than implicitly using awkward "desired width"/"desired height" parameters. - Introduce a new macro/constant (TJUNSCALED/TJ.UNSCALED) that maps to a scaling factor of 1/1. - Implement partial image decompression, using a new function/method (tj3SetCroppingRegion()/TJDecompressor.setCroppingRegion()) and TJBench option (-crop). Extend tjbenchtest to test the new feature. Addresses #1. - Allow the JPEG colorspace to be specified explicitly when compressing, using a new parameter (TJ*PARAM_COLORSPACE). This allows JPEG images with the RGB and CMYK colorspaces to be created. - Remove the error/difference image feature from TJBench. Identical images to the ones that TJBench created can be generated using ImageMagick with 'magick composite <original_image> <output_image> -compose difference <diff_image>' - Handle JPEG images with unknown subsampling types. TJ*PARAM_SUBSAMP is set to TJ*SAMP_UNKNOWN (== -1) for such images, but they can still be decompressed fully into packed-pixel images or losslessly transformed (with the exception of lossless cropping.) They cannot be partially decompressed or decompressed into planar YUV images. Note also that TJBench, due to its lack of support for imperfect transforms, requires that the subsampling type be known when rotating, flipping, or transversely transposing an image. Addresses #436 - The Java version of TJBench now has identical functionality to the C version. This was accomplished by (somewhat hackishly) calling the TurboJPEG C image I/O functions through JNI and copying the pixels between the C heap and the Java heap. - Add parameters (TJ*PARAM_RESTARTROWS and TJ*PARAM_RESTARTBLOCKS) and a TJBench option (-restart) to allow the restart marker interval to be specified when compressing. Eliminate the undocumented TJ_RESTART environment variable. - Add a parameter (TJ*PARAM_OPTIMIZE), a transform option (TJ*OPT_OPTIMIZE), and a TJBench option (-optimize) to allow optimized baseline Huffman coding to be specified when compressing. Eliminate the undocumented TJ_OPTIMIZE environment variable. - Add parameters (TJ*PARAM_XDENSITY, TJ*PARAM_DENSITY, and TJ*DENSITYUNITS) to allow the pixel density to be specified when compressing or saving a Windows BMP image and to be queried when decompressing or loading a Windows BMP image. Addresses #77. - Refactor the fuzz targets to use the new API. * Extend decompression coverage to 12-bit and 16-bit data precision. * Replace the awkward cjpeg12 and cjpeg16 targets with proper TurboJPEG-based compress12, compress12-lossless, and compress16-lossless targets - Fix innocuous UBSan warnings uncovered by the new fuzzers. - Implement previous versions of the TurboJPEG API by wrapping the new functions (tested by running the 2.1.x versions of TJBench, via tjbenchtest, and TJUnitTest against the new implementation.) * Remove all JNI functions for deprecated Java methods and implement the deprecated methods using pure Java wrappers. It should be understood that backward API compatibility in Java applies only to the Java classes and that one cannot mix and match a JAR file from one version of libjpeg-turbo with a JNI library from another version. - tj3Destroy() now silently accepts a NULL handle. - tj3Alloc() and tj3Free() now return/accept void pointers, as malloc() and free() do. - The image I/O functions now accept a TurboJPEG instance handle, which is used to transmit/receive parameters and to receive error information. Closes #517
DRC d4589f4f 2023-01-14T18:07:53 Merge branch 'main' into dev
DRC d2608583 2023-01-05T10:51:12 TurboJPEG: Ensure 'pad' arg is a power of 2 Because the PAD() macro can only handle powers of 2, this is a necessary restriction (and a documented one, except in the case of tjCompressFromYUV()-- oops.) Failing to check the 'pad' argument caused tjBufSizeYUV2() to return bogus results if 'pad' was less than 1 or otherwise not a power of 2. tjEncodeYUV3() and tjDecodeYUV() effectively treated a 'pad' value of 0 as unpadded, but that was subtle and undocumented behavior. tjCompressFromYUV() did not check whether 'pad' was a power of 2, so the strides passed to tjCompressFromYUVPlanes() would have been incorrect if 'pad' was not a power of 2. That would not have caused tjCompressFromYUV() to overrun the source buffer, as long as the calling application allocated the buffer based on the return value of tjBufSizeYUV2() (which computes the strides in the same manner as tjCompressFromYUV().) However, if the calling application attempted to initialize the source buffer using correctly-computed strides, then it could have overrun its own buffer in certain cases or produced incorrect JPEG images in others. Realistically, there is no reason why an application would want to pass a non-power-of-2 'pad' value to a TurboJPEG API function, so this commit is about user-proofing the API rather than fixing any known issue.
DRC 2241434e 2022-12-15T12:20:50 16-bit lossless JPEG support
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 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 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 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 97772cba 2022-11-14T15:36:25 Merge branch 'ijg.lossless' into dev Refer to #402
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 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 cb3642cb 2022-11-03T12:22:51 Bump version to 2.1.5 to prepare for new commits
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 b98dabac 2022-04-27T12:38:58 Merge branch 'main' into dev
DRC d0e7c454 2022-04-18T11:34:07 Don't install libturbojpeg.pc if WITH_TURBOJPEG=0 Fixes #593
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 263386c2 2022-03-11T17:35:59 Merge branch 'main' into dev
kmx.io     mail     discord kmxgit v0.4.0