kmx git

Commit	Date	Message
f2d1f1cb	2025-08-08T12:12:40	Build, LICENSE.md: Update copyright year
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 jinit_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 jinit_*_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.
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.)
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
91b3d4be	2025-06-14T07:19:17	CMakeLists.txt: Formatting tweak
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
c889b1da	2025-06-12T09:40:20	TJBench: Require additional argument with -copy (oversight from e4c67aff50420d7bacff503ceb4556c896128413)
d95f62f0	2025-06-11T16:04:09	CI/Win: Deploy build log with pre-release packages
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
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.
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.
63a2fd87	2025-05-18T09:43:36	CI/Win: Fix caching of installers The cache action needs to run before the build setup.
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.
0bf81664	2025-05-17T17:21:13	CI: Move strict MSVC comp. wrngs. to build scripts
9af8cca7	2025-05-13T17:00:20	CI: Use GitHub Actions for Windows builds
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.)
66771223	2025-05-13T10:33:15	cjpeg: Free ICC profile if API error when fuzzing Fixes #809
2a0c8627	2025-04-03T13:05:01	Fuzz: Fix -Wsign-compare warnings
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.
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.
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.)
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.
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().
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.)
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.
c3446d64	2024-12-12T11:01:53	Bump version to 3.1.0
84fa3bc0	2024-12-11T17:39:02	tjTransform(): Fix false positive compiler warning
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__
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.
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.
9758c8a7	2024-11-18T13:40:08	Exclude more code if !(C\|D)_LOSSLESS_SUPPORTED
6bace81b	2024-10-31T11:54:32	Fix OSS-Fuzz decompress_yuv fuzzer MSan failure
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.)
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 TJPARAM_LOSSLESS behave as intended/documented. - Due to yet another oversight, setCompDefaults() in the TurboJPEG API library permanently modified the value of TJPARAM_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
befabe2c	2024-10-23T18:06:09	GitHub: Use macos-13 runner image w/ Xcode 14.2 (macos-12 is deprecated.)
a927b489	2024-09-24T10:46:40	LICENSE.md: Update copyright year
bfe77d31	2024-09-23T15:30:45	ChangeLog: Document accidental fix from 9983840e Closes #789
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.
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.
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
a9f7490c	2024-09-14T16:09:15	Build: Fix typo
9d76821f	2024-09-14T16:00:53	3.1 beta1
0d58f099	2024-09-14T12:50:36	TJTran: ICC profiles are now supported
6d02718d	2024-09-14T12:42:12	JNI: Guard against int. overflow w/ ICC profiles
9b01f5a0	2024-09-14T11:56:14	TJ: Add func/method for computing xformed buf size
5b099580	2024-09-14T11:13:07	Merge branch 'main' into dev
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.
437a4993	2024-09-12T21:11:00	Merge branch 'main' into dev
bcbca8b9	2024-09-12T20:55:39	Fuzz: Calc. xformed buf size based on dst. subsamp (oversight from b3f0abe377f2dd83396c9d0d4176f684c122af3f)
6f1fe2d1	2024-09-09T10:52:18	turbojpeg-jni.c: Fix int. conv. warnings w/ VC++
e3e353fe	2024-09-06T20:30:03	tjunittest.c: Store/retrieve original buf size ... ... between iterations. (oversight from c519d7b67913e69b667f5fac49650f825e56218d)
a2728582	2024-09-03T07:54:17	TurboJPEG: ICC profile support
c6de7d87	2024-09-06T09:21:47	tjdecomp.c: Remove extraneous #defines
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?
5f05c75a	2024-09-06T19:55:20	Merge branch 'main' into dev
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.
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
e3dac188	2024-09-05T17:07:50	Merge branch 'main' into dev
2e40a687	2024-09-05T16:49:44	turbojpeg.c: Fix -Wsign-compare compiler warning (introduced by previous commit)
8db41dad	2024-09-05T15:15:08	Merge branch 'main' into dev
758e8a8e	2024-09-05T14:55:50	Java: Use Java-style method nomenclature :: is a C++ thing.
fe1e555a	2024-09-05T14:45:53	tjbenchtest.in: Grammar Police
bb1d540a	2024-09-05T12:00:04	TJ: Explicitly reject OOB lossless crop regions tjTransform() 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 tjTransform() 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.
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.)
d43ed7a1	2024-09-04T08:38:13	Merge branch 'main' into dev
dd8b15ee	2024-09-04T07:52:51	tjbenchtest.in: Formatting tweak (oversight from a5689cd45ba290bcf698a172d24c74aada8c5595)
e7e9344d	2024-09-04T06:58:48	TJ: Honor TJOPT_COPYNONE for individual xforms jcopy_markers_execute() has historically ignored its option argument, which is OK for jpegtran, but tjTransform() 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.
5550c80f	2024-09-03T17:20:10	Doc: "compress operation"="compression operation" (consistification)
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.)
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.
a4d19a45	2024-09-03T09:27:04	Merge branch 'main' into dev
37851a32	2024-09-01T15:07:27	TurboJPEG: Add restart markers when transforming
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
a66398fe	2024-09-02T08:52:42	Move md5cmp/md5sum into ${CMAKE_BINARY_DIR}/test
f0bc90d9	2024-09-02T08:44:49	Test: Move test logs into ${CMAKE_BINARY_DIR}/test
df04d26a	2024-09-01T16:24:19	Test: Clean up TurboJPEG example test logs
f464728a	2024-09-02T08:00:08	ChangeLog.md: Minor wordsmithing
debf57bc	2024-09-01T10:59:35	TJBench: Improve usage screen readability
fad61007	2024-08-20T18:52:53	Replace TJExample with IJG workalike programs
6d9f1f81	2024-09-01T14:04:20	Merge branch 'main' into dev
843d04d9	2024-09-01T11:52:01	CI: Run regression tests in parallel
797c6ccd	2024-09-01T11:23:31	Doc: Further clarify MCU definition
7f45663d	2024-09-01T10:05:57	Merge branch 'main' into dev
7ec70ee8	2024-09-01T09:59:10	testclean.cmake: Remove croptest.log
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.
3e303e72	2024-08-31T18:38:05	TJBench: Allow British spellings in arguments
9b119896	2024-08-31T17:46:37	Move test scripts into test/
64567381	2024-08-31T17:31:02	Merge branch 'main' into dev
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.
0fb8fbe1	2024-08-31T15:39:34	CMakeLists.txt: libjpeg-turbo "2.2.x" = "3.0.x"
8d76e4e5	2024-08-31T15:33:55	Doc: "EXIF" = "Exif"
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.
8456d2b9	2024-08-30T10:50:13	Doc: "MCU block" = "iMCU" or "MCU" The JPEG-1 spec never uses the term "MCU block". That term is rarely used in other literature to describe the equivalent of an MCU in an interleaved JPEG image, but the libjpeg documentation uses "iMCU" to describe the same thing. "iMCU" is a better term, since the equivalent of an interleaved MCU can contain multiple DCT blocks (or samples in lossless mode) that are only grouped together if the image is interleaved. In the case of restart markers, "MCU block" was used in the libjpeg documentation instead of "MCU", but "MCU" is more accurate and less confusing. (The restart interval is literally in MCUs, where one MCU is one data unit in a non-interleaved JPEG image and multiple data units in a multi-component interleaved JPEG image.) In the case of 9b704f96b2dccc54363ad7a2fe8e378fc1a2893b, the issue was actually with progressive JPEG images exactly two DCT blocks wide, not two MCU blocks wide. This commit also defines "MCU" and "MCU row" in the description of the various restart marker options/parameters. Although an MCU row is technically always a row of samples in lossless mode, "sample row" was confusing, since it is used in other places to describe a row of samples for a single component (whereas an MCU row in a typical lossless JPEG image consists of a row of interleaved samples for all components.)
2858783d	2024-08-28T18:16:18	JNI: Set srcX, srcY = 0 in loadSourceImage() (oversight from 79b8d65f0f86af77afc5979ecc104b1fbc97c82d)
4ceaf8b7	2024-08-26T10:31:19	TJBench: Allow 'X' in crop spec (for consistency with djpeg and jpegtran)
fd9b21b6	2024-08-28T18:58:21	Merge branch 'main' into dev
5cf79606	2024-08-28T18:36:37	Undocument TJPARAM_RESTARTBLOCKS for lossless TJPARAM_RESTARTBLOCKS technically works with lossless compression, but it is not useful, since the value must be equal to the number of samples in a row. (In other words, it is no different than TJ*PARAM_RESTARTINROWS, except that it requires the user to do more math.)
d6207971	2024-08-28T18:00:14	TJBench: Don't override subsamp until args parsed Otherwise, passing -subsamp after -lossless might cause the worst-case JPEG buffer size to be too small.
c72bbd9c	2024-08-26T18:00:23	tjbench.c: (Re)allow unreduced scaling factors For reasons I can't recall, fc01f4673b71c0b833c59c21e8c4478a9c4bcf21 (the TurboJPEG 3 API overhaul) changed the C version of TJBench, but not the Java version, so that it requires an exact scaling factor match (as opposed to allowing unreduced scaling factors, as djpeg does and prior versions of TJBench did.) That might have been temporary testing code that was accidentally committed.
6a9565ce	2024-08-26T16:45:41	Merge branch 'main' into dev

