Commit Graph

230 Commits

Author SHA1 Message Date
DRC
dec79952d6 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
2016-04-20 11:39:51 -05:00
DRC
55a18d4007 Merge branch '1.4.x' 2016-02-04 18:52:23 -06:00
DRC
6e053525ee 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.
2016-02-04 09:20:41 -06:00
DRC
b657631953 Merge branch '1.4.x' 2015-08-26 20:31:13 -05:00
DRC
58ae401e50 Eliminate cppcheck false positive in turbojpeg.c 2015-08-26 20:29:36 -05:00
DRC
6fa14b37ee 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.
2015-08-13 20:08:08 -05:00
DRC
a8af72437e 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
2015-06-08 18:31:34 +00:00
DRC
db6d8fca59 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
2015-06-08 18:31:34 +00:00
DRC
b3954883af 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
2015-06-01 19:22:41 +00:00
DRC
1f79c7c8c8 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
2015-06-01 19:22:41 +00:00
DRC
f24385c465 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
2015-05-17 15:56:18 +00:00
DRC
bec45b162b 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
2015-05-17 15:56:18 +00:00
DRC
a19f3a9c7a 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
2015-05-16 04:18:21 +00:00
DRC
80bbd3908f 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
2015-05-16 04:18:21 +00:00
DRC
83649cc19b 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
2015-05-15 18:23:59 +00:00
DRC
44320a210b 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
2015-05-15 18:23:59 +00:00
DRC
54e17215e6 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
2015-02-23 19:19:40 +00:00
DRC
feccdcf8c8 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
2015-02-23 19:19:40 +00:00
Kornel Lesiński
f2ec34de52 Merge branch 'libjpeg-turbo'
* libjpeg-turbo: (39 commits)
  Oops.  Delete the duplicate copy of [lib]turbojpeg.dll in the binary directory when uninstalling the package.
  AltiVec SIMD implementation of sample conversion and integer quantization
  Document the fact that the AltiVec implementation uses the same modified algorithms as the SSE2 implementation
  Use intrinsics for loading/storing data in the DCT/IDCT functions.  This has no effect on the performance of the aligned loads/stores, but it makes it more obvious what that code is doing.  Using intrinsics for the unaligned stores in the inverse DCT functions increases overall decompression performance by 1-2%.
  AltiVec SIMD implementation of RGB-to-Grayscale color conversion
  Remove unneeded code;  Make sure jccolor-altivec.o will be rebuilt if jccolext-altivec.c changes.
  AltiVec SIMD implementation of RGB-to-YCC color conversion
  Make test a phony target so things don't go haywire if there is a file named test.c in the current directory.
  Maintain the traditional order of the regression tests while allowing the TurboJPEG and libjpeg portions to be executed separately
  Make comments more consistent
  Add a "quicktest" pseudo-target, for those times when you just don't want to sit through 11 iterations of TJUnitTest.
  Cosmetic tweaks to the PowerPC SIMD stubs
  Split AltiVec algorithms into separate files for ease of maintenance;  Rename constants using lowercase so they are not confused with macros
  Optimizations to the AltiVec DCT algorithms (pre-compute constants and combine multiply/add operations)
  AltiVec SIMD implementation of slow integer inverse DCT
  Use macros to allocate constants statically, rather than reading them from a table using vec_splat*().  This improves code readability and probably improves performance a bit as well.
  Swap the order of the IFAST and ISLOW FDCT functions so that it matches the order of the prototypes in jsimd.h and the stubs in jsimd_powerpc.c.
  Include ARMv8 binaries when generating a combined OS X/iOS package using 'make iosdmg'
  In the output of the configure script, indicate whether gas-preprocessor.pl is being used along with the assembler.
  Modify the ARM64 assembly file so that it uses only syntax that the clang assembler in XCode 5.x can understand.  These changes should all be cosmetic in nature-- they do not change the meaning or readability of the code nor the ability to build it for Linux.  Actually, the code is now more in compliance with the ARM64 programming manual.  In addition to these changes, there were a couple of instructions that clang simply doesn't support, so gas-preprocessor.pl was modified so that it now converts those into equivalent instructions that clang can handle.
  ...

