kc3-lang/libjpeg-turbo/doc
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
9e17440a | 2025-11-10 18:49:38 | Doc: Wordsmithing | |
|
466c3448 | 2025-10-23 10: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-22 10: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-30 12: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-14 11:56:14 | TJ: Add func/method for computing xformed buf size | |
|
a2728582 | 2024-09-03 07:54:17 | TurboJPEG: ICC profile support | |
|
c519d7b6 | 2024-09-05 11: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-06 19:55:20 | Merge branch 'main' into dev | |
|
b3f0abe3 | 2024-09-06 10: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-05 21: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 |