f2d1f1cb

2025-08-08T12:12:40

Build, LICENSE.md: Update copyright year

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.

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.)

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

91b3d4be

2025-06-14T07:19:17

CMakeLists.txt: Formatting tweak

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

c889b1da

2025-06-12T09:40:20

TJBench: Require additional argument with -copy (oversight from e4c67aff50420d7bacff503ceb4556c896128413)

d95f62f0

2025-06-11T16:04:09

CI/Win: Deploy build log with pre-release packages

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

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.

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.

63a2fd87

2025-05-18T09:43:36

CI/Win: Fix caching of installers The cache action needs to run before the build setup.

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.

0bf81664

2025-05-17T17:21:13

CI: Move strict MSVC comp. wrngs. to build scripts

9af8cca7

2025-05-13T17:00:20

CI: Use GitHub Actions for Windows builds

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.)

66771223

2025-05-13T10:33:15

cjpeg: Free ICC profile if API error when fuzzing Fixes #809

2a0c8627

2025-04-03T13:05:01

Fuzz: Fix -Wsign-compare warnings

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.

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.

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.)

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.

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().

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.)

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.

c3446d64

2024-12-12T11:01:53

Bump version to 3.1.0

84fa3bc0

2024-12-11T17:39:02

tjTransform(): Fix false positive compiler warning

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__

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.

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.

