kc3-lang/libjpeg-turbo/doc
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
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 | |
|
a4d19a45 | 2024-09-03 09:27:04 | Merge branch 'main' into dev | |
|
f5f8f5aa | 2024-09-03 08: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-01 14:04:20 | Merge branch 'main' into dev |