java

Branch :

Log

Commit	Date	Message
f74989d8	2025-09-25 11:32:45	Clean up #include directives This is subtle, but #include <header.h> searches directories specified with -I, then system include directories. #include "header.h" searches the current source directory, then directories specified with -I, then system include directories. Using bracketed #include directives for jpeglib.h, jinclude.h, jerror.h, cdjpeg.h, and turbojpeg.h only worked because the build system explicitly passed -I{source_directory}/src/ to the compiler. Referring to 51cee0362998ec6f1eabac1e795f3b6e3ee639ea, it's better for the source code to have as few dependencies on our specific build system as possible. Since jpeglib.h, jinclude.h, jerror.h, and turbojpeg.h can be installed in system include directories, it's also better for internal references to those headers to resolve internally first, to avoid potential conflicts between the system-installed version of libjpeg-turbo and the version being built. (Such conflicts would never have occurred with our build system, but they might have occurred due to misintegration with a downstream build system.)
c889b1da	2025-06-12 09:40:20	TJBench: Require additional argument with -copy (oversight from e4c67aff50420d7bacff503ceb4556c896128413)
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.)
1b1356a5	2024-09-23 15:18:53	TJComp: Explicitly specify data precision This is just a code readability thing. The logic effectively caused the data precision to default to 8 if -precision was not specified, but that was not obvious. This commit also modifies tjcomptest so that it tests TJComp with no -precision argument, to ensure that the data precision defaults to 8.
0d58f099	2024-09-14 12:50:36	TJTran: ICC profiles are now supported
6d02718d	2024-09-14 12:42:12	JNI: Guard against int. overflow w/ ICC profiles
9b01f5a0	2024-09-14 11:56:14	TJ: Add func/method for computing xformed buf size
6f1fe2d1	2024-09-09 10:52:18	turbojpeg-jni.c: Fix int. conv. warnings w/ VC++
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?