9758c8a7

2024-11-18T13:40:08

Exclude more code if !(C|D)_LOSSLESS_SUPPORTED

6bace81b

2024-10-31T11:54:32

Fix OSS-Fuzz decompress_yuv fuzzer MSan failure

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.)

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

befabe2c

2024-10-23T18:06:09

GitHub: Use macos-13 runner image w/ Xcode 14.2 (macos-12 is deprecated.)

a927b489

2024-09-24T10:46:40

LICENSE.md: Update copyright year

bfe77d31

2024-09-23T15:30:45

ChangeLog: Document accidental fix from 9983840e Closes #789

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.

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.

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

a9f7490c

2024-09-14T16:09:15

Build: Fix typo

9d76821f

2024-09-14T16:00:53

3.1 beta1

0d58f099

2024-09-14T12:50:36

TJTran: ICC profiles are now supported

6d02718d

2024-09-14T12:42:12

JNI: Guard against int. overflow w/ ICC profiles

9b01f5a0

2024-09-14T11:56:14

TJ: Add func/method for computing xformed buf size

5b099580

2024-09-14T11:13:07

Merge branch 'main' into dev

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.

437a4993

2024-09-12T21:11:00

Merge branch 'main' into dev

bcbca8b9

2024-09-12T20:55:39

Fuzz: Calc. xformed buf size based on dst. subsamp (oversight from b3f0abe377f2dd83396c9d0d4176f684c122af3f)

6f1fe2d1

2024-09-09T10:52:18

turbojpeg-jni.c: Fix int. conv. warnings w/ VC++

e3e353fe

2024-09-06T20:30:03

tjunittest.c: Store/retrieve original buf size ... ... between iterations. (oversight from c519d7b67913e69b667f5fac49650f825e56218d)

a2728582

2024-09-03T07:54:17

TurboJPEG: ICC profile support

c6de7d87

2024-09-06T09:21:47

tjdecomp.c: Remove extraneous #defines

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?

5f05c75a

2024-09-06T19:55:20

Merge branch 'main' into dev

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.

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

e3dac188

2024-09-05T17:07:50

Merge branch 'main' into dev

2e40a687

2024-09-05T16:49:44

turbojpeg.c: Fix -Wsign-compare compiler warning (introduced by previous commit)

8db41dad

2024-09-05T15:15:08

Merge branch 'main' into dev

758e8a8e

2024-09-05T14:55:50

Java: Use Java-style method nomenclature :: is a C++ thing.

fe1e555a

2024-09-05T14:45:53

tjbenchtest.in: Grammar Police

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.

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.)

d43ed7a1

2024-09-04T08:38:13

Merge branch 'main' into dev

dd8b15ee

2024-09-04T07:52:51

tjbenchtest.in: Formatting tweak (oversight from a5689cd45ba290bcf698a172d24c74aada8c5595)

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.

5550c80f

2024-09-03T17:20:10

Doc: "compress operation"="compression operation" (consistification)

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.)

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.

