|
9e17440a
|
2025-11-10T18:49:38
|
|
Doc: Wordsmithing
|
|
|
466c3448
|
2025-10-23T10: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-22T10: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
|
|
|
1f3614f1
|
2025-10-08T10:42:18
|
|
TJ: Guard against reused JPEG dst buf w/0 buf size
The libjpeg in-memory destination manager has always re-allocated the
JPEG destination buffer if the specified buffer pointer is NULL or the
specified buffer size is 0. TurboJPEG's destination manager inherited
that behavior. Because of fe80ec22752cce224c55d7b429d46503634ef034,
TurboJPEG's destination manager tries to reuse the most recent
destination buffer if the same buffer pointer is specified. (The
purpose of that is to enable repeated invocations of tj*Compress*() or
tj*Transform() to automatically grow the destination buffer, as needed,
with no intervention from the calling program.) However, because of the
inherited code, TurboJPEG's destination manager also reallocated the
destination buffer if the specified buffer size was 0. Thus, passing a
previously-used JPEG destination buffer pointer to tj*Compress*() or
tj*Transform() while specifying a destination buffer size of 0 confused
the destination manager. It reallocated the destination buffer to 4096
bytes but reported the old destination buffer size to the libjpeg API.
This caused a buffer overrun if the old destination buffer size was
larger than 4096 bytes.
The documentation for tj*Compress*() is contradictory on this matter.
It states that the JPEG destination buffer size must be specified if the
destination buffer pointer is non-NULL. However, it also states that,
if the destination buffer is reused, the specified destination buffer
size is ignored. The documentation for tj*Transform() does not specify
the function's behavior if the destination buffer is reused. Thus, the
behavior of the API is at best undefined if a calling application
attempts to reuse a destination buffer while specifying a destination
buffer size of 0. If that ever worked, it only worked in libjpeg-turbo
1.3.x and prior.
This issue was exposed only through API abuse, and calling applications
that abused the API in that manner would not have worked for the last 11
years. Thus, the issue did not represent a security threat. This
commit merely hardens the API against such abuse, by modifying
TurboJPEG's destination manager so that it refuses to re-allocate the
JPEG destination buffer if the buffer pointer is reused and the
specified buffer size is 0. That is consistent with the most permissive
interpretation of the TurboJPEG API documentation. (The API already
ignored the destination buffer size if the destination buffer pointer
was reused and the specified buffer size was non-zero. It makes sense
for it to do likewise if the specified buffer size is 0.) This commit
also modifies TJUnitTest so that it verifies whether the API is hardened
against the aforementioned abuse.
|
|
|
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.)
|
|
|
98c45838
|
2025-08-21T11:22:51
|
|
Fix issues with Windows Arm64EC builds
Arm64EC basically wraps native Arm64 functions with an emulated
Windows/x64 ABI, which can improve performance for Windows/x64
applications running under the x64 emulator on Windows/Arm. When
building for Arm64EC, the compiler defines _M_X64 and _M_ARM64EC but not
_M_ARM64.
|
|
|
f158143e
|
2025-07-28T20:45:02
|
|
jpeg_skip_scanlines: Fix UAF w/merged upsamp/quant
jpeg_skip_scanlines() (more specifically, read_and_discard_scanlines())
should check whether merged upsampling is disabled before attempting
to dereference cinfo->cconvert, and it should check whether color
quantization is enabled before attempting to dereference
cinfo->cquantize. Otherwise, executing one of the following sequences
with the same libjpeg API instance and any 4:2:0 or 4:2:2 JPEG image
will cause a use-after-free issue:
- Disable merged upsampling (default)
- jpeg_start_decompress()
- jpeg_finish_decompress()
(frees but doesn't zero cinfo->cconvert)
- Enable merged upsampling
- jpeg_start_decompress()
(doesn't re-allocate cinfo->cconvert, because
j*init_color_deconverter() isn't called)
- jpeg_skip_scanlines()
- Enable 1-pass color quantization
- jpeg_start_decompress()
- jpeg_finish_decompress()
(frees but doesn't zero cinfo->cquantize)
- Disable 1-pass color quantization
- jpeg_start_decompress()
(doesn't re-allocate cinfo->cquantize, because j*init_*_quantizer()
isn't called)
- jpeg_skip_scanlines()
These sequences are very unlikely to occur in a real-world application.
In practice, this issue does not even cause a segfault or other
user-visible errant behavior, so it is only detectable with ASan. That
is because the memory region is small enough that it doesn't get
reclaimed by either the application or the O/S between the point at
which it is freed and the point at which it is used (even though a
subsequent malloc() call requests exactly the same amount of memory.)
Thus, this is an undefined behavior issue, but it is unlikely to be
exploitable.
|
|
|
51cee036
|
2025-06-13T14:52:09
|
|
Build: Use wrappers rather than CMake object libs
Some downstream projects need to adapt the libjpeg-turbo source code to
non-CMake build systems, and the use of CMake object libraries made that
difficult. Referring to #754, the use of CMake object libraries also
caused the libjpeg-turbo libraries to contain duplicate object names,
which caused problems with certain development tools. This commit
modifies the build system so that it uses wrappers, rather than CMake
object libraries, to compile source files for multiple data precisions.
For convenience, the wrappers are included in the source tree, but they
can be re-generated by building the "wrappers" target.
In addition to facilitating downstream integration, using wrappers
improves code readability, since multiple data precisions are now
handled at the source code level instead of at the build system level.
Since this will be pushed to a bug-fix release, the goal was to avoid
changing any existing source code. A future major release of
libjpeg-turbo may restructure the libjpeg API source code so that only
the functions that need to be compiled for multiple data precisions are
wrapped. (That is how the TurboJPEG API source code is structured.)
Closes #817
|
|
|
c889b1da
|
2025-06-12T09:40:20
|
|
TJBench: Require additional argument with -copy
(oversight from e4c67aff50420d7bacff503ceb4556c896128413)
|
|
|
66771223
|
2025-05-13T10:33:15
|
|
cjpeg: Free ICC profile if API error when fuzzing
Fixes #809
|
|
|
e0e18dea
|
2024-12-18T12:50:38
|
|
Ensure methods called by global funcs are init'd
If a hypothetical calling application does something really stupid and
changes cinfo->data_precision after calling jpeg_start_*compress(), then
the precision-specific methods called by jpeg_write_scanlines(),
jpeg_write_raw_data(), jpeg_finish_compress(), jpeg_read_scanlines(),
jpeg_read_raw_data(), or jpeg_start_output() may not be initialized.
Ensure that the first precision-specific method (which will always be
cinfo->main->process_data*(), cinfo->coef->compress_data*(), or
cinfo->coef->decompress_data()) called by any global function that may
be called after jpeg_start_*compress() is initialized and non-NULL.
This increases the likelihood (but does not guarantee) that a
hypothetical stupid calling application will fail gracefully rather than
segfault if it changes cinfo->data_precision after calling
jpeg_start_*compress(). A hypothetical stupid calling application can
still bork itself by changing cinfo->data_precision after initializing
the source manager but before calling jpeg_start_compress(), or after
initializing the destination manager but before calling
jpeg_start_decompress().
|
|
|
84fa3bc0
|
2024-12-11T17:39:02
|
|
tjTransform(): Fix false positive compiler warning
|
|
|
9758c8a7
|
2024-11-18T13:40:08
|
|
Exclude more code if !(C|D)_LOSSLESS_SUPPORTED
|
|
|
d7932a27
|
2024-10-30T12: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.)
|
|
|
6da05150
|
2024-10-24T13:25:10
|
|
Allow disabling prog/opt/lossless if prev. enabled
- Due to an oversight, a113506d175d03ae0e40965c3d3d21a5d561e119
(libjpeg-turbo 1.4 beta1) effectively made the call to
std_huff_tables() in jpeg_set_defaults() a no-op if the Huffman tables
were previously defined, which made it impossible to disable Huffman
table optimization or progressive mode if they were previously enabled
in the same API instance. std_huff_tables() retains its previous
behavior for decompression instances, but it now force-enables the
standard (baseline) Huffman tables for compression instances.
- Due to another oversight, there was no way to disable lossless mode
if it was previously enabled in a particular API instance.
jpeg_set_defaults() now accomplishes this, which makes
TJ*PARAM_LOSSLESS behave as intended/documented.
- Due to yet another oversight, setCompDefaults() in the TurboJPEG API
library permanently modified the value of TJ*PARAM_SUBSAMP when
generating a lossless JPEG image, which affected subsequent lossy
compression operations. This issue was hidden by the issue above and
thus does not need to be publicly documented.
Fixes #792
|
|
|
1b1356a5
|
2024-09-23T15: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.
|
|
|
ad9c02c6
|
2024-09-23T13:22:09
|
|
tj3Set(): Allow TJPARAM_LOSSLESSPT vals from 0..15
The target data precision isn't necessarily known at the time that the
calling program sets TJPARAM_LOSSLESSPT, so tj3Set() needs to allow all
possible values (from 0 to 15.) jpeg_enable_lossless(), which is called
within the body of tj3Compress*(), will throw an error if the point
transform value is greater than {data precision} - 1.
|
|
|
0d58f099
|
2024-09-14T12:50:36
|
|
TJTran: ICC profiles are now supported
|
|
|
9b01f5a0
|
2024-09-14T11:56:14
|
|
TJ: Add func/method for computing xformed buf size
|
|
|
5b099580
|
2024-09-14T11:13:07
|
|
Merge branch 'main' into dev
|
|
|
e3e353fe
|
2024-09-06T20:30:03
|
|
tjunittest.c: Store/retrieve original buf size ...
... between iterations.
(oversight from c519d7b67913e69b667f5fac49650f825e56218d)
|
|
|
a2728582
|
2024-09-03T07:54:17
|
|
TurboJPEG: ICC profile support
|
|
|
c6de7d87
|
2024-09-06T09:21:47
|
|
tjdecomp.c: Remove extraneous #defines
|
|
|
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
|
|
|
e3dac188
|
2024-09-05T17:07:50
|
|
Merge branch 'main' into dev
|
|
|
8db41dad
|
2024-09-05T15:15:08
|
|
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.)
|
|
|
d43ed7a1
|
2024-09-04T08:38:13
|
|
Merge branch 'main' into dev
|
|
|
a4d19a45
|
2024-09-03T09:27:04
|
|
Merge branch 'main' into dev
|
|
|
37851a32
|
2024-09-01T15:07:27
|
|
TurboJPEG: Add restart markers when transforming
|
|
|
a66398fe
|
2024-09-02T08:52:42
|
|
Move md5cmp/md5sum into ${CMAKE_BINARY_DIR}/test
|
|
|
debf57bc
|
2024-09-01T10:59:35
|
|
TJBench: Improve usage screen readability
|
|
|
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
|