|
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
|
|
|
4d82ddb0
|
2014-03-06T20:07:03
|
|
Oops. We need to call start_pass() on the color converter in order to allocate the conversion tables used by the plain C code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1138 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
50cfc464
|
2014-03-06T20:03:37
|
|
Oops. We need to call start_pass() on the color converter in order to allocate the conversion tables used by the plain C code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1137 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
84c25cbe
|
2014-03-06T19:51:29
|
|
Oops. We need to call start_pass() on the color converter in order to allocate the conversion tables used by the plain C code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1136 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
895fd6d0
|
2014-02-28T09:35:34
|
|
Fix unitialized value reported by valgrind (the upsampling routine used by 4:4:0 and 4:1:1 reads the value of component_index.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1133 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
34dca052
|
2014-02-28T09:17:14
|
|
Implement a YUV decode function in the TurboJPEG API, to be symmetric with tjEncodeYUV().
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1132 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
54918b37
|
2014-02-28T05:34:02
|
|
Remove unused code (the destination manager is not used during YUV encoding, there are no virtual arrays to realize, and jinit_c_prep_controller() is unnecessary because we are not using smoothing.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1130 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
e2ce3b5e
|
2014-02-28T05:27:55
|
|
Remove unused code (the destination manager is not used during YUV encoding, there are no virtual arrays to realize, and jinit_c_prep_controller() is unnecessary because we are not using smoothing.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1129 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
5aec4afc
|
2014-02-28T05:23:26
|
|
Use C-style comments
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1127 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
c7a32466
|
2014-02-28T05:19:43
|
|
Remove unused code (the destination manager is not used during YUV encoding, there are no virtual arrays to realize, and jinit_c_prep_controller() is unnecessary because we are not using smoothing.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1126 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
006bc58d
|
2014-02-27T21:22:54
|
|
Use C-style comments
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1125 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
693f4a56
|
2014-02-11T10:16:42
|
|
Fix an issue that prevented tjEncodeYUV2() and TJCompressor.encodeYUV() from working properly if the source image was very tiny. Basically, jpeg_start_compress() was attempting to write the JPEG headers, which was overrunning the YUV buffer. This patch removes the call to jpeg_start_compress() in tjEncodeYUV2() and replaces it with calls to the individual routines that are necessary to initialize the color converter and downsampler. TJUnitTest has also been modified to test for this condition (the buffer size regression test now works in YUV mode.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1121 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2c0c807f
|
2014-02-11T09:56:12
|
|
Fix an issue that prevented tjEncodeYUV2() and TJCompressor.encodeYUV() from working properly if the source image was very tiny. Basically, jpeg_start_compress() was attempting to write the JPEG headers, which was overrunning the YUV buffer. This patch removes the call to jpeg_start_compress() in tjEncodeYUV2() and replaces it with calls to the individual routines that are necessary to initialize the color converter and downsampler. TJUnitTest has also been modified to test for this condition (the buffer size regression test now works in YUV mode.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1120 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
38c9970b
|
2014-02-11T09:45:18
|
|
Fix an issue that prevented tjEncodeYUV3() and TJCompressor.encodeYUV() from working properly if the source image was very tiny. Basically, jpeg_start_compress() was attempting to write the JPEG headers, which was overrunning the YUV buffer. This patch removes the call to jpeg_start_compress() in tjEncodeYUV3() and replaces it with calls to the individual routines that are necessary to initialize the color converter and downsampler. TJUnitTest has also been modified to test for this condition (the buffer size regression test now works in YUV mode.)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1118 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
b51ee895
|
2013-10-31T05:00:19
|
|
r1065 broke the build on Windows, because getinstance() defines a variable. Thus, it needs to occur before the array initialization code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1069 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
910a3572
|
2013-10-30T23:02:57
|
|
Extend the TurboJPEG C API to support compressing JPEG images from YUV planar images
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1067 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
eaa31f52
|
2013-10-30T22:21:58
|
|
Oops
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1066 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
e2f8e694
|
2013-10-30T22:21:06
|
|
Fix a really subtle issue whereby an invalid free() could occur if a program called tjInitDecompress() and then accidentally passed the handle to tjEncodeYUV3(), or if a program called tjInitCompress() and then accidentally passed the handle to tjDecompressToYUV2().
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1065 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
6cef2b10
|
2013-10-30T22:12:37
|
|
Fix a really subtle issue whereby an invalid free() could occur if a program called tjInitDecompress() and then accidentally passed the handle to tjEncodeYUV2(), or if a program called tjInitCompress() and then accidentally passed the handle to tjDecompressToYUV().
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1064 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
cd7c3e66
|
2013-08-23T02:49:25
|
|
Add CMYK support to the TurboJPEG C API
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1019 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
1f3635c4
|
2013-08-18T10:19:00
|
|
Add 4:1:1 subsampling support in the TurboJPEG C API
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1014 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
418fe286
|
2013-05-07T21:17:35
|
|
Fix incorrect data output and buffer overruns in the new tjDecompressToYUV2() function whenever scaling is used along with a 4:2:0 JPEG image; extend tjunittest and TJUnitTest to test for these issues.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@982 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
f610d61f
|
2013-04-26T10:33:29
|
|
Extend the TurboJPEG C API to support generating YUV images with arbitrary padding and to support image scaling when decompressing to YUV
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@962 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
bdfcb74d
|
2013-01-22T13:56:34
|
|
Actually, turbojpeg.c works with libjpeg as well
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@920 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
5039d734
|
2013-01-21T23:42:12
|
|
Eliminated the awkward and confusing "TurboJPEG/OSS" designation, since there are no other active implementations of the TurboJPEG API anymore; don't refer to the libjpeg API library as "libjpeg-turbo" anymore, since that can be confusing; ARM v7s build instructions
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@919 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
2186809a
|
2012-07-03T20:02:49
|
|
Oops. Add support for TJFLAG_FASTDCT to tjDecompressToYUV() as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@856 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
e0419b53
|
2012-07-03T20:01:31
|
|
Oops. Add support for TJFLAG_FASTDCT to tjDecompressToYUV() as well.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@855 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
73d74c13
|
2012-06-29T23:46:38
|
|
Add flags to the TurboJPEG API that allow the caller to force the use of either the fast or the accurate DCT/IDCT algorithms in the underlying codec.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@851 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
fd3aba35
|
2012-06-29T23:14:48
|
|
Added flags to the TurboJPEG API that allow the caller to force the use of either the fast or the accurate DCT/IDCT algorithms in the underlying codec.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@849 632fc199-4ca6-4c93-a231-07263d6284db
|
|
|
ea3396a9
|
2012-04-26T03:18:49
|
|
Fix memory leak in the colorspace emulation code
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@827 632fc199-4ca6-4c93-a231-07263d6284db
|