Conflicts:
	BUILDING.txt
	ChangeLog.txt
	cjpeg.c
	jpegtran.c
2015-01-07 23:33:49 +00:00
DRC
7432a53e2b Introduce a TJ_REVERT environment variable, which reverts the behavior of the TurboJPEG API to libjpeg[-turbo] defaults.
This serves the same purpose as the -revert switch in cjpeg.  It is primarily
included for testing purposes.
2014-12-14 04:43:02 -06:00
DRC
3e2cf6909c Convert JBOOLEAN_USE_MOZ_DEFAULTS into an integer "compression profile" parameter
This eliminates JBOOLEAN_USE_MOZ_DEFAULTS and replaces it with
JINT_COMPRESS_PROFILE, a more flexible and descriptive parameter.  Currently,
this new parameter works in much the same way as the old-- it changes the
behavior of jpeg_set_defaults().  It currently supports only two values
(max. compression, i.e. mozjpeg defaults, and fastest, i.e. libjpeg-turbo
defaults), but it can be extended in the future with additional profiles that
balance compression ratio with performance.
2014-12-14 01:56:26 -06:00
DRC
9cb270a216 Use mozjpeg defaults by default
Since mozjpeg is now backward ABI-compatible with libjpeg[-turbo], it is now
possible to temporarily load mozjpeg into a binary application and cause that
application to generate uber-compressed JPEGs (at the expense of an extreme
performance loss, of course.)  For instance, someone could do

LD_LIBRARY_PATH=/opt/mozjpeg/lib convert blah_blah_blah

to make ImageMagick use mozjpeg instead of the system's pre-installed JPEG
library (libjpeg-turbo, in most cases.)  However, this only makes sense if
mozjpeg is actually producing different behavior by default than libjpeg-turbo.
Currently it isn't.  Currently it requires the application to set
JBOOLEAN_USE_MOZ_DEFAULTS to TRUE in order to enable the mozjpeg-specific
behavior, but of course applications that were built to use libjpeg[-turbo]
won't do that.  Thus, this patch sets use_moz_defaults to TRUE by default,
requiring an application to explicitly set it to FALSE in order to revert to
the libjpeg[-turbo] behavior (makes sense, since the only applications that
would need to revert to the libjpeg[-turbo] behavior would be mozjpeg-aware
applications.)