a4d19a45

2024-09-03T09:27:04

Merge branch 'main' into dev

37851a32

2024-09-01T15:07:27

TurboJPEG: Add restart markers when transforming

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

a66398fe

2024-09-02T08:52:42

Move md5cmp/md5sum into ${CMAKE_BINARY_DIR}/test

f0bc90d9

2024-09-02T08:44:49

Test: Move test logs into ${CMAKE_BINARY_DIR}/test

df04d26a

2024-09-01T16:24:19

Test: Clean up TurboJPEG example test logs

f464728a

2024-09-02T08:00:08

ChangeLog.md: Minor wordsmithing

debf57bc

2024-09-01T10:59:35

TJBench: Improve usage screen readability

fad61007

2024-08-20T18:52:53

Replace TJExample with IJG workalike programs

6d9f1f81

2024-09-01T14:04:20

Merge branch 'main' into dev

843d04d9

2024-09-01T11:52:01

CI: Run regression tests in parallel

797c6ccd

2024-09-01T11:23:31

Doc: Further clarify MCU definition

7f45663d

2024-09-01T10:05:57

Merge branch 'main' into dev

7ec70ee8

2024-09-01T09:59:10

testclean.cmake: Remove croptest.log

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.

3e303e72

2024-08-31T18:38:05

TJBench: Allow British spellings in arguments

9b119896

2024-08-31T17:46:37

Move test scripts into test/

64567381

2024-08-31T17:31:02

Merge branch 'main' into dev

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.

0fb8fbe1

2024-08-31T15:39:34

CMakeLists.txt: libjpeg-turbo "2.2.x" = "3.0.x"

8d76e4e5

2024-08-31T15:33:55

Doc: "EXIF" = "Exif"

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.

8456d2b9

2024-08-30T10:50:13

Doc: "MCU block" = "iMCU" or "MCU" The JPEG-1 spec never uses the term "MCU block". That term is rarely used in other literature to describe the equivalent of an MCU in an interleaved JPEG image, but the libjpeg documentation uses "iMCU" to describe the same thing. "iMCU" is a better term, since the equivalent of an interleaved MCU can contain multiple DCT blocks (or samples in lossless mode) that are only grouped together if the image is interleaved. In the case of restart markers, "MCU block" was used in the libjpeg documentation instead of "MCU", but "MCU" is more accurate and less confusing. (The restart interval is literally in MCUs, where one MCU is one data unit in a non-interleaved JPEG image and multiple data units in a multi-component interleaved JPEG image.) In the case of 9b704f96b2dccc54363ad7a2fe8e378fc1a2893b, the issue was actually with progressive JPEG images exactly two DCT blocks wide, not two MCU blocks wide. This commit also defines "MCU" and "MCU row" in the description of the various restart marker options/parameters. Although an MCU row is technically always a row of samples in lossless mode, "sample row" was confusing, since it is used in other places to describe a row of samples for a single component (whereas an MCU row in a typical lossless JPEG image consists of a row of interleaved samples for all components.)

2858783d

2024-08-28T18:16:18

JNI: Set srcX, srcY = 0 in loadSourceImage() (oversight from 79b8d65f0f86af77afc5979ecc104b1fbc97c82d)

4ceaf8b7

2024-08-26T10:31:19

TJBench: Allow 'X' in crop spec (for consistency with djpeg and jpegtran)

fd9b21b6

2024-08-28T18:58:21

Merge branch 'main' into dev

5cf79606

2024-08-28T18:36:37

Undocument TJ*PARAM_RESTARTBLOCKS for lossless TJ*PARAM_RESTARTBLOCKS technically works with lossless compression, but it is not useful, since the value must be equal to the number of samples in a row. (In other words, it is no different than TJ*PARAM_RESTARTINROWS, except that it requires the user to do more math.)

d6207971

2024-08-28T18:00:14

TJBench: Don't override subsamp until args parsed Otherwise, passing -subsamp after -lossless might cause the worst-case JPEG buffer size to be too small.

c72bbd9c

2024-08-26T18:00:23

tjbench.c: (Re)allow unreduced scaling factors For reasons I can't recall, fc01f4673b71c0b833c59c21e8c4478a9c4bcf21 (the TurboJPEG 3 API overhaul) changed the C version of TJBench, but not the Java version, so that it requires an exact scaling factor match (as opposed to allowing unreduced scaling factors, as djpeg does and prior versions of TJBench did.) That might have been temporary testing code that was accidentally committed.

6a9565ce

2024-08-26T16:45:41

Merge branch 'main' into dev

kc3-lang/libjpeg-turbo

Log