|
fad61007
|
2024-08-20T18:52:53
|
|
Replace TJExample with IJG workalike programs
|
|
|
6d9f1f81
|
2024-09-01T14:04:20
|
|
Merge branch 'main' into dev
|
|
|
7f45663d
|
2024-09-01T10:05:57
|
|
Merge branch 'main' into dev
|
|
|
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
|
|
|
79b8d65f
|
2024-08-22T13:50:32
|
|
Java: Add official packed-pixel image I/O methods
|
|
|
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
|
|
|
d55a051e
|
2024-08-20T15:11:34
|
|
Merge branch 'main' into dev
|
|
|
26d978b6
|
2024-08-16T11:58:02
|
|
Merge branch 'main' into dev
|
|
|
4c0e5642
|
2024-08-02T09:09:34
|
|
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
|
|
|
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.
|
|
|
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
|
|
|
095e62b6
|
2024-05-29T10:16:05
|
|
Merge branch 'main' into dev
|
|
|
db0bf6cd
|
2024-05-29T00:19:15
|
|
Merge branch 'main' into dev
|
|
|
ea2d8575
|
2024-05-20T14:12:24
|
|
Merge branch 'main' into dev
|
|
|
1face11a
|
2024-05-14T14:49:19
|
|
Merge branch 'main' into dev
|
|
|
e0d660f1
|
2024-05-08T11:42:39
|
|
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
|
|
|
7e45654c
|
2024-03-04T18:10:16
|
|
Merge branch 'main' into dev
|
|
|
9f5a04b5
|
2024-01-24T11:30:40
|
|
Reorganize source tree, Part Deux
- Move version scripts/map files into src/, since those files apply only
to the C API libraries.
|
|
|
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
|