Note that we discussed the possibility of adding a function
(jpeg_revert_defaults()), which would act the same as jpeg_set_defaults() does
in libjpeg[-turbo].  This is a good solution for implementing the -revert
switch in cjpeg, but unfortunately it doesn't work for jpegtran.  The reason
is that jpeg_set_defaults() is called within the body of
jpeg_copy_critical_parameters(), which is part of the API.  So yet again,
if mozjpeg were loaded into a non-mozjpeg-aware application at run time, it
would be desirable for jpeg_copy_critical_parameters() to set the parameters
to mozjpeg defaults.  That means that, in order to implement the -revert
switch in jpegtran, it would be necessary to introduce a new function
(jpeg_revert_critical_parameters(), perhaps).  It seems cleaner to just keep
using the JBOOLEAN_USE_MOZ_DEFAULTS parameter to control the behavior of
jpeg_set_defaults(), even though this represents a minor abuse of the libjpeg
API (jpeg_set_defaults() is technically supposed to set all of the parameters
to defaults, irrespective of any previous state.  However, as long as we
document that JBOOLEAN_USE_MOZ_DEFAULTS works differently, then it should be
OK.)
2014-11-19 23:31:20 -06:00
DRC
d1e39740b2 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
2014-11-19 00:55:28 +00:00
DRC
ea3df2f662 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
2014-11-21 15:33:19 +00:00
DRC
ea1eea4742 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
2014-11-19 00:55:28 +00:00
DRC
24ad6a0179 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://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1417 632fc199-4ca6-4c93-a231-07263d6284db
2014-11-19 00:54:39 +00:00
Josh Aas
e6dd72874e Merge pull request #121 from dcommander/libjpeg-turbo-diff-review
Documentation and code cleanup from DRC
2014-11-18 17:58:36 -06:00
Josh Aas
445d9b4196 Merge pull request #120 from pornel/libjpeg-turbo
Libjpeg turbo sync
2014-11-17 22:52:38 -06:00
Kornel Lesiński
3554fdb9cf Merge branch 'libjpeg-turbo'
* libjpeg-turbo:
  Remove trailing spaces
  Another oops.  tjBufSizeYUV2() should return -1 if width < 1.
  Oops.  tjPlaneSizeYUV() should return -1 if componentID > 0 and subsamp==TJSAMP_GRAY.
  The AltiVec code actually works on 32-bit PowerPC platforms as well, so change the "powerpc64" token to "powerpc".  Also clean up the shift code, which wasn't building properly on OS X.
  AltiVec SIMD implementation of fast forward DCT
  Bump version to 1.5 alpha1 to prepare for new features
  When building libjpeg-turbo on Un*x systems, INT32 is usually typedef'ed to long, not int, so we need to specify an int pointer when doing a 4-byte write to the RGB565 output buffer.  On little endian systems, this doesn't matter, but when you write a 32-bit int to a 64-bit long pointer address on a big endian system, you are writing to the upper 4 bytes, not the lower 4 bytes.  NOTE: this will probably break on big endian systems that use 16-bit ints (are there any of those still around?)
  Fix Windows build
  Fix issues with RGB565 color conversion on big endian machines.  The RGB565 routines are now abstracted in a separate file, with separate little-endian and big-endian versions defined at compile time through the use of macros (this is similar to how the colorspace extension routines work.)  This allows big-endian machines to take advantage of the same performance optimizations as little-endian machines, and it retains the performance on little-endian machines, since the conditional branch for endianness is at a very coarse-grained level.
  Fix build on OS X PowerPC platforms
  Oops.  Forgot to alter the version header in the change log to indicate the release of 1.4 beta.
