|
f74989d8
|
2025-09-25T11: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-12T09:40:20
|
|
TJBench: Require additional argument with -copy
(oversight from e4c67aff50420d7bacff503ceb4556c896128413)
|
|
|
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
|
|
|
e4c67aff
|
2024-09-04T12:06:42
|
|
TJBench: More argument consistification
-copynone --> -copy none
Add '-copy all', even though it's the default.
-rgb, -bgr, -rgbx, -bgrx, -xbgr, -xrgb, -gray, -cmyk -->
-pixelformat {rgb|bgr|rgbx|bgrx|xbgr|xrgb|gray|cmyk}
(This is mainly so -gray won't interfere with -grayscale.)
Fix an ArrayIndexOutOfBoundsException that occurred when passing -dct
to the Java version without specifying the DCT algorithm (oversight from
24fbf64d31a0758c63bcc27cf5d92fc5611717d0.)
|
|
|
37851a32
|
2024-09-01T15:07:27
|
|
TurboJPEG: Add restart markers when transforming
|
|
|
debf57bc
|
2024-09-01T10:59:35
|
|
TJBench: Improve usage screen readability
|
|
|
3e303e72
|
2024-08-31T18:38:05
|
|
TJBench: Allow British spellings in arguments
|
|
|
64567381
|
2024-08-31T17:31:02
|
|
Merge branch 'main' into dev
|
|
|
4ceaf8b7
|
2024-08-26T10:31:19
|
|
TJBench: Allow 'X' in crop spec
(for consistency with djpeg and jpegtran)
|
|
|
fd9b21b6
|
2024-08-28T18:58:21
|
|
Merge branch 'main' into dev
|
|
|
6a9565ce
|
2024-08-26T16:45:41
|
|
Merge branch 'main' into dev
|
|
|
24fbf64d
|
2024-08-21T11:24:44
|
|
TJBench: Consistify args with djpeg
-fastdct --> -dct fast
-fastupsample --> -nosmooth
|
|
|
d6ce7df3
|
2024-08-20T15:22:07
|
|
TJBench: Consistify args with cjpeg/djpeg/jpegtran
-hflip --> -flip horizontal
-limitscans --> -maxscans N
-rot90 --> -rotate 90
-rot180 --> -rotate 180
-rot270 --> -rotate 270
-stoponwarning --> -strict
-vflip --> -flip vertical
|
|
|
ab203704
|
2024-08-20T08:01:50
|
|
TJBench: Allow abbreviated command-line options
... using the same matching algorithm as cjpeg/djpeg/jpegtran and, where
possible, the same abbreviations:
-a for -arithmetic
-b for -bmp
-cr for -crop
-g for -grayscale
-l for -lossless
-max for -maxmemory
-o for -optimize
-pre for -precision
-p for -progressive
-r for -restart
-s for -scale
-t for -transpose
-transv for -transverse
|
|
|
26d978b6
|
2024-08-16T11:58:02
|
|
Merge branch 'main' into dev
|
|
|
6ec8e41f
|
2024-06-13T11:52:13
|
|
Handle lossless JPEG images w/2-15 bits per sample
Closes #768
Closes #769
|
|
|
ed79114a
|
2024-06-18T13:06:30
|
|
TJBench: Test end-to-end grayscale comp./decomp.
Because the TurboJPEG API originated in VirtualGL and TurboVNC as a
means of compressing from/decompressing to extended RGB framebuffers,
its earliest incarnations did not handle grayscale packed-pixel images.
Thus, TJBench has always converted the input image (even if it is
grayscale) to an extended RGB source buffer prior to compression, and it
has always decompressed JPEG images (even if they are grayscale) into an
extended RGB destination buffer. That allows TJBench to benchmark the
RGB-to-grayscale and grayscale-to-RGB color conversion paths used by
VirtualGL and TurboVNC when grayscale subsampling (AKA the grayscale
JPEG colorspace) is selected. However, more recent versions of the
TurboJPEG API handle grayscale packed-pixel images, so it is beneficial
to allow TJBench to benchmark the end-to-end grayscale compression and
decompression paths. This commit accomplishes that by adding a new
command-line option (-gray) that causes TJBench to use a grayscale
source buffer (which only works if the input image is PGM or grayscale
BMP), to decompress JPEG images (even if they are full-color) into a
grayscale destination buffer, and to save output images in PGM or
grayscale BMP format.
|
|
|
55bcad88
|
2024-06-24T22:16:07
|
|
Merge branch 'main' into dev
|
|
|
cf357e81
|
2024-03-18T12:46:54
|
|
Merge branch 'main' into dev
|
|
|
c8c5c2e5
|
2024-03-06T15:33:47
|
|
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
|