|
140a1ea3
|
2022-11-22T10:37:19
|
|
tjEncodeYUVPlanes(): Ignore TJFLAG_LOSSLESS
TJFLAG_LOSSLESS is irrelevant to planar YUV encoding, and setting the
flag caused tjEncode*() to fail with "Invalid lossless parameters"
because tjEncodeYUVPlanes() passes a JPEG quality value of -1 to
setCompDefaults(). This commit modifies setCompDefaults() so that it
takes no action related to the jpegQual parameter unless jpegQual >= 0.
|
|
|
98ff1fd1
|
2022-11-21T20:57:39
|
|
TurboJPEG: Add lossless JPEG detection capability
Add a new TurboJPEG C API function (tjDecompressHeader4()) and Java API
method (TJDecompressor.getFlags()) that return the bitwise OR of any
flags that are relevant to the JPEG image being decompressed (currently
TJFLAG_PROGRESSIVE, TJFLAG_ARITHMETIC, TJFLAG_LOSSLESS, and their Java
equivalents.) This allows a calling program to determine whether the
image being decompressed is a lossless JPEG image, which means that the
decompression scaling feature will not be available and that a
full-sized destination buffer should be allocated.
More specifically, this fixes a buffer overrun in TJBench, TJExample,
and the decompress* fuzz targets that occurred when attempting (in vain)
to decompress a lossless JPEG image with decompression scaling enabled.
|
|
|
25ccad99
|
2022-11-16T15:57:25
|
|
TurboJPEG: 8-bit lossless JPEG support
|
|
|
6002720c
|
2022-11-15T23:10:35
|
|
TurboJPEG: Opt. enable arithmetic entropy coding
|
|
|
ed73fdc9
|
2022-11-15T21:28:01
|
|
Merge branch 'main' into dev
|
|
|
aa3dd0bd
|
2022-11-15T15:41:07
|
|
TurboJPEG: Nix unneeded setDecodeDefaults ret val
The return value was inherited from setDecompDefaults() in
34dca052271f4a75b3c0f7b11a2c5024159628d4, but it was never needed.
|
|
|
e8b40f3c
|
2022-11-01T21:45:39
|
|
Vastly improve 12-bit JPEG integration
The Gordian knot that 7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac attempted
to unravel was caused by the fact that there are several
data-precision-dependent (JSAMPLE-dependent) fields and methods in the
exposed libjpeg API structures, and if you change the exposed libjpeg
API structures, then you have to change the whole API. If you change
the whole API, then you have to provide a whole new library to support
the new API, and that makes it difficult to support multiple data
precisions in the same application. (It is not impossible, as example.c
demonstrated, but using data-precision-dependent libjpeg API structures
would have made the cjpeg, djpeg, and jpegtran source code hard to read,
so it made more sense to build, install, and package 12-bit-specific
versions of those applications.)
Unfortunately, the result of that initial integration effort was an
unreadable and unmaintainable mess, which is a problem for a library
that is an ISO/ITU-T reference implementation. Also, as I dug into the
problem of lossless JPEG support, I realized that 16-bit lossless JPEG
images are a thing, and supporting yet another version of the libjpeg
API just for those images is untenable.
In fact, however, the touch points for JSAMPLE in the exposed libjpeg
API structures are minimal:
- The colormap and sample_range_limit fields in jpeg_decompress_struct
- The alloc_sarray() and access_virt_sarray() methods in
jpeg_memory_mgr
- jpeg_write_scanlines() and jpeg_write_raw_data()
- jpeg_read_scanlines() and jpeg_read_raw_data()
- jpeg_skip_scanlines() and jpeg_crop_scanline()
(This is subtle, but both of those functions use JSAMPLE-dependent
opaque structures behind the scenes.)
It is much more readable and maintainable to provide 12-bit-specific
versions of those six top-level API functions and to document that the
aforementioned methods and fields must be type-cast when using 12-bit
samples. Since that eliminates the need to provide a 12-bit-specific
version of the exposed libjpeg API structures, we can:
- Compile only the precision-dependent libjpeg modules (the
coefficient buffer controllers, the colorspace converters, the
DCT/IDCT managers, the main buffer controllers, the preprocessing
and postprocessing controller, the downsampler and upsamplers, the
quantizers, the integer DCT methods, and the IDCT methods) for
multiple data precisions.
- Introduce 12-bit-specific methods into the various internal
structures defined in jpegint.h.
- Create precision-independent data type, macro, method, field, and
function names that are prefixed by an underscore, and use an
internal header to convert those into precision-dependent data
type, macro, method, field, and function names, based on the value
of BITS_IN_JSAMPLE, when compiling the precision-dependent libjpeg
modules.
- Expose precision-dependent jinit*() functions for each of the
precision-dependent libjpeg modules.
- Abstract the precision-dependent libjpeg modules by calling the
appropriate precision-dependent jinit*() function, based on the
value of cinfo->data_precision, from top-level libjpeg API
functions.
|
|
|
5acd9f20
|
2022-10-04T12:58:11
|
|
Merge branch 'main' into dev
|
|
|
eb0a024a
|
2022-10-04T12:51:38
|
|
Remove redundant jconfigint.h #includes
Because of 607b668ff96e40fdc749de9b1bb98e7f40c86d93, jconfigint.h is
included by jinclude.h.
|
|
|
aa5a3599
|
2022-06-24T14:21:33
|
|
Merge branch 'main' into dev
|
|
|
ba22c0f7
|
2022-06-24T14:03:03
|
|
tjDecompressHeader3(): Accept tables-only streams
Inspired by:
https://github.com/amyspark/libjpeg-turbo/commit/b3b15cfe74cf07914122e26cf1e408a9a9cf3135
Closes #604
Closes #605
|
|
|
263386c2
|
2022-03-11T17:35:59
|
|
Merge branch 'main' into dev
|
|
|
a0148454
|
2022-03-11T10:50:47
|
|
Win: Fix build with Visual Studio 2010
(broken by 607b668ff96e40fdc749de9b1bb98e7f40c86d93)
- Visual Studio 2010 apparently doesn't have the snprintf() inline
function, so restore the macro that emulates that function using
_snprintf_s().
- Explicitly include errno.h in strtest.c, since jinclude.h doesn't
include it when building with Visual Studio.
|
|
|
7fec5074
|
2022-03-08T12:34:11
|
|
Support 8-bit & 12-bit JPEGs using the same build
Partially implements #199
This commit also implements a request from #178 (the ability to compile
the libjpeg example as a standalone program.)
|
|
|
9abeff46
|
2022-03-09T11:48:30
|
|
Remove extraneous #include directives
jinclude.h already includes stdio.h, stdlib.h, and string.h.
|
|
|
13377e6b
|
2022-02-11T13:58:31
|
|
MSVC: Eliminate int conversion warnings (C4244)
|
|
|
607b668f
|
2022-02-10T11:33:49
|
|
MSVC: Eliminate C4996 warnings in API libs
The primary purpose of this is to encourage adoption of libjpeg-turbo in
downstream Windows projects that forbid the use of "deprecated"
functions. libjpeg-turbo's usage of those functions was not actually
unsafe, because:
- libjpeg-turbo always checks the return value of fopen() and ensures
that a NULL filename can never be passed to it.
- libjpeg-turbo always checks the return value of getenv() and never
passes a NULL argument to it.
- The sprintf() calls in format_message() (jerror.c) could never
overflow the destination string buffer or leave it unterminated as
long as the buffer was at least JMSG_LENGTH_MAX bytes in length, as
instructed. (Regardless, this commit replaces those calls with
snprintf() calls.)
- libjpeg-turbo never uses sscanf() to read strings or multi-byte
character arrays.
- Because of b7d6e84d6a9283dc2bc50ef9fcaadc0cdeb25c9f, wrjpgcom
explicitly checks the bounds of the source and destination strings
before calling strcat() and strcpy().
- libjpeg-turbo always ensures that the destination string is
terminated when using strncpy().
(548490fe5e2aa31cb00f6602d5a478b068b99682 made this explicit.)
Regarding thread safety:
Technically speaking, getenv() is not thread-safe, because the returned
pointer may be invalidated if another thread sets the same environment
variable between the time that the first thread calls getenv() and the
time that that thread uses the return value. In practice, however, this
could only occur with libjpeg-turbo if:
(1) A multithreaded calling application used the deprecated and
undocumented TJFLAG_FORCEMMX/TJFLAG_FORCESSE/TJFLAG_FORCESSE2 flags in
the TurboJPEG API or set one of the corresponding environment variables
(which are only intended for testing purposes.) Since the TurboJPEG API
library only ever passed string constants to putenv(), the only inherent
risk (i.e. the only risk introduced by the library and not the calling
application) was that the SIMD extensions may have read an incorrect
value from one of the aforementioned environment variables.
or
(2) A multithreaded calling application modified the value of the
JPEGMEM environment variable in one thread while another thread was
reading the value of that environment variable (in the body of
jpeg_create_compress() or jpeg_create_decompress().) Given that the
libjpeg API provides a thread-safe way for applications to modify the
default memory limit without using the JPEGMEM environment variable,
direct modification of that environment variable by calling applications
is not supported.
Microsoft's implementation of getenv_s() does not claim to be
thread-safe either, so this commit uses getenv_s() solely to mollify
Visual Studio. New inline functions and macros (GETENV_S() and
PUTENV_S) wrap getenv_s()/_putenv_s() when building for Visual Studio
and getenv()/setenv() otherwise, but GETENV_S()/PUTENV_S() provide no
advantages over getenv()/setenv() other than parameter validation. They
are implemented solely for convenience.
Technically speaking, strerror() is not thread-safe, because the
returned pointer may be invalidated if another thread changes the locale
and/or calls strerror() between the time that the first thread calls
strerror() and the time that that thread uses the return value. In
practice, however, this could only occur with libjpeg-turbo if a
multithreaded calling application encountered a file I/O error in
tjLoadImage() or tjSaveImage(). Since both of those functions
immediately copy the string returned from strerror() into a thread-local
buffer, the risk is minimal, and the worst case would involve an
incorrect error string being reported to the calling application.
Regardless, this commit uses strerror_s() in the TurboJPEG API library
when building for Visual Studio. Note that strerror_r() could have been
used on Un*x systems, but it would have been necessary to handle both
the POSIX and GNU implementations of that function and perform
widespread compatibility testing. Such is left as an exercise for
another day.
Fixes #568
|
|
|
1f55ae7b
|
2022-01-06T12:08:46
|
|
Fix -Wpedantic compiler warnings
... and test for those warnings (and others) when performing CI builds.
|
|
|
17297239
|
2022-01-06T09:17:30
|
|
Eliminate non-ANSI C compatibility macros
libjpeg-turbo has never supported non-ANSI C compilers. Per the spec,
ANSI C compilers must have locale.h, stddef.h, stdlib.h, memset(),
memcpy(), unsigned char, and unsigned short. They must also handle
undefined structures.
|
|
|
173900b1
|
2021-09-02T12:48:50
|
|
tjTrans: Allow 8x8 crop alignmnt w/odd 4:4:4 JPEGs
Fixes #549
|
|
a72816ed
|
2021-07-16T09:37:06
|
|
Use uintptr_t, if avail, for pointer-to-int casts
Although sizeof(void *) == sizeof(size_t) for all architectures that are
currently supported by libjpeg-turbo, such is not guaranteed by the C
standard. Specifically, CHERI-enabled architectures (e.g. CHERI-RISC-V
or Arm's Morello) use capability pointers that are twice the size of
size_t (128 bits for Morello and RV64), so casting to size_t strips the
upper bits of the pointer (including the validity bit) and makes it
non-deferenceable, as indicated by the following compiler warning:
warning: cast from provenance-free integer type to pointer type will
give pointer that can not be dereferenced
[-Werror,-Wcheri-capability-misuse]
cvalue = values = (JCOEF *)PAD((size_t)values_unaligned, 16);
Ignoring this warning results in a run-time crash. Casting pointers to
uintptr_t, if it is available, avoids this problem, since uintptr_t is
defined as an unsigned integer type that can hold a pointer value.
Since C89 compatibility is still necessary in libjpeg-turbo, this commit
introduces a new typedef for pointer-to-integer casts that uses a
GNU-specific extension available in GCC 4.6+ and Clang 3.0+ and falls
back to using size_t if the extension is unavailable. The only other
options would require C99 or Clang-specific builtins.
Closes #538
|
|
|
e0606daf
|
2021-04-21T14:49:06
|
|
TurboJPEG: Update JPEG buf ptrs on comp/xform err
When using the in-memory destination manager, it is necessary to
explicitly call the destination manager's term_destination() method if
an error occurs. That method is called by jpeg_finish_compress() but
not by jpeg_abort_compress().
This fixes a potential double free() that could occur if tjCompress*()
or tjTransform() returned an error and the calling application tried to
clean up a JPEG buffer that was dynamically re-allocated by one of those
functions.
|
|
|
55ec9b3b
|
2021-04-21T11:04:42
|
|
OSS-Fuzz: Code comment tweaks for compr. targets
(oversight from 171b875b272f47f1ae42a5009c64f424db22a95b)
|
|
|
171b875b
|
2021-04-15T19:03:53
|
|
OSS-Fuzz: Check img size b4 readers allocate mem
After the completion of the start_input() method, it's too late to check
the image size, because the image readers may have already tried to
allocate memory for the image. If the width and height are excessively
large, then attempting to allocate memory for the image could slow
performance or lead to out-of-memory errors prior to the fuzz target
checking the image size.
NOTE: Specifically, the aforementioned OOM errors and slow units were
observed with the compression fuzz targets when using MSan.
|
|
|
47b66d1d
|
2021-04-09T11:26:34
|
|
OSS-Fuzz: Fix UBSan err caused by TJFLAG_FUZZING
|
|
|
34d264d6
|
2021-04-07T12:44:50
|
|
OSS-Fuzz: Private TurboJPEG API flag for fuzzing
This limits the tjLoadImage() behavioral changes to the scope of the
compress_fuzzer target. Otherwise, TJBench in fuzzer builds would
refuse to load images larger than 1 Mpixel.
|
|
|
d2d44655
|
2021-04-05T21:41:30
|
|
OSS-Fuzz: Compression fuzz target
|
|
|
c81e91e8
|
2021-04-05T16:08:22
|
|
TurboJPEG: New flag for limiting prog JPEG scans
This also fixes timeouts reported by OSS-Fuzz.
|
|
|
fe5b6a1c
|
2020-09-13T16:58:08
|
|
TJPEG: Remove unnecessary setCompDefaults() retval
setCompDefaults() hasn't thrown an error since
aa7459050d7a50e1d8a99488902d41fbc118a50f was introduced in 2.0.x.
|
|
|
ae87a958
|
2020-06-16T13:52:39
|
|
TurboJPEG: Make global error handling thread-safe
... on platforms that support thread-local storage. This currently
includes all supported platforms except 32-bit macOS.
Fixes #396
|
|
|
fdf89033
|
2020-01-07T15:23:08
|
|
Eliminate unnecessary NULL checks before free()
This programming practice (which exists in other code bases as well)
is a by-product of having used early C compilers that did not properly
handle free(NULL). All modern compilers should properly handle that.
Fixes #398
|
|
|
6367924a
|
2019-12-31T00:32:30
|
|
tjTransform(): Use instance err. for bad crop spec
Addresses a concern raised in #396
|
|
|
c0b16e3d
|
2019-11-15T13:29:11
|
|
TurboJPEG: Fix erroneous subsampling detection
... that caused some JPEG images with unusual sampling factors to be
misidentified as 4:4:4. This led to a buffer overflow when attempting
to decompress some such images using tjDecompressToYUV*().
Regression introduced by 479501b07c0afd8912a0e0f5b4740cfce9a89a4c
The correct behavior is for the TurboJPEG API to refuse to decompress
such images, which it did prior to the aforementioned commit.
Fixes #389
|
|
|
bd20344b
|
2019-11-12T15:45:20
|
|
tjDecompressToYUV*(): Fix OOB write/double free
... when attempting to decompress grayscale JPEG images with sampling
factors != 1.
Fixes #387
|
|
|
ded5a504
|
2019-08-15T13:24:25
|
|
tjDecodeYUV*: Fix err if TJ inst used for prog dec
If the TurboJPEG instance passed to tjDecodeYUV[Planes]() was previously
used to decompress a progressive JPEG image, then we need to disable the
progressive decompression parameters in the underlying libjpeg instance
before calling jinit_master_decompress().
This commit also modifies the build system so that the "tjtest" target
will test for this issue, and it corrects a previous oversight in the
build system whereby tjbenchtest did not test progressive
compression/decompression unless WITH_JAVA was true.
|
|
|
2a9e3bd7
|
2019-07-11T15:30:04
|
|
TurboJPEG: Properly handle gigapixel images
Prevent several integer overflow issues and subsequent segfaults that
occurred when attempting to compress or decompress gigapixel images with
the TurboJPEG API:
- Modify tjBufSize(), tjBufSizeYUV2(), and tjPlaneSizeYUV() to avoid
integer overflow when computing the return values and to return an
error if such an overflow is unavoidable.
- Modify tjunittest to validate the above.
- Modify tjCompress2(), tjEncodeYUVPlanes(), tjDecompress2(), and
tjDecodeYUVPlanes() to avoid integer overflow when computing the row
pointers in the 64-bit TurboJPEG C API.
- Modify TJBench (both C and Java versions) to avoid overflowing the
size argument to malloc()/new and to fail gracefully if such an
overflow is unavoidable.
In general, this allows gigapixel images to be accommodated by the
64-bit TurboJPEG C API when using automatic JPEG buffer (re)allocation.
Such images cannot currently be accommodated without automatic JPEG
buffer (re)allocation, due to the fact that tjAlloc() accepts a 32-bit
integer argument (oops.) Such images cannot be accommodated in the
TurboJPEG Java API due to the fact that Java always uses a signed 32-bit
integer as an array index.
Fixes #361
|
|
|
6399d0a6
|
2019-04-23T14:10:04
|
|
Fix code formatting/style issues ...
... including, but not limited to:
- unused macros
- private functions not marked as static
- unprototyped global functions
- variable shadowing
(detected by various non-default GCC 8 warning options)
|
|
|
bce58f48
|
2019-04-12T07:49:35
|
|
Consistify formatting of macros in TurboJPEG code
|
|
|
500b5ece
|
2019-02-17T09:06:42
|
|
turbojpeg.c: Fix compiler warning w/ -DNO_GETENV
|
|
|
479501b0
|
2019-01-21T13:57:55
|
|
TurboJPEG: Decompress 4:4:4 JPEGs with unusual SFs
Normally, 4:4:4 JPEGs have horizontal x vertical luminance & chrominance
sampling factors of 1x1. However, it is technically legal to create
4:4:4 JPEGs with sampling factors of 2x1, 1x2, 3x1, or 1x3, since the
sums of the products of those sampling factors are still <= 10. The
libjpeg API correctly decodes such images, so the TurboJPEG API should
as well.
Fixes #323
|
|
|
3d9c64e9
|
2019-01-01T18:57:36
|
|
tjLoadImage(): Fix int overflow/segfault w/big BMP
Fixes #304
|
|
|
696e754e
|
2018-06-12T18:49:37
|
|
TurboJPEG: Handle JERR_BMP*,JERR_PPM* error codes
... in tjLoadImage()/tjSaveImage(). These error codes require an add-on
message table, and if it isn't initialized, then format_message()
produces "Bogus message code XXXX" instead.
|
|
|
2401e4d1
|
2018-04-26T18:01:52
|
|
TurboJPEG: Handle CMYK JPEGs w/ subsampled M, Y
Arguably it doesn't make much sense for non-chroma components to be
subsampled (which is why this type of image was overlooked in
cd7c3e6672cce3779450c6dd10d0d70b0c2278b2-- I didn't realize it was a
thing), but certain Adobe applications apparently generate these images.
Fixes #236
|
|
|
58cb10ee
|
2018-03-31T13:51:31
|
|
Eliminate compiler warnings w/ Solaris Studio
|
|
|
293263c3
|
2018-03-17T15:14:35
|
|
Format preprocessor macros more consistently
Within the libjpeg API code, it seems to be more the convention than not
to separate the macro name and value by two or more spaces, which
improves general readability. Making this consistent across all of
libjpeg-turbo is less about my individual preferences and more about
making it easy to automatically detect variations from our chosen
formatting convention. I intend to release the script I'm using to
validate this stuff, once it matures and stabilizes a bit.
|
|
|
84fbd4f1
|
2018-03-17T00:27:49
|
|
Merge branch 'master' into dev
|
|
|
bd96b30b
|
2018-03-17T00:06:10
|
|
Make all get/putenv() calls compile-time optional
* Modify the SIMD dispatchers so they guard their usage of getenv() with
the existing NO_GETENV preprocessor definition.
* Introduce a new NO_PUTENV preprocessor definition to guard the
usage of putenv() in the TurboJPEG API library.
This at least puts Windows Store compatibility within the realm of
possibility, although further steps are required.
|
|
|
29e453f7
|
2018-03-16T14:09:53
|
|
turbojpeg.c: Fix Windows build
Broken by previous commit. Although turbojpeg.c no longer needs
tjutil.h on Un*x, it still needs to include that file on Windows in
order to use snprintf() and strcasecmp() (which, on Windows, are macros
that wrap _snprintf_s() and stricmp().)
|
|
|
19c791cd
|
2018-03-08T10:55:20
|
|
Improve code formatting consistency
With rare exceptions ...
- Always separate line continuation characters by one space from
preceding code.
- Always use two-space indentation. Never use tabs.
- Always use K&R-style conditional blocks.
- Always surround operators with spaces, except in raw assembly code.
- Always put a space after, but not before, a comma.
- Never put a space between type casts and variables/function calls.
- Never put a space between the function name and the argument list in
function declarations and prototypes.
- Always surround braces ('{' and '}') with spaces.
- Always surround statements (if, for, else, catch, while, do, switch)
with spaces.
- Always attach pointer symbols ('*' and '**') to the variable or
function name.
- Always precede pointer symbols ('*' and '**') by a space in type
casts.
- Use the MIN() macro from jpegint.h within the libjpeg and TurboJPEG
API libraries (using min() from tjutil.h is still necessary for
TJBench.)
- Where it makes sense (particularly in the TurboJPEG code), put a blank
line after variable declaration blocks.
- Always separate statements in one-liners by two spaces.
The purpose of this was to ease maintenance on my part and also to make
it easier for contributors to figure out how to format patch
submissions. This was admittedly confusing (even to me sometimes) when
we had 3 or 4 different style conventions in the same source tree. The
new convention is more consistent with the formatting of other OSS code
bases.
This commit corrects deviations from the chosen formatting style in the
libjpeg API code and reformats the TurboJPEG API code such that it
conforms to the same standard.
NOTES:
- Although it is no longer necessary for the function name in function
declarations to begin in Column 1 (this was historically necessary
because of the ansi2knr utility, which allowed libjpeg to be built
with non-ANSI compilers), we retain that formatting for the libjpeg
code because it improves readability when using libjpeg's function
attribute macros (GLOBAL(), etc.)
- This reformatting project was accomplished with the help of AStyle and
Uncrustify, although neither was completely up to the task, and thus
a great deal of manual tweaking was required. Note to developers of
code formatting utilities: the libjpeg-turbo code base is an
excellent test bed, because AFAICT, it breaks every single one of the
utilities that are currently available.
- The legacy (MMX, SSE, 3DNow!) assembly code for i386 has been
formatted to match the SSE2 code (refer to
ff5685d5344273df321eb63a005eaae19d2496e3.) I hadn't intended to
bother with this, but the Loongson MMI implementation demonstrated
that there is still academic value to the MMX implementation, as an
algorithmic model for other 64-bit vector implementations. Thus, it
is desirable to improve its readability in the same manner as that of
the SSE2 implementation.
|
|
|
bd544e28
|
2017-12-16T09:34:28
|
|
Merge branch 'master' into dev
|
|
|
bf6c7743
|
2017-12-07T19:29:42
|
|
Fix whitespace errors
|
|
|
9f1f86bf
|
2017-11-19T09:18:36
|
|
tjLoadImage(): Fix OOB array access w/TJPF_UNKNOWN
Because the previous commit added a test for TJPF_UNKNOWN to tjunittest,
the ASAN CI build detected this issue.
|
|
|
8c40ac8a
|
2017-11-16T18:46:01
|
|
Add TurboJPEG C example and clean up Java example
Also rename example.c --> example.txt and add a disclaimer to that file
so people will stop trying to compile it.
|
|
|
aa745905
|
2017-11-16T18:09:07
|
|
TurboJPEG C API: Add BMP/PPM load/save functions
The main justification for this is to provide new libjpeg-turbo users
with a quick & easy way of developing a complete JPEG
compression/decompression program without requiring them to build
libjpeg-turbo from source (which was necessary in order to use the
project-private bmp API) or to use external libraries. These new
functions build upon significant enhancements to rdbmp.c, wrbmp.c,
rdppm.c, and wrppm.c which allow those engines to convert directly
between the native pixel format of the file and a pixel format
("colorspace" in libjpeg parlance) specified by the calling program.
rdbmp.c and wrbmp.c have also been modified such that the calling
program can choose to read or write image rows in the native (bottom-up)
order of the file format, thus eliminating the need to use an inversion
array. tjLoadImage() and tjSaveImage() leverage these new underlying
features in order to significantly improve upon the performance of the
old bmp API.
Because these new functions cannot work without the libjpeg-turbo
colorspace extensions, the libjpeg-compatible code in turbojpeg.c has
been removed. That code was only there to serve as an example of how
to use the TurboJPEG API on top of libjpeg, but more specific, buildable
examples now exist in the https://github.com/libjpeg-turbo/ijg
repository.
|
|
|
4893e5d8
|
2017-11-17T19:00:53
|
|
Merge branch 'master' into dev
|
|
|
94e152b1
|
2017-11-13T08:15:50
|
|
TurboJPEG C: Code formatting tweaks
|
|
|
616b4e2d
|
2017-09-20T19:55:54
|
|
TurboJPEG C: Compiler warnings
Introduced in b9ab64d8dbee2db829e59357d335c151680f44f0.
|
|
|
9baef107
|
2017-06-29T12:08:02
|
|
TurboJPEG: Don't make STOPONWARNING persistent
Due to an oversight in d4092f6b4dd94c64864662987b070d517c399490,
the state of TJFLAG_STOPONWARNING persisted beyond the function it
was passed to.
|
|
|
dadebcd7
|
2017-06-28T11:43:08
|
|
TurboJPEG: Add "copy none", progressive xform opts
Allow progressive entropy coding to be enabled on a
transform-by-transform basis, and implement a new transform option for
disabling the copying of markers.
Closes #153
|
|
|
aba6ae59
|
2017-06-27T13:24:08
|
|
TurboJPEG: Opt. enable progressive entropy coding
Fulfills part of the feature request in #153. Also paves the way for
SIMD-accelerated progressive Huffman coding (refer to #46.)
|
|
|
d4092f6b
|
2017-06-27T10:54:21
|
|
TurboJPEG: Improve error handling
- Provide a new C API function and TJException method that allows
calling programs to query the severity of a compression/decompression/
transform error.
- Provide a new flag that instructs the library to immediately stop
compressing/decompressing/transforming if a warning is encountered.
Fixes #151
|
|
|
b9ab64d8
|
2017-05-11T21:02:29
|
|
TurboJPEG: Thread-safe error message retrieval
Introduce a new C API function (tjGetErrorStr2()) that can be used to
retrieve compression/decompression/transform error messages in a
thread-safe (i.e. instance-specific) manner. Retrieving error messages
from global functions is still thread-unsafe.
Addresses a concern expressed in #151.
|
|
|
2ac4e9d9
|
2017-06-26T21:58:32
|
|
Merge branch 'master' into dev
|
|
|
d4c41fe0
|
2017-03-18T12:56:36
|
|
TurboJPEG: Fix potential memory leaks
Referring to https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=746,
it seems that the values of local buffer pointers in TurboJPEG API
functions aren't always preserved if longjmp() returns control to a
point prior to the allocation of the local buffers. This is known to
be an issue with GCC 4.x and clang with -O1 and higher optimization
levels but not with GCC 5.x and later. It is unknown why GCC 5.x and
6.x do not suffer from the issue, but possibly the local buffer pointers
are not allocated on the stack when using those more recent compilers.
In any case, this commit modifies the TurboJPEG API library code such
that the jump buffer is always updated after any local buffer pointers
are allocated but before any subsequent libjpeg API functions are
called.
|
|
|
6c365686
|
2016-09-20T18:09:15
|
|
Merge branch 'master' into dev
|
|
|
8ce2c911
|
2016-08-01T11:22:24
|
|
TurboJPEG: Decomp. 4:2:2/4:4:0 JPEGs w/unusual SFs
Normally, 4:2:2 JPEGs have horizontal x vertical luminance,chrominance
sampling factors of 2x1,1x1, and 4:4:0 JPEGs have horizontal x vertical
luminance,chrominance sampling factors of 1x2,1x1. However, it is
technically legal to create 4:2:2 JPEGs with sampling factors of
2x2,1x2 and 4:4:0 JPEGs with sampling factors of 2x2,2x1, since the
sums of the products of those sampling factors (2x2 + 1x2 + 1x2 and
2x2 + 2x1 + 2x1) are still <= 10. The libjpeg API correctly decodes
such images, so the TurboJPEG API should as well.
Fixes #92
|
|
|
db044351
|
2016-07-14T13:36:47
|
|
Silence pedantic GCC6 code formatting warnings
Apparently it's "misleading" to put two self-contained if statements
on a single line. Who knew?
|
|
|
7ee3ce9a
|
2016-07-05T16:19:26
|
|
Lay the groundwork for 32-bit AVX2 SIMD support
|
|
|
3c67d4f7
|
2016-04-20T11:27:42
|
|
Catch libjpeg errors in tjDecompressToYUV2()
Even though tjDecompressToYUV2() is mostly just a wrapper for
tjDecompressToYUVPlanes(), tjDecompressToYUV2() still calls
jpeg_read_header(), so it needs to properly set up the libjpeg error
handler prior to making this call. Otherwise, under very esoteric (and
arguably incorrect) use cases, a program could call tjDecompressToYUV2()
without first checking the JPEG header using tjDecompressHeader3(), and
if the header was corrupt, then the libjpeg API would invoke
my_error_exit(). my_error_exit() would in turn call longjmp() on the
previous value of myerr->setjmp_buffer, which was probably set in a
previous TurboJPEG function, such as tjInitDecompress(). Thus, when a
libjpeg error was triggered within the body of tjDecompressToYUV2(), the
PC would jump to the error handler of the previous TurboJPEG function,
and this usually caused stack corruption in the calling program (because
the signature and return type of the previous TurboJPEG function
probably wasn't the same as that of tjDecompressToYUV2().)
|
|
|
dec79952
|
2016-04-20T11:27:42
|
|
Catch libjpeg errors in tjDecompressToYUV2()
Even though tjDecompressToYUV2() is mostly just a wrapper for
tjDecompressToYUVPlanes(), tjDecompressToYUV2() still calls
jpeg_read_header(), so it needs to properly set up the libjpeg error
handler prior to making this call. Otherwise, under very esoteric (and
arguably incorrect) use cases, a program can call tjDecompressToYUV2()
without first checking the JPEG header using tjDecompressHeader3(), and
if the header is corrupt, tjDecompressToYUV2() will abort without
triggering an error.
Fixes #72
|
|
|
55a18d40
|
2016-02-04T18:52:23
|
|
Merge branch '1.4.x'
|
|
|
6e053525
|
2016-02-04T09:20:41
|
|
TurboJPEG: Avoid dangling pointers
This addresses a minor concern (LJT-01-002) expressed in a security
audit by Cure53. _tjInitCompress() and _tjInitDecompress() call
(respectively) jpeg_mem_dest_tj() and jpeg_mem_src_tj() with a pointer
to a dummy buffer, in order to set up the destination/source manager.
The dummy buffer should never be used, but it's still better to make it
static so that the pointer in the destination/source manager always
points to a valid region of memory.
|
|
|
b6576319
|
2015-08-26T20:31:13
|
|
Merge branch '1.4.x'
|
|
|
58ae401e
|
2015-08-26T20:29:36
|
|
Eliminate cppcheck false positive in turbojpeg.c
|
|
|
6fa14b37
|
2015-08-13T20:06:03
|
|
Declare source buffers in TurboJPEG C API as const
This reassures the caller that the buffers will not be modified and also
allows read-only buffers to be passed to the functions.
Partially reverts 3947a19f25fc8186d3812dbcf8e70baea36ef652.
|
|
db6d8fca
|
2015-06-08T18:31:34
|
|
Now that the TurboJPEG API is reporting libjpeg warnings as errors, an "Invalid SOS parameters for sequential JPEG" warning surfaced in tjDecodeYUV*(). This was caused by the Se member of jpeg_decompress_struct being set to 0 (it is normally set to a non-zero value when the start-of-scan markers are read, but there are no SOS markers in this case, because we're not actually decompressing a JPEG file.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1564 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
1f79c7c8
|
2015-06-01T19:22:41
|
|
If a warning (such as "Premature end of JPEG file") is triggered in the underlying libjpeg API, make sure that the TurboJPEG API function returns -1. Unlike errors, however, libjpeg warnings do not make the TurboJPEG functions abort.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1561 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
bec45b16
|
2015-05-17T15:56:18
|
|
Back out r1555 and r1548. Using setenv() didn't fix the iOS simulator issue. It just replaced an undefined _putenv$UNIX2003 symbol with an undefined _setenv$UNIX2003 symbol. The correct solution seems to be to use -D_NONSTD_SOURCE when generating our official builds.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1557 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
80bbd390
|
2015-05-16T04:18:21
|
|
Fix the Windows build. I remember now why I used putenv() originally-- because Windows doesn't have setenv(). We could use _putenv_s(), but older versions of MinGW don't have that either. Fortunately, since all of the environment values we're setting in turbojpeg.c are static, we can just map setenv() to putenv() using a macro. NOTE: we still have to use _putenv_s() in turbojpeg-jni.c, but at least people who may need to build with an older version of MinGW can still do so by disabling the Java build.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1555 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
44320a21
|
2015-05-15T18:23:59
|
|
Unless you define _ANSI_SOURCE, then putenv() on Mac is renamed to putenv$UNIX2003(), and this causes problems when trying to link an i386 iOS application (for the simulator) against the TurboJPEG static library. It's easiest to just use setenv() instead.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1548 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
feccdcf8
|
2015-02-23T19:19:40
|
|
Surround the usage of getenv() in the TurboJPEG API with #ifndef NO_GETENV so that developers can add -DNO_GETENV to the C flags when building for platforms that don't have getenv(). Currently this is known to be necessary when building for Windows Phone.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1537 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0426cd34
|
2014-11-21T15:33:19
|
|
Sometimes the sampling factors in grayscale images can be > 1 (for instance, if compressing using 'cjpeg -sample 2x2 -grayscale'.) Technically, sampling factors have no meaning with grayscale JPEGs, and the libjpeg decompressor ignores them in that case. Thus, the TurboJPEG decompressor should ignore them as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1419 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ea1eea47
|
2014-11-19T00:55:28
|
|
Sometimes the sampling factors in grayscale images can be > 1 (for instance, if compressing using 'cjpeg -sample 2x2 -grayscale'.) Technically, sampling factors have no meaning with grayscale JPEGs, and the libjpeg decompressor ignores them in that case. Thus, the TurboJPEG decompressor should ignore them as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1418 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
55620c6e
|
2014-10-23T19:08:14
|
|
Another oops. tjBufSizeYUV2() should return -1 if width < 1.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1410 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2240974d
|
2014-10-23T18:54:42
|
|
Oops. tjPlaneSizeYUV() should return -1 if componentID > 0 and subsamp==TJSAMP_GRAY.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1408 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0713c1bb
|
2014-08-22T13:43:33
|
|
Add a set of undocumented environment variables and Java system properties that allow compression features of libjpeg that are not normally exposed in the TurboJPEG API to be enabled. These features are not normally exposed because, for the most part, they aren't "turbo" features, but it is still useful to be able to benchmark them without modifying the code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1376 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
40dd3146
|
2014-08-17T12:23:49
|
|
Refactored YUVImage Java class so that it supports both unified YUV image buffers as well as separate YUV image planes; modified the JNI functions accordingly and added new helper functions to the TurboJPEG C API (tjPlaneWidth(), tjPlaneHeight(), tjPlaneSizeYUV()) to facilitate those modifications; changed potentially confusing "component width" and "component height" terms to "plane width" and "plane height" and modified variable names in turbojpeg.c to reflect this; numerous other documentation tweaks
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1360 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
aecea388
|
2014-08-11T18:05:41
|
|
Extend the TurboJPEG C API to support handling YUV images stored in separate image planes instead of a unified buffer
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1343 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
5de454b2
|
2014-05-18T19:04:03
|
|
libjpeg-turbo has never supported non-ANSI compilers, so get rid of the crufty SIZEOF() macro. It was not being used consistently anyhow, so it would not have been possible to build prior releases of libjpeg-turbo using the broken compilers for which that macro was designed.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1313 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
bc56b754
|
2014-05-16T10:43:44
|
|
Get rid of the HAVE_PROTOTYPES configuration option, as well as the related JMETHOD and JPP macros. libjpeg-turbo has never supported compilers that don't handle prototypes. Doing so requires ansi2knr, which isn't even supported in the IJG code anymore.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1308 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
f57b8a63
|
2014-05-06T09:41:08
|
|
Phrasing. Boom.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1268 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
230d09db
|
2014-04-20T09:42:49
|
|
Fix crashes and bogus output in the CMYK and decode-to-YUV features that occurred if JCS_EXTENSIONS wasn't defined.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1260 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
0c989d9e
|
2014-04-17T00:47:18
|
|
Fix warnings about unused variables when building with GCC 4.8.x
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1242 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
41861626
|
2014-04-16T23:38:37
|
|
Fix warnings about unused variables when building with GCC 4.8.x
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1241 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
05d24e82
|
2014-03-10T21:38:11
|
|
Fix Windows build
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1147 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
42aeac3e
|
2014-03-10T21:37:54
|
|
Formatting tweaks
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1146 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
7d9f758e
|
2014-03-10T20:14:53
|
|
For now, punt on trying to support fancy upsampling in tjDecodeYUV(). Fancy upsampling requires context rows and other refinements, which are difficult to implement correctly with the algorithm we're using. Longer-term, supporting fancy upsampling would probably require using the main buffer that libjpeg allocates.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1145 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
15c08761
|
2014-03-10T20:11:56
|
|
Fix additional uninitialized values reported by valgrind
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1144 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
c9014495
|
2014-03-10T09:34:04
|
|
When tjDecodeYUV() is used with a "fresh" decompressor instance (one that hasn't been previously used to decompress a JPEG image), then it needs comps_in_scan, data_precision, and the quantization tables to be defined. This patch also extends TJUnitTest to check for this error.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1143 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2bdc0425
|
2014-03-07T03:52:57
|
|
Go ahead and call jinit_master_decompress() rather than trying to reproduce its functionality. That function does a few things that we were missing, including allocating the range limit table used by the plain C color conversion code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1139 632fc199-4ca6-4c93-a231-07263d6284db
|