2014-11-08 16:36:45 +00:00
DRC
ebc7c3a760 Reconcile indentation, whitespace, and other code formatting with libjpeg-turbo.
For whatever reason, some of these files didn't get fully merged from
libjpeg-turbo 1.4.  They still contained tab characters and other formatting
conventions from libjpeg-turbo 1.3.  This patch also fixes some obvious
indentation errors in the mozjpeg-specific code.  There is more formatting work
that needs to be done to the mozjpeg-specific code, to fix line overruns,
incorrect operator whitespace, and other issues that make it not consistent
with the libjpeg/libjpeg-turbo code.
2014-11-06 01:14:11 -06:00
DRC
db2986c96f Restore backward ABI compatibility with libjpeg/libjpeg-turbo by moving the mozjpeg-specific parameters into the opaque jpeg_comp_master struct and implementing generic accessor functions for getting/setting those parameters. These functions can be used upstream, if the need for them arises in libjpeg-turbo, and they can also be easily extended to cover future extensions to the decompressor. Note that, in order to use jpeg_comp_master as a repository for extension parameters, cinfo->master is now allocated within the body of jpeg_CreateCompress(). It is later re-allocated in jinit_c_master_control(), because that function (and others in jcmaster.c) use an extended form of jpeg_comp_master, but the existing extension parameters are copied into the new master instance. Similar modifications would need to be made to the decompressor to support the same type of extension framework. 2014-11-04 01:58:52 -06:00
DRC
c42b9ca3ef 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
2014-10-23 19:08:14 +00:00
DRC
55620c6ef2 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
2014-10-23 19:08:14 +00:00
DRC
338ac421d7 Another oops. tjBufSizeYUV2() should return -1 if width < 1.
git-svn-id: svn://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1409 632fc199-4ca6-4c93-a231-07263d6284db
2014-10-23 19:07:25 +00:00
DRC
86d57c6787 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
2014-10-23 18:54:42 +00:00
DRC
2240974d5d 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
2014-10-23 18:54:42 +00:00
DRC
1083a3bffb Oops. tjPlaneSizeYUV() should return -1 if componentID > 0 and subsamp==TJSAMP_GRAY.
git-svn-id: svn://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1407 632fc199-4ca6-4c93-a231-07263d6284db
2014-10-23 18:53:20 +00:00
Kornel Lesiński
662bf6ba7b Merge libjpeg-turbo r1390
* commit '73edb3d734a628fd88994bc974dc6737a58bd956': (45 commits)
  Rename the ARM64 assembly file to match the C file
  Fix several mathematical issues discovered in the ARM64 NEON code while running the extended regression tests introduced in r1267.  Specific comments can be found in the original patches: https://sourceforge.net/p/libjpeg-turbo/patches/64/
  Reformat code per Siarhei's original patch (to clearly indicate that the offset instructions are completely independent) and add Siarhei as an individual author (he no longer works for Nokia.)
  Clarify forward compatibility of iOS/ARM builds
  ARM64 NEON SIMD support for YCC-to-RGB565 conversion
  ARM NEON SIMD support for YCC-to-RGB565 conversion, and optimizations to the existing YCC-to-RGB conversion code:
  Ensure that tjFree() is used for any JPEG buffers that might have been dynamically allocated by the compress/transform functions.  To keep things simple, we use tjAlloc() for the statically-allocated buffer as well, so that tjFree() can always be used to free the buffer, regardless of whether it was allocated by tjbench or by the TurboJPEG library.  This fixes crashes that occurred on Windows when running tjunittest or tjbench with the -alloc flag.
  Revert r1335 and r1336.  It was a valiant effort, but on Windows, xmm8-xmm15 are non-volatile, and the overhead of pushing them onto the stack at the beginning of each function and popping them at the end was causing worse performance (in the neighborhood of 3-5%) than just using the work areas and limiting the register usage to xmm0-xmm7.  Best to leave the SSE2 code alone.  We can optimize the register usage for AVX2, once that port takes place.
  Windows doesn't have setenv().  Go, go Gadget Macros.
  1.4 beta1
  Fix 'make dist'
  Don't use sudo when building a Debian package unless the user is non-root
  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.
  .func/.endfunc are only necessary when generating STABS debug info, which basically went out of style with parachute pants and Rick Astley.  At any rate, none of the platforms for which we're building the ARM code use it (DWARF is the common format these days), and the .func/.endfunc directives cause the clang integrated assembler to fail (http://llvm.org/bugs/show_bug.cgi?id=20424).
  Extend tjbenchtest so that it tests the dynamic JPEG buffer allocation feature in TurboJPEG.  Disable the tiling feature in TJBench whenever dynamic buffer allocation is enabled (because the tiling feature requires a separate buffer for each tile, using it successfully with dynamic buffer allocation would require a separate TurboJPEG compressor instance for each tile, and it's not worth going to that trouble right now.)
  Run the TurboJPEG conformance tests out of a directory in /tmp (for improved performance, if the source directory is on a remote file share.)  Fix an issue in TJBench.java that prevented it from working properly if the source image resided in a directory with a dot in the name.
  Oops
  Subtle point, but dest->outbuffer is a pointer to the address of the JPEG buffer, which is stored in the calling program.  Thus, *(dest->outbuffer) will always equal *outbuffer.  We need to compare *outbuffer with dest->buffer instead to determine if the pointer is being reused.
  If the output buffer in the TurboJPEG destination manager was allocated by the destination manager and is being reused from a previous compression operation, then we need to get the buffer size from the previous operation, since the calling program doesn't know the actual buffer size.
  Actually, we need to increase the size of BUFSIZE, not just the size of _buffer.  The previous patch might have cause problems if, for instance, state->free_in_buffer was 127 but 129 bytes were compressed.  In that case, only 127 of the 129 bytes would have been written to the file.  Also document the fix.
  ...

Conflicts:
	CMakeLists.txt
	Makefile.am
	configure.ac
	jcdctmgr.c
	release/deb-control.tmpl
	sharedlib/CMakeLists.txt
	simd/CMakeLists.txt
	turbojpeg.c
2014-09-07 18:21:19 +01:00
Kornel Lesiński
71539b3e13 Merge libjpeg-turbo r1325
* commit 'b8d044a666056d4d8d28d7a5d0805ac32b619b36': (58 commits)
  Big oops.  wrjpgcom on Windows was being built using the rdjpgcom source.
  Prevent a buffer overrun if the comment begins with a literal quote character and the string exceeds 65k characters.  Also prevent comments longer than 65k characters from being written, since this will produce an incorrect JPEG file.
  Remove VMS-specific code
  Our copyright string is longer than JMSG_LENGTH_MAX, and this was causing a buffer overrun if output_message() was called with msg_code set to JMSG_COPYRIGHT, or if format_message() was called with msg_code set to JMSG_COPYRIGHT and with a buffer of length JMSG_LENGTH_MAX.
  We don't support non-ANSI C compilers
  Allow for building the MIPS DSPr2 extensions if the host is mips-* as well as mipsel-*.  The DSPr2 extensions are little endian, so we still have to check that the compiler defines __MIPSEL__ before enabling them.  This paves the way for supporting big-endian MIPS, and in the near term, it allows the SIMD extensions to be built with Sourcery CodeBench.
  SIMD-accelerated int upsample routine for MIPS DSPr2
  Fix MIPS build
  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.
  Remove MS-DOS code and information, and adjust copyright headers to reflect the removal of features in r1307 and r1308.  libjpeg-turbo has never supported MS-DOS, nor is it even possible for us to do so.
  Further copyright header cleanup
  Further copyright header cleanup
  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.
  Remove all of the NEED_SHORT_EXTERNAL_NAMES stuff.  There is scant information available as to which linkers ever had a 15-character global symbol name limit.  AFAICT, it might have been a VMS and/or a.out BSD thing, but none of those platforms have ever been supported by libjpeg-turbo (nor are such systems supported by other open source libraries of this nature.)
  Clean up code formatting in the SIMD interface functions
  SIMD-accelerated NULL convert routine for MIPS DSPr2
  Fix build, which was broken by the checkin of the MIPS DSPr2 accelerated smooth downsampling routine.  Until/unless other platforms include SIMD support for that function, it's just easier to #ifdef around it rather than adding stubs for the other platforms.
  Fix error in MIPS DSPr2 accelerated smooth downsample routine
  SIMD-accelerated h2v2 smooth downsampling routine for MIPS DSPr2
  Minor tweak to improve code readability
  ...

Conflicts:
	BUILDING.txt
	CMakeLists.txt
	Makefile.am
	cdjpeg.h
	cjpeg.1
	cjpeg.c
	configure.ac
	djpeg.1
	example.c
	jccoefct.c
	jcdctmgr.c
	jchuff.c
	jchuff.h
	jcinit.c
	jcmaster.c
	jcparam.c
	jcphuff.c
	jidctflt.c
	jpegint.h
	jpeglib.h
	jversion.h
	libjpeg.txt
	rdswitch.c
	simd/CMakeLists.txt
	tjbench.c
	turbojpeg.c
	usage.txt
	wrjpgcom.c
2014-09-07 16:59:11 +01:00
Kornel Lesiński
f9d1fcdf6f Merge libjpeg-turbo r1220
* commit '93ddfcfc1a814789ed64d967a6118616753bb9d5': (65 commits)
  Use clz/bsr instructions on ARM for bit counting rather than the lookup table (reduces memory footprint and can improve performance in some cases.)
  Make iOS build instructions more generic and applicable to all versions of Xcode;  modify iOS build procedure for Xcode 5.0 and later to fix a build issue with Xcode 5.1.
  Update build instructions to reflect the use of pkgbuild/productbuild
  Remove any claims of support for OS X 10.4 "Tiger" (the packaging system overhaul produces packages that require Leopard or later, and I haven't been able to test Tiger for years anyhow.)  Update TurboJPEG shared library version.
  Migrate Mac packaging system to pkgbuild, since PackageMaker is no longer supported.
  Remove the sections about replacing libjpeg at run time and compile time.  These were written before O/S distributions started shipping libjpeg-turbo, and they are either pedantic or no longer relevant.  Also remove any text that assumes the use of our official project binaries.  Notes specific to the official binaries have been moved into the project wiki.
  Fix Windows build
  Since we're now maintaining our own Cygwin pseudo-repository directories instead of recommending that users install these packages from a local source, it makes more sense to name the packages according to Cygwin specs, so they can be copied as-is into the pseudo-repository.
  39dbc2db9718f9af2f62eb486fd73328fe8bf5e8
  Fix 'make dist'
  RHEL 6 (and probably other platforms as well) sets _defaultdocdir=%{_datadir}/doc, which screws things up, since we're overriding _datadir.  Since we intend _defaultdocdir to be /usr/share/doc, just be explicit about it.
  Fix compiler warning about unused function when building with the libjpeg v6b API/ABI
  Fix compiler warning ("always_inline function might not be inlinable") when building with recent versions of GCC
  Enable silent build (can be overridden with 'make V=1') if the version of autotools being used is new enough.
  Extend YUVImage class to allow reuse of the same buffer with different metadata;  port TJBench changes that treat YUV encoding/decoding as an intermediate step of the JPEG compression/decompression pipeline rather than a separate test case;  add YUV encode/decode tests to the Java version of tjbenchtest
  formatting tweaks
  Fix an error that occurred when trying to use the lossless transform feature without specifying -quiet;  formatting tweak
  Move the garbage collection of the JPEG tiles into the decompression function to increase the chances that tiled decompression of large images will succeed without an OutOfMemoryError.
  Generate the Java documentation using javadoc 7, to improve readability.
  This should have been checked in with the previous commit.
  ...

Conflicts:
	BUILDING.txt
	configure.ac
	jversion.h
	release/Info.plist.in
	release/ReadMe.rtf
	tjbench.c
	turbojpeg.c
2014-09-07 16:50:54 +01:00
DRC
04962caf3a 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://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1376 632fc199-4ca6-4c93-a231-07263d6284db
2014-08-22 13:43:33 +00:00
DRC
004427c071 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
2014-08-22 13:43:33 +00:00
DRC
0713c1bb54 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
2014-08-22 13:43:33 +00:00
DRC
ce6f3d8cd2 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://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1360 632fc199-4ca6-4c93-a231-07263d6284db
2014-08-17 12:23:49 +00:00
DRC
3d037a5c72 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
2014-08-17 12:23:49 +00:00
DRC
40dd3146cd 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
2014-08-17 12:23:49 +00:00
DRC
ab62cf7ba5 Extend the TurboJPEG C API to support handling YUV images stored in separate image planes instead of a unified buffer 2014-08-11 18:05:41 +00:00
DRC
257745ba05 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
2014-08-11 18:05:41 +00:00
DRC
aecea388c7 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
2014-08-11 18:05:41 +00:00
DRC
46611eb0ee 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. 2014-05-18 19:04:03 +00:00