kmx git

Commit	Date	Message
9e17440a	2025-11-10T18:49:38	Doc: Wordsmithing
466c3448	2025-10-23T10:41:16	TurboJPEG doc tweaks - Clarify that YUV encoding performs downsampling as well as color conversion. - Clarify that TJPARAM_LOSSLESS is ignored by tj3CompressFromYUV8(). - Clarify that tj3CompressFromYUV8() generates only YCbCr or grayscale JPEG images, i.e. that TJPARAM_COLORSPACE has no effect.
6d48aaac	2025-10-22T10:30:53	TJ: Handle lossless/CS params w/ YUV enc/compress - If TJPARAM_LOSSLESS was set, then tj3EncodeYUV8() called jpeg_enable_lossless() (via setCompDefaults()), which caused the underlying libjpeg API to silently disable subsampling and color conversion. This led to three issues: 1. Attempting to encode RGB pixels produced incorrect YCbCr or grayscale components, since color conversion did not occur. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to TJCS_RGB. 2. Attempting to encode RGB pixels into a grayscale plane caused tj3EncodeYUVPlanes8() to overflow the caller's destination pointer array if the array was not big enough to accommodate three pointers. If called from tj3EncodeYUV8(), tj3EncodeYUVPlanes8() did not overflow the caller's destination pointer array, but a segfault occurred when it attempted to copy to the Cb and Cr pointers, which were NULL. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to anything other than TJCS_GRAY. 3. Attempting to encode RGB pixels into subsampled YUV planes caused tj3EncodeYUV8() to overflow the caller's buffer(s) if the buffer(s) were not big enough to accommodate 4:4:4 (non-subsampled) YUV planes. That would have been the case if the caller allocated its buffer(s) based on the return value of tj3YUVBufSize() or tj3YUVPlaneSize(). The same issue occurs if TJPARAM_SUBSAMP is explicitly set to TJSAMP_444. tj3EncodeYUV8() now ignores TJPARAM_LOSSLESS and TJPARAM_COLORSPACE. - If TJPARAM_LOSSLESS was set, then attempting to compress a grayscale plane into a JPEG image caused tj3CompressFromYUVPlanes8() to overflow the caller's source pointer array if the array was not big enough to accommodate three pointers. If called from tj3CompressFromYUV8(), tj3CompressFromYUVPlanes8() did not overflow the caller's source pointer array, but a segfault occurred when it attempted to copy from the Cb and Cr pointers, which were NULL. This was similar to Issue 2 above. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to anything other than TJCS_GRAY. tj3CompressFromYUV8() now throws an error if TJPARAM_LOSSLESS is set, and it now ignores TJPARAM_COLORSPACE. These issues did not pose a security risk, since security exploits involve supported workflows that function normally except when supplied with malformed input data. It is documented that colorspace conversion, chrominance subsampling, and compression from planar YUV images are unavailable when TJPARAM_LOSSLESS is set. When TJPARAM_LOSSLESS is set, the library effectively sets TJPARAM_SUBSAMP to TJSAMP_444 and TJPARAM_COLORSPACE to TJCS_RGB, TJCS_GRAY, or TJCS_CMYK, depending on the pixel format of the source image. That behavior is strongly implied by the documentation of TJPARAM_LOSSLESS, although the documentation isn't specific about whether TJPARAM_LOSSLESS applies to tj3EncodeYUV8(). In any case, setting TJPARAM_LOSSLESS before calling tj3CompressFromYUV8() was never a supported or functional workflow, and setting TJPARAM_LOSSLESS before calling tj3EncodeYUV*8() was never a functional workflow. Thus, there should be no applications "in the wild" that use either workflow. Such applications would crash every time they attempted to encode to or compress from a YUV image. In other words, setting TJPARAM_LOSSLESS or TJPARAM_COLORSPACE required the caller to understand the ramifications of the loss of color conversion and/or subsampling, and failing to do so was essentially API abuse (albeit subtle API abuse, hence the desire to make the behavior more intuitive.) This commit also removes no-op code introduced by 6da05150efa9b7a190d05bf82295127c778d15ab. Since setCompDefaults() returns after calling jpeg_enable_lossless(), modifying the subsampling level locally had no effect. The libjpeg API already silently disables subsampling in jinit_c_master_control() if lossless compression is enabled, so it was not necessary for setCompDefaults() to handle that. Fixes #839
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.)
9b01f5a0	2024-09-14T11:56:14	TJ: Add func/method for computing xformed buf size
a2728582	2024-09-03T07:54:17	TurboJPEG: ICC profile support
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
a4d19a45	2024-09-03T09:27:04	Merge branch 'main' into dev
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
6d9f1f81	2024-09-01T14:04:20	Merge branch 'main' into dev
797c6ccd	2024-09-01T11:23:31	Doc: Further clarify MCU definition
64567381	2024-08-31T17:31:02	Merge branch 'main' into dev
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.)
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.)
6a9565ce	2024-08-26T16:45:41	Merge branch 'main' into dev
35199878	2024-08-26T16:35:30	TurboJPEG doc: Fix incorrect/confusing parentheses
26d978b6	2024-08-16T11:58:02	Merge branch 'main' into dev
0c23b0ad	2024-08-14T09:21:54	Various doc tweaks - "Optimized baseline entropy coding" = "Huffman table optimization" "Optimized baseline entropy coding" was meant to emphasize that the feature is only useful when generating baseline (single-scan lossy 8-bit-per-sample Huffman-coded) JPEG images, because it is automatically enabled when generating Huffman-coded progressive (multi-scan), 12-bit-per-sample, and lossless JPEG images. However, Huffman table optimization isn't actually an integral part of those non-baseline modes. You can forego Huffman table optimization with 12-bit data precision if you supply your own Huffman tables. The spec doesn't require it with progressive or lossless mode, either, although our implementation does. Furthermore, "baseline" describes more than just the type of entropy coding used. It was incorrect to say that optimized "baseline" entropy coding is automatically enabled for Huffman-coded progressive, 12-bit-per-sample, and lossless JPEG images, since those are clearly not baseline images. - "Progressive entropy coding" = "Progressive JPEG" "Progressive" describes more than just the type of entropy coding used. (In fact, both Huffman-coded and arithmetic-coded images can be progressive.) - Mention that TJPARAM_OPTIMIZE/TJ.PARAM_OPTIMIZE can be used with lossless transformation as well. - General wordsmithing - Formatting tweaks
6ec8e41f	2024-06-13T11:52:13	Handle lossless JPEG images w/2-15 bits per sample Closes #768 Closes #769
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.
55bcad88	2024-06-24T22:16:07	Merge branch 'main' into dev
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
be96fa0a	2023-12-14T13:18:20	Doc: Lossless JPEG clarifications - Clarify that lossless JPEG is slower than and doesn't compress as well as lossy JPEG. (That should be obvious, because "lossy" literally means that data is thrown away.) - Re-generate TurboJPEG C API documentation using Doxygen 1.9.8. - Clarify that setting the data_precision field in jpeg_compress_struct to 16 requires lossless mode. - Explain what the predictor selection value actually does. (Refer to Recommendation ITU-T T.81 (1992) \| ISO/IEC 10918-1:1994, Section H.1.2.1.)
55d342c7	2023-11-16T15:36:47	TurboJPEG: Expose/extend hidden "max pixels" param TJPARAM_MAXPIXELS was previously hidden and used only for fuzz testing, but it is potentially useful for calling applications as well, particularly if they want to guard against excessive memory consumption by the tj3LoadImage*() functions. The parameter has also been extended to decompression and lossless transformation functions/methods, mainly as a convenience. (It was already possible for calling applications to impose their own JPEG image size limits by reading the JPEG header prior to decompressing or transforming the image.)
df9dbff8	2023-11-11T12:25:03	TurboJPEG: New param to limit virt array mem usage This corresponds to max_memory_to_use in the jpeg_memory_mgr struct in the libjpeg API, except that the TurboJPEG parameter is specified in megabytes. Because this is 2023 and computers with less than 1 MB of memory are not a thing (at least not within the scope of libjpeg-turbo support), it isn't useful to allow a limit less than 1 MB to be specified. Furthermore, because TurboJPEG parameters are signed integers, if we allowed the memory limit to be specified in bytes, then it would be impossible to specify a limit larger than 2 GB on 64-bit machines. Because max_memory_to_use is a long signed integer, effectively we can specify a limit of up to 2 petabytes on 64-bit machines if the TurboJPEG parameter is specified in megabytes. (2 PB should be enough for anybody, right?) This commit also bumps the TurboJPEG API version to 3.0.1. Since the TurboJPEG API version no longer tracks the libjpeg-turbo version, it makes sense to increment the API revision number when adding constants, to increment the minor version number when adding functions, and to increment the major version number for a complete overhaul. This commit also removes the vestigial TJ_NUMPARAM macro, which was never defined because it proved unnecessary. Partially implements #735
220bd761	2023-11-10T11:06:16	turbojpeg.h: Fix broken refs in API documentation "TJPARAM_DENSITYUNIT" should be "TJPARAM_DENSITYUNITS" (oops.)
89528757	2023-07-05T15:35:21	xform fuzz: Use src subsamp to calc dst buf size Referring to https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60379 there are some specially-crafted malformed JPEG images that, when transformed to grayscale, will exceed the worst-case transformed grayscale JPEG image size. This is similar in nature to the issue fixed by c8d52f1c4c7480277b91420c27b2548d4c8e9043, except that in this case, the issue occurs regardless of the amount of metadata in the source image. Also, the tj3Transform() function, the Java_org_libjpegturbo_turbojpeg_TJTransformer_transform() JNI function, and TJBench were behaving correctly in this case, because the TurboJPEG API documentation specifies that the source image's subsampling type should be used when computing the worst-case transformed JPEG image size. (However, only the Java API documentation specified that. Oops. The C API documentation now does as well.) The documented usage mitigates the issue, and only the transform fuzzer did not adhere to that. Thus, this was an issue with the fuzzer itself rather than an issue with the library.
4a831d6e	2023-06-30T10:15:40	turbojpeg.h: Make customFilter() proto match doc Closes #704
fc881ebb	2023-03-09T20:55:43	TurboJPEG: Implement 4:4:1 chrominance subsampling This allows losslessly transposed or rotated 4:1:1 JPEG images to be losslessly cropped, partially decompressed, or decompressed to planar YUV images. Because tj3Transform() allows multiple lossless transformations to be chained together, all subsampling options need to have a corresponding transposed subsampling option. (This is why 4:4:0 was originally implemented as well.) Otherwise, the documentation would be technically incorrect. It says that images with unknown subsampling types cannot be losslessly cropped, partially decompressed, or decompressed to planar YUV images, but it doesn't say anything about images with known subsampling types whose subsampling type becomes unknown if the image is rotated or transposed. This is one of those situations in which it is easier to implement a feature that works around the problem than to document the problem. Closes #659
96bc40c1	2023-01-26T13:11:58	Implement arithmetic coding with 12-bit precision This actually works and apparently always has worked. It only failed because the libjpeg code, which did not originally support arithmetic coding, assumed that optimize_coding should always be TRUE for 12-bit data precision.
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 TJFLAG_ARITHMETIC and TJFLAG_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. * TJFLAG_LIMITSCANS has been reimplemented as an integer parameter (TJPARAM_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 (TJPARAM_LOSSLESS, TJPARAM_LOSSLESSPSV, and TJPARAM_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 (TJPARAM_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. TJPARAM_SUBSAMP is set to TJSAMP_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 (TJPARAM_RESTARTROWS and TJPARAM_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 (TJPARAM_OPTIMIZE), a transform option (TJOPT_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 (TJPARAM_XDENSITY, TJPARAM_DENSITY, and TJDENSITYUNITS) 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
7ab6222c	2023-01-20T14:09:25	Merge branch 'main' into dev
fb15efe9	2023-01-18T06:44:46	TurboJPEG: More documentation improvements - TJBench/TJUnitTest: Wordsmith command-line output - Java: "decompress operations"="decompression operations" - tjLoadImage(): Error message tweak - Don't mention compression performance in the description of TJXOPT_PROGRESSIVE/TJTransform.OPT_PROGRESSIVE, because the image has already been compressed at that point. (Oversights from 9a146f0f23b01869e1bf7c478e12b43f83d59c32)
d4589f4f	2023-01-14T18:07:53	Merge branch 'main' into dev
9a146f0f	2023-01-06T10:29:10	TurboJPEG: Numerous documentation improvements - Wordsmithing, formatting, and grammar tweaks - Various clarifications and corrections, including specifying whether a particular buffer or image is used as a source or destination - Accommodate/mention features that were introduced since the API documentation was created. - For clarity, use "packed-pixel" to describe uncompressed source/destination images that are not planar YUV. - Use "row" rather than "line" to refer to a single horizontal group of pixels or component values, for consistency with the libjpeg API documentation. (libjpeg also uses "scanline", which is a more archaic term.) - Use "alignment" rather than "padding" to refer to the number of bytes by which a row's width is evenly divisible. This consistifies the documention of the YUV functions and tjLoadImage(). ("Padding" typically refers to the number of bytes added to each row, which is not the same thing.) - Remove all references to "the underlying codec." Although the TurboJPEG API originated as a cross-platform wrapper for the Intel Integrated Performance Primitives, Sun mediaLib, QuickTime, and libjpeg, none of those TurboJPEG implementations has been maintained since 2009. Nothing would prevent someone from implementing the TurboJPEG API without libjpeg-turbo, but such an implementation would not necessarily have an "underlying codec." (It could be fully self-contained.) - Use "destination image" rather than "output image", for consistency, or describe the type of image that will be output. - Avoid the term "image buffer" and instead use "byte buffer" to refer to buffers that will hold JPEG images, or describe the type of image that will be contained in the buffer. (The Java documentation doesn't use "byte buffer", because the buffer arrays literally have "byte" in front of them, and since Java doesn't have pointers, it is not possible for mere mortals to store any other type of data in those arrays.) - C: Use "unified" to describe YUV images stored in a single buffer, for consistency with the Java documentation. - Use "planar YUV" rather than "YUV planar". Is is our convention to describe images using {component layout} {colorspace/pixel format} {image function}, e.g. "packed-pixel RGB source image" or "planar YUV destination image." - C: Document the TurboJPEG API version in which a particular function or macro was introduced, and reorder the backward compatibility function stubs in turbojpeg.h alphabetically by API version. - C: Use Markdown rather than HTML tags, where possible, in the Doxygen comments.
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.
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.
25ccad99	2022-11-16T15:57:25	TurboJPEG: 8-bit lossless JPEG support
6002720c	2022-11-15T23:10:35	TurboJPEG: Opt. enable arithmetic entropy coding
ba22c0f7	2022-06-24T14:03:03	tjDecompressHeader3(): Accept tables-only streams Inspired by: https://github.com/amyspark/libjpeg-turbo/commit/b3b15cfe74cf07914122e26cf1e408a9a9cf3135 Closes #604 Closes #605
cd9a3185	2021-04-05T22:20:52	Bump TurboJPEG C API version to 2.1 (because of TJFLAG_LIMITSCANS)
c81e91e8	2021-04-05T16:08:22	TurboJPEG: New flag for limiting prog JPEG scans This also fixes timeouts reported by OSS-Fuzz.
2d14fc2e	2020-10-01T14:35:46	Dox: Re-generate using Doxygen 1.8.20 This fixes a GitHub Dependabot alert regarding jquery.js. Fixes #421
ae87a958	2020-06-16T13:52:39	TurboJPEG: Make global error handling thread-safe ... on platforms that support thread-local storage. This currently includes all supported platforms except 32-bit macOS. Fixes #396
00607ec2	2020-01-08T14:22:35	Eliminate unnecessary NULL checks before tjFree() + document that tjFree() accepts NULL pointers without complaint. Effectively, it has had that behavior all along, but the API does not guarantee that tjFree() will be implemented with free() behind the scenes, so it's best to formalize the behavior.
c0ca354e	2018-03-22T16:04:29	Label this release 2.0 instead of 1.6 This also pulls the formatting changes from 19c791cdac6df84418c66eb9d67cfa9703bc2461 into the TurboJPEG C API docs.
479fa1d8	2017-11-18T11:33:05	tjLoadImage(): Don't convert RGB to grayscale Loading RGB image files into a grayscale buffer isn't a particularly useful feature, given that libjpeg-turbo can perform this conversion much more optimally (with SIMD acceleration on some platforms) during the compression process. Also, the RGB2GRAY() macro was not producing deterministic cross-platform results because of variations in the round-off behavior of various floating point implementations, so `tjunittest -bmp` was failing in i386 builds.
dc4b9002	2017-11-16T20:43:12	TurboJPEG: Add alpha offset array/method Also, set the red/green/blue offsets for TJPF_GRAY to -1 rather than 0. It was undefined behavior for an application to use those arrays/methods with TJPF_GRAY anyhow, and this makes it easier for applications to programmatically detect whether a given pixel format has red, green, and blue components.
aa745905	2017-11-16T18:09:07	TurboJPEG C API: Add BMP/PPM load/save functions The main justification for this is to provide new libjpeg-turbo users with a quick & easy way of developing a complete JPEG compression/decompression program without requiring them to build libjpeg-turbo from source (which was necessary in order to use the project-private bmp API) or to use external libraries. These new functions build upon significant enhancements to rdbmp.c, wrbmp.c, rdppm.c, and wrppm.c which allow those engines to convert directly between the native pixel format of the file and a pixel format ("colorspace" in libjpeg parlance) specified by the calling program. rdbmp.c and wrbmp.c have also been modified such that the calling program can choose to read or write image rows in the native (bottom-up) order of the file format, thus eliminating the need to use an inversion array. tjLoadImage() and tjSaveImage() leverage these new underlying features in order to significantly improve upon the performance of the old bmp API. Because these new functions cannot work without the libjpeg-turbo colorspace extensions, the libjpeg-compatible code in turbojpeg.c has been removed. That code was only there to serve as an example of how to use the TurboJPEG API on top of libjpeg, but more specific, buildable examples now exist in the https://github.com/libjpeg-turbo/ijg repository.
4893e5d8	2017-11-17T19:00:53	Merge branch 'master' into dev
5abf2536	2017-11-14T16:12:13	Doc tweak: TJFLAG_ACCURATEDCT is the first flag
dadebcd7	2017-06-28T11:43:08	TurboJPEG: Add "copy none", progressive xform opts Allow progressive entropy coding to be enabled on a transform-by-transform basis, and implement a new transform option for disabling the copying of markers. Closes #153
dedce66e	2017-06-28T15:30:41	Merge branch 'master' into dev
b0971e47	2017-06-28T14:47:45	TurboJPEG: Document xform issue w/ big marker data If the source image for a transform operation has a lot of EXIF or ICC data embedded in it, then it may cause the output image size to exceed the worst-case size returned by tjBufSize() (because tjTransform() transfers all markers to the output image.) This is only a problem if TJFLAG_NOREALLOC is passed to the function. Since the TurboJPEG C API doesn't require the destination image size to be set in this case, it makes the documented assumption that the calling program has allocated the destination buffer to exactly the size returned by tjBufSize(). Changing this assumption would change the API behavior and necessitate a new function name (tjTransform2().) At the moment, it's easier to just document this as a known issue, since it's easy to work around in the C API. The Java API is unfortunately a different story, since it must always use TJFLAG_NOREALLOC (because, when using the TurboJPEG Java API, all buffers are allocated on the Java heap, and thus they can't be reallocated by the C code.) There is no easy way to work around this without changing the C API as discussed above, because if the source image contains large amounts of marker data, it's virtually impossible to determine how big the output image will be.
aba6ae59	2017-06-27T13:24:08	TurboJPEG: Opt. enable progressive entropy coding Fulfills part of the feature request in #153. Also paves the way for SIMD-accelerated progressive Huffman coding (refer to #46.)
596e3965	2017-06-27T11:51:34	Merge branch 'master' into dev
d0c3aa90	2017-06-27T11:36:25	TurboJPEG: C API documentation buglet TJFLAG_NOREALLOC, tjAlloc(), and tjFree() apply to all TurboJPEG compression functions, not just tjCompress2().
d4092f6b	2017-06-27T10:54:21	TurboJPEG: Improve error handling - Provide a new C API function and TJException method that allows calling programs to query the severity of a compression/decompression/ transform error. - Provide a new flag that instructs the library to immediately stop compressing/decompressing/transforming if a warning is encountered. Fixes #151
b9ab64d8	2017-05-11T21:02:29	TurboJPEG: Thread-safe error message retrieval Introduce a new C API function (tjGetErrorStr2()) that can be used to retrieve compression/decompression/transform error messages in a thread-safe (i.e. instance-specific) manner. Retrieving error messages from global functions is still thread-unsafe. Addresses a concern expressed in #151.
7c202f76	2016-02-29T13:18:01	Bump TurboJPEG C API revision to 1.5 The changes relative to 1.4.x are only cosmetic (using const pointers) and should not affect API/ABI compatibility, but our practice is to synchronize the API revision with the most recent release that provides user-visible changes to the API.
6fa14b37	2015-08-13T20:06:03	Declare source buffers in TurboJPEG C API as const This reassures the caller that the buffers will not be modified and also allows read-only buffers to be passed to the functions. Partially reverts 3947a19f25fc8186d3812dbcf8e70baea36ef652.
7a8c53e4	2015-06-19T16:07:14	Clarify that the TurboJPEG API functions/methods do not modify the source buffer. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1567 632fc199-4ca6-4c93-a231-07263d6284db
fe80ec22	2014-08-21T15:51:47	If the output buffer in the TurboJPEG destination manager was allocated by the destination manager and is being reused from a previous compression operation, then we need to get the buffer size from the previous operation, since the calling program doesn't know the actual buffer size. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1368 632fc199-4ca6-4c93-a231-07263d6284db
40dd3146	2014-08-17T12:23:49	Refactored YUVImage Java class so that it supports both unified YUV image buffers as well as separate YUV image planes; modified the JNI functions accordingly and added new helper functions to the TurboJPEG C API (tjPlaneWidth(), tjPlaneHeight(), tjPlaneSizeYUV()) to facilitate those modifications; changed potentially confusing "component width" and "component height" terms to "plane width" and "plane height" and modified variable names in turbojpeg.c to reflect this; numerous other documentation tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1360 632fc199-4ca6-4c93-a231-07263d6284db
f7c11051	2014-08-12T15:52:51	Oops. Parameter name is "strides", not "stride" git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1345 632fc199-4ca6-4c93-a231-07263d6284db
9d77dad4	2014-08-12T15:06:30	Reformat TurboJPEG C API documentation to improve ease of maintenance and to make it more consistent with the javadoc formatting; fix minor error in tjCompressFromYUV() prototype. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1344 632fc199-4ca6-4c93-a231-07263d6284db
aecea388	2014-08-11T18:05:41	Extend the TurboJPEG C API to support handling YUV images stored in separate image planes instead of a unified buffer git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1343 632fc199-4ca6-4c93-a231-07263d6284db
493be617	2014-08-10T20:12:17	Clean up and consolidate notes regarding the YUV image format. This also corrects a factual error regarding the padding of the luminance plane-- because we now support 4:1:1, the component width is not necessarily padded to the nearest multiple of 2 if horizontal subsampling is used. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1342 632fc199-4ca6-4c93-a231-07263d6284db
779bd68d	2014-08-10T18:30:52	Clean up notes using the doxygen @note command git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1341 632fc199-4ca6-4c93-a231-07263d6284db
d13df213	2014-08-10T17:25:51	Clean up notes using the doxygen @note command git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1340 632fc199-4ca6-4c93-a231-07263d6284db
c71ab2f7	2014-08-10T16:43:31	Make the documentation more readable by displaying fixed-width text (which is used to refer to variables and functions) in a different color. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1339 632fc199-4ca6-4c93-a231-07263d6284db
983503ed	2014-08-10T16:39:32	Fix a display issue in the documentation for tjDecompress2() (doxygen treats a star at the beginning of the line as a list bullet); make the documentation more readable by displaying fixed-width text (which is used to refer to variables and functions) in a different color. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1338 632fc199-4ca6-4c93-a231-07263d6284db
1909c59b	2014-03-15T08:48:53	As with tjDecompressToYUV*(), tjCompressFromYUV() also conditionally uses an intermediate buffer if the source image dimensions do not fall on MCU boundaries. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1170 632fc199-4ca6-4c93-a231-07263d6284db
a15f19f2	2014-03-11T09:46:50	Wordsmithing & formatting tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1154 632fc199-4ca6-4c93-a231-07263d6284db
34dca052	2014-02-28T09:17:14	Implement a YUV decode function in the TurboJPEG API, to be symmetric with tjEncodeYUV(). git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1132 632fc199-4ca6-4c93-a231-07263d6284db
7db5273e	2013-11-25T21:12:23	Per the conventions of the image compression and digital video communities, use "YCbCr" to describe the JPEG colorspace and "YUV" to describe an image format consisting of Y, Cb, and Cr planes (this partially reverts r960.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1093 632fc199-4ca6-4c93-a231-07263d6284db
b3a028e3	2013-11-25T21:08:47	Per the conventions of the image compression and digital video communities, use "YCbCr" to describe the JPEG colorspace and "YUV" to describe an image format consisting of Y, Cb, and Cr planes (this partially reverts r959.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1092 632fc199-4ca6-4c93-a231-07263d6284db
5a7e9e5b	2013-11-25T20:30:12	Per the conventions of the image compression and digital video communities, use "YCbCr" to describe the JPEG colorspace and "YUV" to describe an image format consisting of Y, Cb, and Cr planes (this partially reverts r959.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1091 632fc199-4ca6-4c93-a231-07263d6284db
07e982d9	2013-10-31T07:11:39	Deprecate and undocument the FORCE{MMX\|SSE\|SSE2\|SSE3} flags. These were originally introduced in TurboJPEG/IPP as a way to override the automatic CPU selection in the underlying IPP codec, which was closed source. They are not meaningful anymore, since libjpeg-turbo provides environment variables to accomplish the same thing and since it no longer necessarily uses x86 SIMD code behind the scenes. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1072 632fc199-4ca6-4c93-a231-07263d6284db
910a3572	2013-10-30T23:02:57	Extend the TurboJPEG C API to support compressing JPEG images from YUV planar images git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1067 632fc199-4ca6-4c93-a231-07263d6284db
b2c4745a	2013-08-23T06:38:59	Wordsmithing git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1021 632fc199-4ca6-4c93-a231-07263d6284db
cd7c3e66	2013-08-23T02:49:25	Add CMYK support to the TurboJPEG C API git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1019 632fc199-4ca6-4c93-a231-07263d6284db
1f3635c4	2013-08-18T10:19:00	Add 4:1:1 subsampling support in the TurboJPEG C API git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1014 632fc199-4ca6-4c93-a231-07263d6284db
7bd24b26	2013-08-18T09:38:52	Disable timestamp in generated HTML files to make diffing and merging easier. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1013 632fc199-4ca6-4c93-a231-07263d6284db
ca866c48	2013-08-18T09:37:48	Disable timestamp in generated HTML files to make diffing and merging easier. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1012 632fc199-4ca6-4c93-a231-07263d6284db
3b21982b	2013-08-18T09:31:45	Wordsmithing git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1011 632fc199-4ca6-4c93-a231-07263d6284db
7657726d	2013-08-18T09:28:09	Wordsmithing git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1010 632fc199-4ca6-4c93-a231-07263d6284db
d081fd72	2013-08-18T09:15:37	Add note regarding the fact that 4:4:0 lacks full SIMD support; Add an option for benchmarking 4:4:0 subsampling in tjbench. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1009 632fc199-4ca6-4c93-a231-07263d6284db
bcda6834	2013-08-18T09:02:42	Upgrade to Doxygen 1.8.3.1; Add note regarding the fact that 4:4:0 lacks full SIMD support. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1007 632fc199-4ca6-4c93-a231-07263d6284db
71ccb39d	2013-08-18T09:00:15	Upgrade to Doxygen 1.8.3.1 git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1006 632fc199-4ca6-4c93-a231-07263d6284db
a4a48ed0	2013-08-18T08:47:03	Upgrade to Doxygen 1.8.3.1 git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1005 632fc199-4ca6-4c93-a231-07263d6284db
f610d61f	2013-04-26T10:33:29	Extend the TurboJPEG C API to support generating YUV images with arbitrary padding and to support image scaling when decompressing to YUV git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@962 632fc199-4ca6-4c93-a231-07263d6284db
d8522a75	2013-04-26T08:54:10	Wordsmithing git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@961 632fc199-4ca6-4c93-a231-07263d6284db
01fdcc39	2013-04-26T08:41:25	Further doc tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@959 632fc199-4ca6-4c93-a231-07263d6284db

9e17440a

2025-11-10T18:49:38

Doc: Wordsmithing

466c3448

2025-10-23T10:41:16

TurboJPEG doc tweaks - Clarify that YUV encoding performs downsampling as well as color conversion. - Clarify that TJPARAM_LOSSLESS is ignored by tj3CompressFromYUV*8(). - Clarify that tj3CompressFromYUV*8() generates only YCbCr or grayscale JPEG images, i.e. that TJPARAM_COLORSPACE has no effect.

6d48aaac

2025-10-22T10:30:53

TJ: Handle lossless/CS params w/ YUV enc/compress - If TJPARAM_LOSSLESS was set, then tj3EncodeYUV*8() called jpeg_enable_lossless() (via setCompDefaults()), which caused the underlying libjpeg API to silently disable subsampling and color conversion. This led to three issues: 1. Attempting to encode RGB pixels produced incorrect YCbCr or grayscale components, since color conversion did not occur. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to TJCS_RGB. 2. Attempting to encode RGB pixels into a grayscale plane caused tj3EncodeYUVPlanes8() to overflow the caller's destination pointer array if the array was not big enough to accommodate three pointers. If called from tj3EncodeYUV8(), tj3EncodeYUVPlanes8() did not overflow the caller's destination pointer array, but a segfault occurred when it attempted to copy to the Cb and Cr pointers, which were NULL. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to anything other than TJCS_GRAY. 3. Attempting to encode RGB pixels into subsampled YUV planes caused tj3EncodeYUV*8() to overflow the caller's buffer(s) if the buffer(s) were not big enough to accommodate 4:4:4 (non-subsampled) YUV planes. That would have been the case if the caller allocated its buffer(s) based on the return value of tj3YUVBufSize() or tj3YUVPlaneSize(). The same issue occurs if TJPARAM_SUBSAMP is explicitly set to TJSAMP_444. tj3EncodeYUV*8() now ignores TJPARAM_LOSSLESS and TJPARAM_COLORSPACE. - If TJPARAM_LOSSLESS was set, then attempting to compress a grayscale plane into a JPEG image caused tj3CompressFromYUVPlanes8() to overflow the caller's source pointer array if the array was not big enough to accommodate three pointers. If called from tj3CompressFromYUV8(), tj3CompressFromYUVPlanes8() did not overflow the caller's source pointer array, but a segfault occurred when it attempted to copy from the Cb and Cr pointers, which were NULL. This was similar to Issue 2 above. The same issue occurred if TJPARAM_COLORSPACE was explicitly set to anything other than TJCS_GRAY. tj3CompressFromYUV*8() now throws an error if TJPARAM_LOSSLESS is set, and it now ignores TJPARAM_COLORSPACE. These issues did not pose a security risk, since security exploits involve supported workflows that function normally except when supplied with malformed input data. It is documented that colorspace conversion, chrominance subsampling, and compression from planar YUV images are unavailable when TJPARAM_LOSSLESS is set. When TJPARAM_LOSSLESS is set, the library effectively sets TJPARAM_SUBSAMP to TJSAMP_444 and TJPARAM_COLORSPACE to TJCS_RGB, TJCS_GRAY, or TJCS_CMYK, depending on the pixel format of the source image. That behavior is strongly implied by the documentation of TJPARAM_LOSSLESS, although the documentation isn't specific about whether TJPARAM_LOSSLESS applies to tj3EncodeYUV*8(). In any case, setting TJPARAM_LOSSLESS before calling tj3CompressFromYUV*8() was never a supported or functional workflow, and setting TJPARAM_LOSSLESS before calling tj3EncodeYUV*8() was never a functional workflow. Thus, there should be no applications "in the wild" that use either workflow. Such applications would crash every time they attempted to encode to or compress from a YUV image. In other words, setting TJPARAM_LOSSLESS or TJPARAM_COLORSPACE required the caller to understand the ramifications of the loss of color conversion and/or subsampling, and failing to do so was essentially API abuse (albeit subtle API abuse, hence the desire to make the behavior more intuitive.) This commit also removes no-op code introduced by 6da05150efa9b7a190d05bf82295127c778d15ab. Since setCompDefaults() returns after calling jpeg_enable_lossless(), modifying the subsampling level locally had no effect. The libjpeg API already silently disables subsampling in jinit_c_master_control() if lossless compression is enabled, so it was not necessary for setCompDefaults() to handle that. Fixes #839

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

9b01f5a0

2024-09-14T11:56:14

TJ: Add func/method for computing xformed buf size

a2728582

2024-09-03T07:54:17

TurboJPEG: ICC profile support

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

a4d19a45

2024-09-03T09:27:04

Merge branch 'main' into dev

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

6d9f1f81

2024-09-01T14:04:20

Merge branch 'main' into dev

797c6ccd

2024-09-01T11:23:31

Doc: Further clarify MCU definition

64567381

2024-08-31T17:31:02

Merge branch 'main' into dev

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

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

6a9565ce

2024-08-26T16:45:41

Merge branch 'main' into dev

35199878

2024-08-26T16:35:30

TurboJPEG doc: Fix incorrect/confusing parentheses

26d978b6

2024-08-16T11:58:02

Merge branch 'main' into dev

0c23b0ad

2024-08-14T09:21:54

Various doc tweaks - "Optimized baseline entropy coding" = "Huffman table optimization" "Optimized baseline entropy coding" was meant to emphasize that the feature is only useful when generating baseline (single-scan lossy 8-bit-per-sample Huffman-coded) JPEG images, because it is automatically enabled when generating Huffman-coded progressive (multi-scan), 12-bit-per-sample, and lossless JPEG images. However, Huffman table optimization isn't actually an integral part of those non-baseline modes. You can forego Huffman table optimization with 12-bit data precision if you supply your own Huffman tables. The spec doesn't require it with progressive or lossless mode, either, although our implementation does. Furthermore, "baseline" describes more than just the type of entropy coding used. It was incorrect to say that optimized "baseline" entropy coding is automatically enabled for Huffman-coded progressive, 12-bit-per-sample, and lossless JPEG images, since those are clearly not baseline images. - "Progressive entropy coding" = "Progressive JPEG" "Progressive" describes more than just the type of entropy coding used. (In fact, both Huffman-coded and arithmetic-coded images can be progressive.) - Mention that TJPARAM_OPTIMIZE/TJ.PARAM_OPTIMIZE can be used with lossless transformation as well. - General wordsmithing - Formatting tweaks

6ec8e41f

2024-06-13T11:52:13

Handle lossless JPEG images w/2-15 bits per sample Closes #768 Closes #769

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.

55bcad88

2024-06-24T22:16:07

Merge branch 'main' into dev

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

be96fa0a

2023-12-14T13:18:20

Doc: Lossless JPEG clarifications - Clarify that lossless JPEG is slower than and doesn't compress as well as lossy JPEG. (That should be obvious, because "lossy" literally means that data is thrown away.) - Re-generate TurboJPEG C API documentation using Doxygen 1.9.8. - Clarify that setting the data_precision field in jpeg_compress_struct to 16 requires lossless mode. - Explain what the predictor selection value actually does. (Refer to Recommendation ITU-T T.81 (1992) | ISO/IEC 10918-1:1994, Section H.1.2.1.)

55d342c7

2023-11-16T15:36:47

TurboJPEG: Expose/extend hidden "max pixels" param TJPARAM_MAXPIXELS was previously hidden and used only for fuzz testing, but it is potentially useful for calling applications as well, particularly if they want to guard against excessive memory consumption by the tj3LoadImage*() functions. The parameter has also been extended to decompression and lossless transformation functions/methods, mainly as a convenience. (It was already possible for calling applications to impose their own JPEG image size limits by reading the JPEG header prior to decompressing or transforming the image.)

df9dbff8

2023-11-11T12:25:03

TurboJPEG: New param to limit virt array mem usage This corresponds to max_memory_to_use in the jpeg_memory_mgr struct in the libjpeg API, except that the TurboJPEG parameter is specified in megabytes. Because this is 2023 and computers with less than 1 MB of memory are not a thing (at least not within the scope of libjpeg-turbo support), it isn't useful to allow a limit less than 1 MB to be specified. Furthermore, because TurboJPEG parameters are signed integers, if we allowed the memory limit to be specified in bytes, then it would be impossible to specify a limit larger than 2 GB on 64-bit machines. Because max_memory_to_use is a long signed integer, effectively we can specify a limit of up to 2 petabytes on 64-bit machines if the TurboJPEG parameter is specified in megabytes. (2 PB should be enough for anybody, right?) This commit also bumps the TurboJPEG API version to 3.0.1. Since the TurboJPEG API version no longer tracks the libjpeg-turbo version, it makes sense to increment the API revision number when adding constants, to increment the minor version number when adding functions, and to increment the major version number for a complete overhaul. This commit also removes the vestigial TJ_NUMPARAM macro, which was never defined because it proved unnecessary. Partially implements #735

220bd761

2023-11-10T11:06:16

turbojpeg.h: Fix broken refs in API documentation "TJPARAM_DENSITYUNIT" should be "TJPARAM_DENSITYUNITS" (oops.)

89528757

2023-07-05T15:35:21

xform fuzz: Use src subsamp to calc dst buf size Referring to https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60379 there are some specially-crafted malformed JPEG images that, when transformed to grayscale, will exceed the worst-case transformed grayscale JPEG image size. This is similar in nature to the issue fixed by c8d52f1c4c7480277b91420c27b2548d4c8e9043, except that in this case, the issue occurs regardless of the amount of metadata in the source image. Also, the tj3Transform() function, the Java_org_libjpegturbo_turbojpeg_TJTransformer_transform() JNI function, and TJBench were behaving correctly in this case, because the TurboJPEG API documentation specifies that the source image's subsampling type should be used when computing the worst-case transformed JPEG image size. (However, only the Java API documentation specified that. Oops. The C API documentation now does as well.) The documented usage mitigates the issue, and only the transform fuzzer did not adhere to that. Thus, this was an issue with the fuzzer itself rather than an issue with the library.

4a831d6e

2023-06-30T10:15:40

turbojpeg.h: Make customFilter() proto match doc Closes #704

fc881ebb

2023-03-09T20:55:43

TurboJPEG: Implement 4:4:1 chrominance subsampling This allows losslessly transposed or rotated 4:1:1 JPEG images to be losslessly cropped, partially decompressed, or decompressed to planar YUV images. Because tj3Transform() allows multiple lossless transformations to be chained together, all subsampling options need to have a corresponding transposed subsampling option. (This is why 4:4:0 was originally implemented as well.) Otherwise, the documentation would be technically incorrect. It says that images with unknown subsampling types cannot be losslessly cropped, partially decompressed, or decompressed to planar YUV images, but it doesn't say anything about images with known subsampling types whose subsampling type becomes unknown if the image is rotated or transposed. This is one of those situations in which it is easier to implement a feature that works around the problem than to document the problem. Closes #659

96bc40c1

2023-01-26T13:11:58

Implement arithmetic coding with 12-bit precision This actually works and apparently always has worked. It only failed because the libjpeg code, which did not originally support arithmetic coding, assumed that optimize_coding should always be TRUE for 12-bit data precision.

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

7ab6222c

2023-01-20T14:09:25

Merge branch 'main' into dev

fb15efe9

2023-01-18T06:44:46

TurboJPEG: More documentation improvements - TJBench/TJUnitTest: Wordsmith command-line output - Java: "decompress operations"="decompression operations" - tjLoadImage(): Error message tweak - Don't mention compression performance in the description of TJXOPT_PROGRESSIVE/TJTransform.OPT_PROGRESSIVE, because the image has already been compressed at that point. (Oversights from 9a146f0f23b01869e1bf7c478e12b43f83d59c32)

d4589f4f

2023-01-14T18:07:53

Merge branch 'main' into dev

9a146f0f

2023-01-06T10:29:10

TurboJPEG: Numerous documentation improvements - Wordsmithing, formatting, and grammar tweaks - Various clarifications and corrections, including specifying whether a particular buffer or image is used as a source or destination - Accommodate/mention features that were introduced since the API documentation was created. - For clarity, use "packed-pixel" to describe uncompressed source/destination images that are not planar YUV. - Use "row" rather than "line" to refer to a single horizontal group of pixels or component values, for consistency with the libjpeg API documentation. (libjpeg also uses "scanline", which is a more archaic term.) - Use "alignment" rather than "padding" to refer to the number of bytes by which a row's width is evenly divisible. This consistifies the documention of the YUV functions and tjLoadImage(). ("Padding" typically refers to the number of bytes added to each row, which is not the same thing.) - Remove all references to "the underlying codec." Although the TurboJPEG API originated as a cross-platform wrapper for the Intel Integrated Performance Primitives, Sun mediaLib, QuickTime, and libjpeg, none of those TurboJPEG implementations has been maintained since 2009. Nothing would prevent someone from implementing the TurboJPEG API without libjpeg-turbo, but such an implementation would not necessarily have an "underlying codec." (It could be fully self-contained.) - Use "destination image" rather than "output image", for consistency, or describe the type of image that will be output. - Avoid the term "image buffer" and instead use "byte buffer" to refer to buffers that will hold JPEG images, or describe the type of image that will be contained in the buffer. (The Java documentation doesn't use "byte buffer", because the buffer arrays literally have "byte" in front of them, and since Java doesn't have pointers, it is not possible for mere mortals to store any other type of data in those arrays.) - C: Use "unified" to describe YUV images stored in a single buffer, for consistency with the Java documentation. - Use "planar YUV" rather than "YUV planar". Is is our convention to describe images using {component layout} {colorspace/pixel format} {image function}, e.g. "packed-pixel RGB source image" or "planar YUV destination image." - C: Document the TurboJPEG API version in which a particular function or macro was introduced, and reorder the backward compatibility function stubs in turbojpeg.h alphabetically by API version. - C: Use Markdown rather than HTML tags, where possible, in the Doxygen comments.

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.

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.

25ccad99

2022-11-16T15:57:25

TurboJPEG: 8-bit lossless JPEG support

6002720c

2022-11-15T23:10:35

TurboJPEG: Opt. enable arithmetic entropy coding

ba22c0f7

2022-06-24T14:03:03

tjDecompressHeader3(): Accept tables-only streams Inspired by: https://github.com/amyspark/libjpeg-turbo/commit/b3b15cfe74cf07914122e26cf1e408a9a9cf3135 Closes #604 Closes #605

cd9a3185

2021-04-05T22:20:52

Bump TurboJPEG C API version to 2.1 (because of TJFLAG_LIMITSCANS)

c81e91e8

2021-04-05T16:08:22

TurboJPEG: New flag for limiting prog JPEG scans This also fixes timeouts reported by OSS-Fuzz.

2d14fc2e

2020-10-01T14:35:46

Dox: Re-generate using Doxygen 1.8.20 This fixes a GitHub Dependabot alert regarding jquery.js. Fixes #421

ae87a958

2020-06-16T13:52:39

TurboJPEG: Make global error handling thread-safe ... on platforms that support thread-local storage. This currently includes all supported platforms except 32-bit macOS. Fixes #396

00607ec2

2020-01-08T14:22:35

Eliminate unnecessary NULL checks before tjFree() + document that tjFree() accepts NULL pointers without complaint. Effectively, it has had that behavior all along, but the API does not guarantee that tjFree() will be implemented with free() behind the scenes, so it's best to formalize the behavior.

c0ca354e

2018-03-22T16:04:29

Label this release 2.0 instead of 1.6 This also pulls the formatting changes from 19c791cdac6df84418c66eb9d67cfa9703bc2461 into the TurboJPEG C API docs.

479fa1d8

2017-11-18T11:33:05

tjLoadImage(): Don't convert RGB to grayscale Loading RGB image files into a grayscale buffer isn't a particularly useful feature, given that libjpeg-turbo can perform this conversion much more optimally (with SIMD acceleration on some platforms) during the compression process. Also, the RGB2GRAY() macro was not producing deterministic cross-platform results because of variations in the round-off behavior of various floating point implementations, so `tjunittest -bmp` was failing in i386 builds.

dc4b9002

2017-11-16T20:43:12

TurboJPEG: Add alpha offset array/method Also, set the red/green/blue offsets for TJPF_GRAY to -1 rather than 0. It was undefined behavior for an application to use those arrays/methods with TJPF_GRAY anyhow, and this makes it easier for applications to programmatically detect whether a given pixel format has red, green, and blue components.

aa745905

2017-11-16T18:09:07

TurboJPEG C API: Add BMP/PPM load/save functions The main justification for this is to provide new libjpeg-turbo users with a quick & easy way of developing a complete JPEG compression/decompression program without requiring them to build libjpeg-turbo from source (which was necessary in order to use the project-private bmp API) or to use external libraries. These new functions build upon significant enhancements to rdbmp.c, wrbmp.c, rdppm.c, and wrppm.c which allow those engines to convert directly between the native pixel format of the file and a pixel format ("colorspace" in libjpeg parlance) specified by the calling program. rdbmp.c and wrbmp.c have also been modified such that the calling program can choose to read or write image rows in the native (bottom-up) order of the file format, thus eliminating the need to use an inversion array. tjLoadImage() and tjSaveImage() leverage these new underlying features in order to significantly improve upon the performance of the old bmp API. Because these new functions cannot work without the libjpeg-turbo colorspace extensions, the libjpeg-compatible code in turbojpeg.c has been removed. That code was only there to serve as an example of how to use the TurboJPEG API on top of libjpeg, but more specific, buildable examples now exist in the https://github.com/libjpeg-turbo/ijg repository.

4893e5d8

2017-11-17T19:00:53

Merge branch 'master' into dev

5abf2536

2017-11-14T16:12:13

Doc tweak: TJFLAG_ACCURATEDCT is the first flag

dadebcd7

2017-06-28T11:43:08

TurboJPEG: Add "copy none", progressive xform opts Allow progressive entropy coding to be enabled on a transform-by-transform basis, and implement a new transform option for disabling the copying of markers. Closes #153

dedce66e

2017-06-28T15:30:41

Merge branch 'master' into dev

b0971e47

2017-06-28T14:47:45

TurboJPEG: Document xform issue w/ big marker data If the source image for a transform operation has a lot of EXIF or ICC data embedded in it, then it may cause the output image size to exceed the worst-case size returned by tjBufSize() (because tjTransform() transfers all markers to the output image.) This is only a problem if TJFLAG_NOREALLOC is passed to the function. Since the TurboJPEG C API doesn't require the destination image size to be set in this case, it makes the documented assumption that the calling program has allocated the destination buffer to exactly the size returned by tjBufSize(). Changing this assumption would change the API behavior and necessitate a new function name (tjTransform2().) At the moment, it's easier to just document this as a known issue, since it's easy to work around in the C API. The Java API is unfortunately a different story, since it must always use TJFLAG_NOREALLOC (because, when using the TurboJPEG Java API, all buffers are allocated on the Java heap, and thus they can't be reallocated by the C code.) There is no easy way to work around this without changing the C API as discussed above, because if the source image contains large amounts of marker data, it's virtually impossible to determine how big the output image will be.

aba6ae59

2017-06-27T13:24:08

TurboJPEG: Opt. enable progressive entropy coding Fulfills part of the feature request in #153. Also paves the way for SIMD-accelerated progressive Huffman coding (refer to #46.)

596e3965

2017-06-27T11:51:34

Merge branch 'master' into dev

d0c3aa90

2017-06-27T11:36:25

TurboJPEG: C API documentation buglet TJFLAG_NOREALLOC, tjAlloc(), and tjFree() apply to all TurboJPEG compression functions, not just tjCompress2().

d4092f6b

2017-06-27T10:54:21

TurboJPEG: Improve error handling - Provide a new C API function and TJException method that allows calling programs to query the severity of a compression/decompression/ transform error. - Provide a new flag that instructs the library to immediately stop compressing/decompressing/transforming if a warning is encountered. Fixes #151

b9ab64d8

2017-05-11T21:02:29

TurboJPEG: Thread-safe error message retrieval Introduce a new C API function (tjGetErrorStr2()) that can be used to retrieve compression/decompression/transform error messages in a thread-safe (i.e. instance-specific) manner. Retrieving error messages from global functions is still thread-unsafe. Addresses a concern expressed in #151.

7c202f76

2016-02-29T13:18:01

Bump TurboJPEG C API revision to 1.5 The changes relative to 1.4.x are only cosmetic (using const pointers) and should not affect API/ABI compatibility, but our practice is to synchronize the API revision with the most recent release that provides user-visible changes to the API.

6fa14b37

2015-08-13T20:06:03

Declare source buffers in TurboJPEG C API as const This reassures the caller that the buffers will not be modified and also allows read-only buffers to be passed to the functions. Partially reverts 3947a19f25fc8186d3812dbcf8e70baea36ef652.

7a8c53e4

2015-06-19T16:07:14

Clarify that the TurboJPEG API functions/methods do not modify the source buffer. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1567 632fc199-4ca6-4c93-a231-07263d6284db

fe80ec22

2014-08-21T15:51:47

If the output buffer in the TurboJPEG destination manager was allocated by the destination manager and is being reused from a previous compression operation, then we need to get the buffer size from the previous operation, since the calling program doesn't know the actual buffer size. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1368 632fc199-4ca6-4c93-a231-07263d6284db

40dd3146

2014-08-17T12:23:49

Refactored YUVImage Java class so that it supports both unified YUV image buffers as well as separate YUV image planes; modified the JNI functions accordingly and added new helper functions to the TurboJPEG C API (tjPlaneWidth(), tjPlaneHeight(), tjPlaneSizeYUV()) to facilitate those modifications; changed potentially confusing "component width" and "component height" terms to "plane width" and "plane height" and modified variable names in turbojpeg.c to reflect this; numerous other documentation tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1360 632fc199-4ca6-4c93-a231-07263d6284db

f7c11051

2014-08-12T15:52:51

Oops. Parameter name is "strides", not "stride" git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1345 632fc199-4ca6-4c93-a231-07263d6284db

9d77dad4

2014-08-12T15:06:30

Reformat TurboJPEG C API documentation to improve ease of maintenance and to make it more consistent with the javadoc formatting; fix minor error in tjCompressFromYUV() prototype. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1344 632fc199-4ca6-4c93-a231-07263d6284db

aecea388

2014-08-11T18:05:41

Extend the TurboJPEG C API to support handling YUV images stored in separate image planes instead of a unified buffer git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1343 632fc199-4ca6-4c93-a231-07263d6284db

493be617

2014-08-10T20:12:17

Clean up and consolidate notes regarding the YUV image format. This also corrects a factual error regarding the padding of the luminance plane-- because we now support 4:1:1, the component width is not necessarily padded to the nearest multiple of 2 if horizontal subsampling is used. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1342 632fc199-4ca6-4c93-a231-07263d6284db

779bd68d

2014-08-10T18:30:52

Clean up notes using the doxygen @note command git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1341 632fc199-4ca6-4c93-a231-07263d6284db

d13df213

2014-08-10T17:25:51

Clean up notes using the doxygen @note command git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1340 632fc199-4ca6-4c93-a231-07263d6284db

c71ab2f7

2014-08-10T16:43:31

Make the documentation more readable by displaying fixed-width text (which is used to refer to variables and functions) in a different color. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1339 632fc199-4ca6-4c93-a231-07263d6284db

983503ed

2014-08-10T16:39:32

Fix a display issue in the documentation for tjDecompress2() (doxygen treats a star at the beginning of the line as a list bullet); make the documentation more readable by displaying fixed-width text (which is used to refer to variables and functions) in a different color. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1338 632fc199-4ca6-4c93-a231-07263d6284db

1909c59b

2014-03-15T08:48:53

As with tjDecompressToYUV*(), tjCompressFromYUV() also conditionally uses an intermediate buffer if the source image dimensions do not fall on MCU boundaries. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1170 632fc199-4ca6-4c93-a231-07263d6284db

a15f19f2

2014-03-11T09:46:50

Wordsmithing & formatting tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1154 632fc199-4ca6-4c93-a231-07263d6284db

34dca052

2014-02-28T09:17:14

Implement a YUV decode function in the TurboJPEG API, to be symmetric with tjEncodeYUV(). git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1132 632fc199-4ca6-4c93-a231-07263d6284db

7db5273e

2013-11-25T21:12:23

Per the conventions of the image compression and digital video communities, use "YCbCr" to describe the JPEG colorspace and "YUV" to describe an image format consisting of Y, Cb, and Cr planes (this partially reverts r960.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1093 632fc199-4ca6-4c93-a231-07263d6284db

b3a028e3

2013-11-25T21:08:47

Per the conventions of the image compression and digital video communities, use "YCbCr" to describe the JPEG colorspace and "YUV" to describe an image format consisting of Y, Cb, and Cr planes (this partially reverts r959.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1092 632fc199-4ca6-4c93-a231-07263d6284db

5a7e9e5b

2013-11-25T20:30:12

Per the conventions of the image compression and digital video communities, use "YCbCr" to describe the JPEG colorspace and "YUV" to describe an image format consisting of Y, Cb, and Cr planes (this partially reverts r959.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1091 632fc199-4ca6-4c93-a231-07263d6284db

07e982d9

2013-10-31T07:11:39

Deprecate and undocument the FORCE{MMX|SSE|SSE2|SSE3} flags. These were originally introduced in TurboJPEG/IPP as a way to override the automatic CPU selection in the underlying IPP codec, which was closed source. They are not meaningful anymore, since libjpeg-turbo provides environment variables to accomplish the same thing and since it no longer necessarily uses x86 SIMD code behind the scenes. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1072 632fc199-4ca6-4c93-a231-07263d6284db

910a3572

2013-10-30T23:02:57

Extend the TurboJPEG C API to support compressing JPEG images from YUV planar images git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1067 632fc199-4ca6-4c93-a231-07263d6284db

b2c4745a

2013-08-23T06:38:59

Wordsmithing git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1021 632fc199-4ca6-4c93-a231-07263d6284db

cd7c3e66

2013-08-23T02:49:25

Add CMYK support to the TurboJPEG C API git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1019 632fc199-4ca6-4c93-a231-07263d6284db

1f3635c4

2013-08-18T10:19:00

Add 4:1:1 subsampling support in the TurboJPEG C API git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1014 632fc199-4ca6-4c93-a231-07263d6284db

7bd24b26

2013-08-18T09:38:52

Disable timestamp in generated HTML files to make diffing and merging easier. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1013 632fc199-4ca6-4c93-a231-07263d6284db

ca866c48

2013-08-18T09:37:48

Disable timestamp in generated HTML files to make diffing and merging easier. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1012 632fc199-4ca6-4c93-a231-07263d6284db

3b21982b

2013-08-18T09:31:45

Wordsmithing git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1011 632fc199-4ca6-4c93-a231-07263d6284db

7657726d

2013-08-18T09:28:09

Wordsmithing git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1010 632fc199-4ca6-4c93-a231-07263d6284db

d081fd72

2013-08-18T09:15:37

Add note regarding the fact that 4:4:0 lacks full SIMD support; Add an option for benchmarking 4:4:0 subsampling in tjbench. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1009 632fc199-4ca6-4c93-a231-07263d6284db

bcda6834

2013-08-18T09:02:42

Upgrade to Doxygen 1.8.3.1; Add note regarding the fact that 4:4:0 lacks full SIMD support. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1007 632fc199-4ca6-4c93-a231-07263d6284db

71ccb39d

2013-08-18T09:00:15

Upgrade to Doxygen 1.8.3.1 git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1006 632fc199-4ca6-4c93-a231-07263d6284db

a4a48ed0

2013-08-18T08:47:03

Upgrade to Doxygen 1.8.3.1 git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1005 632fc199-4ca6-4c93-a231-07263d6284db

f610d61f

2013-04-26T10:33:29

Extend the TurboJPEG C API to support generating YUV images with arbitrary padding and to support image scaling when decompressing to YUV git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@962 632fc199-4ca6-4c93-a231-07263d6284db

d8522a75

2013-04-26T08:54:10

Wordsmithing git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@961 632fc199-4ca6-4c93-a231-07263d6284db

01fdcc39

2013-04-26T08:41:25

Further doc tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@959 632fc199-4ca6-4c93-a231-07263d6284db

kc3-lang/libjpeg-turbo/doc

doc

Log