kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
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 bf2c1efb 2025-09-25T11:11:01 Build: Use correct compress12_lossless fuzzer src (oops)
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 8af737ed 2025-09-23T08:26:20 ChangeLog.md: List CVE ID for 2a9e3bd7 and c30b1e7
DRC 5e27ca23 2025-09-19T14:21:49 x86: Reformat NASM code to improve readability (and simplify the checkstyle script)
DRC 42d2a243 2025-09-10T13:06:51 Build: Fix Loongson MMI detection with -Werror If compiler warnings are treated as errors, then the apostrophe in "Loongson MMI can't work with MIPS Release 6+" triggers a compiler warning that causes the HAVE_MMI test to fail. Surrounding the error message with quotes fixes the issue.
DRC 4e151a4a 2025-08-26T21:11:07 Remove vestigial filenames from SIMD code headers These were a relic of libjpeg/SIMD, which attempted to follow the conventions of the libjpeg source code, but they are no longer relevant (or even accurate in some cases.)
DRC 98c45838 2025-08-21T11:22:51 Fix issues with Windows Arm64EC builds Arm64EC basically wraps native Arm64 functions with an emulated Windows/x64 ABI, which can improve performance for Windows/x64 applications running under the x64 emulator on Windows/Arm. When building for Arm64EC, the compiler defines _M_X64 and _M_ARM64EC but not _M_ARM64.
DRC f2d1f1cb 2025-08-08T12:12:40 Build, LICENSE.md: Update copyright year
DRC f158143e 2025-07-28T20:45:02 jpeg_skip_scanlines: Fix UAF w/merged upsamp/quant jpeg_skip_scanlines() (more specifically, read_and_discard_scanlines()) should check whether merged upsampling is disabled before attempting to dereference cinfo->cconvert, and it should check whether color quantization is enabled before attempting to dereference cinfo->cquantize. Otherwise, executing one of the following sequences with the same libjpeg API instance and any 4:2:0 or 4:2:2 JPEG image will cause a use-after-free issue: - Disable merged upsampling (default) - jpeg_start_decompress() - jpeg_finish_decompress() (frees but doesn't zero cinfo->cconvert) - Enable merged upsampling - jpeg_start_decompress() (doesn't re-allocate cinfo->cconvert, because j*init_color_deconverter() isn't called) - jpeg_skip_scanlines() - Enable 1-pass color quantization - jpeg_start_decompress() - jpeg_finish_decompress() (frees but doesn't zero cinfo->cquantize) - Disable 1-pass color quantization - jpeg_start_decompress() (doesn't re-allocate cinfo->cquantize, because j*init_*_quantizer() isn't called) - jpeg_skip_scanlines() These sequences are very unlikely to occur in a real-world application. In practice, this issue does not even cause a segfault or other user-visible errant behavior, so it is only detectable with ASan. That is because the memory region is small enough that it doesn't get reclaimed by either the application or the O/S between the point at which it is freed and the point at which it is used (even though a subsequent malloc() call requests exactly the same amount of memory.) Thus, this is an undefined behavior issue, but it is unlikely to be exploitable.
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 d95f62f0 2025-06-11T16:04:09 CI/Win: Deploy build log with pre-release packages
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 d163c99b 2025-05-19T11:14:47 CI/Win: Fix release signing GitHub Actions automatically creates a zip file from artifacts, so we don't need to create it ourselves.
DRC 085e0a7b 2025-05-19T10:35:02 CI/Win: Don't deploy tag builds to AWS AWS is used for pre-releases, and tag builds are used for final releases.
DRC 63a2fd87 2025-05-18T09:43:36 CI/Win: Fix caching of installers The cache action needs to run before the build setup.
DRC 024e10f3 2025-05-18T08:49:12 CI: Trigger Windows build when a tag is pushed AppVeyor ran our CI build when both branches and tags were pushed. This is necessary to support signing with SignPath.io, since we only sign releases and not pre-releases. However, due to an oversight in 9af8cca75c098e8fb5afaa20e859b705f7189020, the global on: dictionary excluded tag pushes. To simulate the previous AppVeyor CI environment: - Run all jobs regardless of whether a branch or a tag was pushed. - Use the if: key to exclude all jobs except "windows" from tag pushes.
DRC 0bf81664 2025-05-17T17:21:13 CI: Move strict MSVC comp. wrngs. to build scripts
DRC 9af8cca7 2025-05-13T17:00:20 CI: Use GitHub Actions for Windows builds
DRC 4c72bb80 2025-05-13T17:00:20 Build/CI: Officially support Windows/Arm - Use Visual Studio 2022 for CI builds. - Rename installers to clearly distinguish x86, x64, and Arm64 versions. NOTE: The Windows/Arm installer uses the same internal name and install directory as the Windows/x64 installer. That is consistent with the behavior of the Linux packages. Because the installer places turbojpeg.dll into C:\WINDOWS\System32, it would normally be impossible to co-install the x64 and Arm64 versions anyhow. (That can still be accomplished. You just have to use 7-Zip to extract one of the installers into a non-default directory.)
DRC 66771223 2025-05-13T10:33:15 cjpeg: Free ICC profile if API error when fuzzing Fixes #809
DRC 2a0c8627 2025-04-03T13:05:01 Fuzz: Fix -Wsign-compare warnings
DRC 2f26b48f 2025-04-02T13:59:17 Mac pkg: Fix issues that prevent notarization - Explicitly sign all binaries included in the package. - Enable the hardened runtime.
DRC adbb3281 2025-02-25T14:52:48 GitHub: Use GCC 11 for linux-jpeg7 job GCC 12 and later throw a false positive with -Wstringop-overflow=4.
DRC f210df79 2025-02-25T14:10:36 GitHub: Don't test x32 ABI The ubuntu-20.04 hosted runner image is going away on April 1, and newer versions of Ubuntu can build but not run x32 binaries. The x32 ABI seems to be mostly dead, but we can still regression test x32 support using a local Ubuntu 20.04 VM if necessary. (That shouldn't be necessary unless the x86-64 SIMD extensions change at some point in the future.)
DRC 36ac5b84 2025-02-17T17:50:44 GitHub: Use Clang 17 rather than Clang 14 The ubuntu-latest runner image now runs Ubuntu 24.04 rather than 22.04.
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 cc095fee 2024-12-18T09:39:53 Build: Generate 32-bit supplementary ppc64 .deb As with x86-64, the Power ISA basically implements 64-bit instructions as extensions of their 32-bit counterparts. Thus, 64-bit Power ISA CPUs can natively execute legacy 32-bit PowerPC instructions when running in big-endian mode. Most Power ISA support has shifted (pun intended) to little-endian mode, so there are few remaining operating systems that support big-endian mode. Debian is one of them, however (albeit unofficially.)
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 84fa3bc0 2024-12-11T17:39:02 tjTransform(): Fix false positive compiler warning
DRC 602f0592 2024-12-12T00:09:34 AltiVec: Disable/Fix some strict compiler warnings We use a standard set of strict compiler warnings with Clang and GCC to continuously test and maintain C89 conformance in the libjpeg API code. However, SIMD extensions need not comply with that. The AltiVec code specifically uses some C99isms, so disable -Wc99-extensions and -Wpedantic in the scope of that code. Also disable -Wshadow, because I'm too lazy to fix the TRANSPOSE() macro. Also use #ifdef __BIG_ENDIAN__ and #if defined(__BIG_ENDIAN__) instead of #if __BIG_ENDIAN__
DRC ea4ee229 2024-12-11T16:51:39 Neon: Disable some strict compiler warnings We use a standard set of strict compiler warnings with Clang and GCC to continuously test and maintain C89 conformance in the libjpeg API code. However, SIMD extensions need not comply with that. The Neon code specifically uses some C99isms, so disable -Wdeclaration-after-statement, -Wc99-extensions, and -Wpedantic in the scope of that code. Also modify the Neon feature tests so that they will succeed if any of the aforementioned compiler warnings are enabled.
DRC be7a0c8b 2024-12-11T12:25:16 Build: Make Mac packaging architecture-agnostic Rename the ARMV8_BUILD CMake variable to SECONDARY_BUILD, and modify the makemacpkg script so that it allows any architecture in a primary or secondary build. The idea is that Apple Silicon users can package an arm64 primary build and a secondary x86_64 build, and Intel users can package an x86_64 primary build and a secondary arm64 build, using the same procedure. Also simplify the iOS build instructions, using the CMAKE_OSX_ARCHITECTURES variable rather than a toolchain.
DRC 9758c8a7 2024-11-18T13:40:08 Exclude more code if !(C|D)_LOSSLESS_SUPPORTED
DRC 6bace81b 2024-10-31T11:54:32 Fix OSS-Fuzz decompress_yuv fuzzer MSan failure
DRC d7932a27 2024-10-30T12:12:03 TJ doc: Density params require YCbCr or grayscale Since libjpeg-turbo does not support Exif, the only way it can embed density information in a JPEG image is by using the JFIF marker, which is only written if the JPEG colorspace is YCbCr or grayscale. (Referring to the conversation under #793, we may need to further restrict that to 8-bit-per-sample JPEG images, because the JFIF spec requires 8-bit data precision.)
DRC 6da05150 2024-10-24T13:25:10 Allow disabling prog/opt/lossless if prev. enabled - Due to an oversight, a113506d175d03ae0e40965c3d3d21a5d561e119 (libjpeg-turbo 1.4 beta1) effectively made the call to std_huff_tables() in jpeg_set_defaults() a no-op if the Huffman tables were previously defined, which made it impossible to disable Huffman table optimization or progressive mode if they were previously enabled in the same API instance. std_huff_tables() retains its previous behavior for decompression instances, but it now force-enables the standard (baseline) Huffman tables for compression instances. - Due to another oversight, there was no way to disable lossless mode if it was previously enabled in a particular API instance. jpeg_set_defaults() now accomplishes this, which makes TJ*PARAM_LOSSLESS behave as intended/documented. - Due to yet another oversight, setCompDefaults() in the TurboJPEG API library permanently modified the value of TJ*PARAM_SUBSAMP when generating a lossless JPEG image, which affected subsequent lossy compression operations. This issue was hidden by the issue above and thus does not need to be publicly documented. Fixes #792
DRC befabe2c 2024-10-23T18:06:09 GitHub: Use macos-13 runner image w/ Xcode 14.2 (macos-12 is deprecated.)
DRC a927b489 2024-09-24T10:46:40 LICENSE.md: Update copyright year
DRC bfe77d31 2024-09-23T15:30:45 ChangeLog: Document accidental fix from 9983840e Closes #789
DRC 1b1356a5 2024-09-23T15:18:53 TJComp: Explicitly specify data precision This is just a code readability thing. The logic effectively caused the data precision to default to 8 if -precision was not specified, but that was not obvious. This commit also modifies tjcomptest so that it tests TJComp with no -precision argument, to ensure that the data precision defaults to 8.
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 0d58f099 2024-09-14T12:50:36 TJTran: ICC profiles are now supported
DRC 6d02718d 2024-09-14T12:42:12 JNI: Guard against int. overflow w/ ICC profiles
DRC 9b01f5a0 2024-09-14T11:56:14 TJ: Add func/method for computing xformed buf size
DRC 5b099580 2024-09-14T11:13:07 Merge branch 'main' into dev
DRC f29eda64 2024-09-14T10:29:56 tj3Transform: Don't calc dst subsamp unless needed This just improves code readability by emphasizing that we don't care about the destination image's level of subsampling unless TJPARAM_NOREALLOC is set or lossless cropping will be performed.
DRC 437a4993 2024-09-12T21:11:00 Merge branch 'main' into dev
DRC bcbca8b9 2024-09-12T20:55:39 Fuzz: Calc. xformed buf size based on dst. subsamp (oversight from b3f0abe377f2dd83396c9d0d4176f684c122af3f)
DRC 6f1fe2d1 2024-09-09T10:52:18 turbojpeg-jni.c: Fix int. conv. warnings w/ VC++
DRC e3e353fe 2024-09-06T20:30:03 tjunittest.c: Store/retrieve original buf size ... ... between iterations. (oversight from c519d7b67913e69b667f5fac49650f825e56218d)
DRC a2728582 2024-09-03T07:54:17 TurboJPEG: ICC profile support
DRC c6de7d87 2024-09-06T09:21:47 tjdecomp.c: Remove extraneous #defines
DRC c519d7b6 2024-09-05T11:10:44 Don't ignore JPEG buf size with TJPARAM_NOREALLOC Since the introduction of TJFLAG_NOREALLOC in libjpeg-turbo 1.2.x, the TurboJPEG C API documentation has (confusingly) stated that: - if the JPEG buffer pointer points to a pre-allocated buffer, then the JPEG buffer size must be specified, and - the JPEG buffer size should be specified if the JPEG buffer is pre-allocated to an arbitrary size. The documentation never explicitly stated that the JPEG buffer size should be specified if the JPEG buffer is pre-allocated to a worst-case size, but since focus does not imply exclusion, it also never explicitly stated the reverse. Furthermore, the documentation never stated that this was contingent upon TJPARAM_NOREALLOC/TJFLAG_NOREALLOC. However, effectively the compression and lossless transformation functions ignored the JPEG buffer size(s) passed to them, and assumed that the JPEG buffer(s) had been allocated to a worst-case size, if TJPARAM_NOREALLOC/TJFLAG_NOREALLOC was set. This behavior was an accidental and undocumented throwback to libjpeg-turbo 1.1.x, in which the tjCompress() function provided no way to specify the JPEG buffer size. It was always a bad idea for applications to rely upon that behavior (although our own TJBench application unfortunately did.) However, if such applications exist in the wild, the new behavior would constitute a breaking change, so it has been introduced only into libjpeg-turbo 3.1.x and only into TurboJPEG 3 API functions. The previous behavior has been retained when calling functions from the TurboJPEG 2.1.x API and prior versions. Did I mention that APIs are hard?
DRC 5f05c75a 2024-09-06T19:55:20 Merge branch 'main' into dev
DRC b3f0abe3 2024-09-06T10:23:02 TJ: Calc. xformed buf sizes based on dst. subsamp With respect to tj3Transform(), this addresses an oversight from bb1d540a807783a3db8b85bab2993d70b1330287. Note to self: A convenience function/method for computing the worst-case transformed JPEG size for a particular transform would be nice.
DRC 6d959170 2024-09-05T21:57:16 Minor TurboJPEG doc tweaks - When transforming, the worst-case JPEG buffer size depends on the subsampling level used in the destination image, since a grayscale transform might have been applied. - Parentheses Police
DRC e3dac188 2024-09-05T17:07:50 Merge branch 'main' into dev
DRC 2e40a687 2024-09-05T16:49:44 turbojpeg.c: Fix -Wsign-compare compiler warning (introduced by previous commit)
DRC 8db41dad 2024-09-05T15:15:08 Merge branch 'main' into dev
DRC 758e8a8e 2024-09-05T14:55:50 Java: Use Java-style method nomenclature :: is a C++ thing.
DRC fe1e555a 2024-09-05T14:45:53 tjbenchtest.in: Grammar Police
DRC bb1d540a 2024-09-05T12:00:04 TJ: Explicitly reject OOB lossless crop regions tj*Transform() relied upon the underlying transupp API to check the cropping region. However, transupp uses unsigned integers for the cropping region, whereas the tjregion structure uses signed integers. Thus, casting negative values from a tjregion structure produced very large unsigned values. In the case of the left and upper boundary, this was innocuous, because jtransform_request_workspace() rejected the values as being out of bounds. However, jtransform_request_workspace() did not always reject very large width and height values, because it supports expanding the destination image by specifying a cropping region larger than the source image. In certain cases, it allowed those values, and the libjpeg memory manager subsequently ran out of memory. NOTE: Prior to this commit, image expansion technically worked with tj*Transform() as long as the cropping width and height were valid and automatic JPEG buffer (re)allocation was used. However, that behavior is not a documented feature of the TurboJPEG API, nor do we have any way of testing it at the moment. Official support for image expansion can be added later, if there is sufficient demand for it. Similarly, this commit modifies tj3SetCroppingRegion() so that it explicitly checks for left boundary values exactly equal to the scaled image width and upper boundary values exactly equal to the scaled image height. If the specified cropping width or height was 0 (which is interpreted as {scaled image width} - {left boundary} or {scaled image height} - {upper boundary}), then such values caused a cropping width or height of 0 to be passed to the libjpeg API. In the case of the width, this was innocuous, because jpeg_crop_scanline() rejected the value. In the case of the height, however, this caused unexpected and hard-to-diagnose errors farther down the pipeline.
DRC e4c67aff 2024-09-04T12:06:42 TJBench: More argument consistification -copynone --> -copy none Add '-copy all', even though it's the default. -rgb, -bgr, -rgbx, -bgrx, -xbgr, -xrgb, -gray, -cmyk --> -pixelformat {rgb|bgr|rgbx|bgrx|xbgr|xrgb|gray|cmyk} (This is mainly so -gray won't interfere with -grayscale.) Fix an ArrayIndexOutOfBoundsException that occurred when passing -dct to the Java version without specifying the DCT algorithm (oversight from 24fbf64d31a0758c63bcc27cf5d92fc5611717d0.)
DRC d43ed7a1 2024-09-04T08:38:13 Merge branch 'main' into dev
DRC dd8b15ee 2024-09-04T07:52:51 tjbenchtest.in: Formatting tweak (oversight from a5689cd45ba290bcf698a172d24c74aada8c5595)
DRC e7e9344d 2024-09-04T06:58:48 TJ: Honor TJ*OPT_COPYNONE for individual xforms jcopy_markers_execute() has historically ignored its option argument, which is OK for jpegtran, but tj*Transform() needs to be able to save a set of markers from the source image and write a subset of those markers to each destination image. Without that ability, the function effectively behaved as if TJ*OPT_COPYNONE was not specified unless all transforms specified it.
DRC 5550c80f 2024-09-03T17:20:10 Doc: "compress operation"="compression operation" (consistification)
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 a5689cd4 2024-09-03T15:26:52 Test: Replace big_tree8.bmp and big_building16.ppm These images were only used with tjbenchtest and tjexampletest, but I was concerned about introducing additional licensing provisions into the libjpeg-turbo source tree. Thus, this commit replaces them with images that I own and can thus make available under the libjpeg-turbo licenses with no additional provisions.
DRC a4d19a45 2024-09-03T09:27:04 Merge branch 'main' into dev
DRC 37851a32 2024-09-01T15:07:27 TurboJPEG: Add restart markers when transforming
DRC f5f8f5aa 2024-09-03T08:59:37 TJ: Reorder functions to improve readability Put all general functions at the top of the list, and ensure that all functions are defined before they are mentioned. Also consistify the function ordering between turbojpeg.h and turbojpeg.c
DRC a66398fe 2024-09-02T08:52:42 Move md5cmp/md5sum into ${CMAKE_BINARY_DIR}/test
DRC f0bc90d9 2024-09-02T08:44:49 Test: Move test logs into ${CMAKE_BINARY_DIR}/test
DRC df04d26a 2024-09-01T16:24:19 Test: Clean up TurboJPEG example test logs
DRC f464728a 2024-09-02T08:00:08 ChangeLog.md: Minor wordsmithing
DRC debf57bc 2024-09-01T10:59:35 TJBench: Improve usage screen readability
DRC fad61007 2024-08-20T18:52:53 Replace TJExample with IJG workalike programs
DRC 6d9f1f81 2024-09-01T14:04:20 Merge branch 'main' into dev
DRC 843d04d9 2024-09-01T11:52:01 CI: Run regression tests in parallel
DRC 797c6ccd 2024-09-01T11:23:31 Doc: Further clarify MCU definition
DRC 7f45663d 2024-09-01T10:05:57 Merge branch 'main' into dev
DRC 7ec70ee8 2024-09-01T09:59:10 testclean.cmake: Remove croptest.log
DRC 174672af 2024-09-01T09:55:52 jquant1.c: Formatting tweak Extending the Bayer matrix past Column 80 seems like a lesser readability sin than not putting a space after each comma, especially since we had to explicitly whitelist the file in checkstyle.
DRC 3e303e72 2024-08-31T18:38:05 TJBench: Allow British spellings in arguments
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 eb753630 2024-08-31T16:50:08 Update URLs - Eliminate unnecessary "www." - Use HTTPS. - Update Java, MSYS, tdm-gcc, and NSIS URLs. - Update URL and title of Agner Fog's assembly language optimization manual. - Remove extraneous information about MASM and Borland Turbo Assembler and outdated NASM URLs from the x86 assembly headers, and mention Yasm.
DRC 0fb8fbe1 2024-08-31T15:39:34 CMakeLists.txt: libjpeg-turbo "2.2.x" = "3.0.x"
DRC 8d76e4e5 2024-08-31T15:33:55 Doc: "EXIF" = "Exif"
DRC 9983840e 2024-08-31T12:41:13 TJ/xform: Check crop region against dest. image Lossless cropping is performed after other lossless transform operations, so the cropping region must be specified relative to the destination image dimensions and level of chrominance subsampling, not the source image dimensions and level of chrominance subsampling. More specifically, if the lossless transform operation swaps the X and Y axes, or if the image is converted to grayscale, then that changes the cropping region requirements.
kmx.io     mail     discord kmxgit v0.4.0