kmx git

Commit	Date	Message
0c23b0ad	2024-08-14T09:21:54	Various doc tweaks - "Optimized baseline entropy coding" = "Huffman table optimization" "Optimized baseline entropy coding" was meant to emphasize that the feature is only useful when generating baseline (single-scan lossy 8-bit-per-sample Huffman-coded) JPEG images, because it is automatically enabled when generating Huffman-coded progressive (multi-scan), 12-bit-per-sample, and lossless JPEG images. However, Huffman table optimization isn't actually an integral part of those non-baseline modes. You can forego Huffman table optimization with 12-bit data precision if you supply your own Huffman tables. The spec doesn't require it with progressive or lossless mode, either, although our implementation does. Furthermore, "baseline" describes more than just the type of entropy coding used. It was incorrect to say that optimized "baseline" entropy coding is automatically enabled for Huffman-coded progressive, 12-bit-per-sample, and lossless JPEG images, since those are clearly not baseline images. - "Progressive entropy coding" = "Progressive JPEG" "Progressive" describes more than just the type of entropy coding used. (In fact, both Huffman-coded and arithmetic-coded images can be progressive.) - Mention that TJPARAM_OPTIMIZE/TJ.PARAM_OPTIMIZE can be used with lossless transformation as well. - General wordsmithing - Formatting tweaks
51d021bf	2024-06-24T12:17:22	TurboJPEG: Fix 12-bit-per-sample arith-coded compr (Regression introduced by 7bb958b732e6b4f261595e2d1527d46964fe3aed) Because of 7bb958b732e6b4f261595e2d1527d46964fe3aed, the TurboJPEG compression and encoding functions no longer transfer the value of TJPARAM_OPTIMIZE into cinfo->data_precision unless the data precision is 8. The intent of that was to prevent using_std_huff_tables() from being called more than once when reusing the same compressor object to generate multiple 12-bit-per-sample JPEG images. However, because cinfo->optimize_coding is always set to TRUE by jpeg_set_defaults() if the data precision is 12, calling applications that use 12-bit data precision had to unset cinfo->optimize_coding if they set cinfo->arith_code after calling jpeg_set_defaults(). Because of 7bb958b732e6b4f261595e2d1527d46964fe3aed, the TurboJPEG API stopped doing that except with 8-bit data precision. Thus, attempting to generate a 12-bit-per-sample arithmetic-coded lossy JPEG image using the TurboJPEG API failed with "Requested features are incompatible." Since the compressor will always fail if cinfo->arith_code and cinfo->optimize_coding are both set, and since cinfo->optimize_coding has no relevance for arithmetic coding, the most robust and user-proof solution is for jinit_c_master_control() to set cinfo->optimize_coding to FALSE if cinfo->arith_code is TRUE. This commit also: - modifies TJBench so that it no longer reports that it is using optimized baseline entropy coding in modes where that setting is irrelevant, - amends the cjpeg documentation to clarify that -optimize is implied when specifying -progressive or '-precision 12' without -arithmetic, and - prevents jpeg_set_defaults() from uselessly checking the value of cinfo->arith_code immediately after it has been set to FALSE.
905ec0fa	2024-03-08T10:29:27	Avoid tautological comparisons Several TurboJPEG functions store their return value in an unsigned long long intermediate and compare it against the maximum value of unsigned long or size_t in order to avoid integer overflow. However, such comparisons are tautological (always true, i.e. redundant) unless the size of unsigned long or size_t is less than the size of unsigned long long. Explicitly guarding the comparisons with #if avoids compiler warnings with -Wtautological-constant-in-range-compare in Clang and also makes it clear to the reader that the comparisons are only intended for 32-bit code. Refer to #752
34c05585	2024-03-06T15:12:31	Fix warnings with -Wmissing-variable-declarations
55d342c7	2023-11-16T15:36:47	TurboJPEG: Expose/extend hidden "max pixels" param TJPARAM_MAXPIXELS was previously hidden and used only for fuzz testing, but it is potentially useful for calling applications as well, particularly if they want to guard against excessive memory consumption by the tj3LoadImage*() functions. The parameter has also been extended to decompression and lossless transformation functions/methods, mainly as a convenience. (It was already possible for calling applications to impose their own JPEG image size limits by reading the JPEG header prior to decompressing or transforming the image.)
df9dbff8	2023-11-11T12:25:03	TurboJPEG: New param to limit virt array mem usage This corresponds to max_memory_to_use in the jpeg_memory_mgr struct in the libjpeg API, except that the TurboJPEG parameter is specified in megabytes. Because this is 2023 and computers with less than 1 MB of memory are not a thing (at least not within the scope of libjpeg-turbo support), it isn't useful to allow a limit less than 1 MB to be specified. Furthermore, because TurboJPEG parameters are signed integers, if we allowed the memory limit to be specified in bytes, then it would be impossible to specify a limit larger than 2 GB on 64-bit machines. Because max_memory_to_use is a long signed integer, effectively we can specify a limit of up to 2 petabytes on 64-bit machines if the TurboJPEG parameter is specified in megabytes. (2 PB should be enough for anybody, right?) This commit also bumps the TurboJPEG API version to 3.0.1. Since the TurboJPEG API version no longer tracks the libjpeg-turbo version, it makes sense to increment the API revision number when adding constants, to increment the minor version number when adding functions, and to increment the major version number for a complete overhaul. This commit also removes the vestigial TJ_NUMPARAM macro, which was never defined because it proved unnecessary. Partially implements #735
c8d52f1c	2023-06-26T11:53:03	tj3Transform: Calc dst buf size from xformed dims When used with TJPARAM_NOREALLOC and with TJXOP_TRANSPOSE, TJXOP_TRANSVERSE, TJXOP_ROT90, or TJXOP_ROT270, tj3Transform() incorrectly based the destination buffer size for a transform on the source image dimensions rather than the transformed image dimensions. This was apparently a long-standing bug that had existed in the tjTransform() function since its inception. As initially implemented in the evolving libjpeg-turbo v1.2 code base, tjTransform() required dstSizes[i] to be set regardless of whether TJFLAG_NOREALLOC (the predecessor to TJPARAM_NOREALLOC) was set. ff78e37595c8462f64fd100f928aa1d08539527e, which was introduced later in the evolving libjpeg-turbo v1.2 code base, removed that requirement and planted the seed for the bug. However, the bug was not activated until 9b49f0e4c77c727648c6d3a4915eefdf5436de4a was introduced still later in the evolving libjpeg-turbo v1.2 code base, adding a subsampling type argument to the (new at the time) tjBufSize() function and thus making the width and height arguments no longer commutative. The bug opened up the possibility that a JPEG source image could cause tj3Transform() to overflow the destination buffer for a transform if all of the following were true: - The JPEG source image used 4:2:2, 4:4:0, 4:1:1, or 4:4:1 subsampling. (These are the only subsampling types for which the width and height arguments to tj3JPEGBufSize() are not commutative.) - The width and height of the JPEG source image were such that tj3JPEGBufSize(height, width, subsamplingType) returned a smaller value than tj3JPEGBufSize(width, height, subsamplingType). - The JPEG source image contained enough metadata that the size of the transformed image was larger than tj3JPEGBufSize(height, width, subsamplingType). - TJPARAM_NOREALLOC was set. - TJXOP_TRANSPOSE, TJXOP_TRANSVERSE, TJXOP_ROT90, or TJXOP_ROT270 was used. - TJXOPT_COPYNONE was not set. - TJXOPT_CROP was not set. - The calling program allocated tj3JPEGBufSize(height, width, subsamplingType) bytes for the destination buffer, as the API documentation instructs. The API documentation cautions that JPEG source images containing a large amount of extraneous metadata (EXIF, IPTC, ICC, etc.) cannot reliably be transformed if TJPARAM_NOREALLOC is set and TJXOPT_COPYNONE is not set. Irrespective of the bug, there are still cases in which a JPEG source image with a large amount of metadata can, when transformed, exceed the worst-case transformed JPEG image size. For instance, if you try to losslessly crop a JPEG image with 3 kB of EXIF data to 16x16 pixels, then you are guaranteed to exceed the worst-case 16x16 JPEG image size unless you discard the EXIF data. Even without the bug, tj3Transform() will still fail with "Buffer passed to JPEG library is too small" when attempting to transform JPEG source images that meet the aforementioned criteria. The bug is that the function segfaults rather than failing gracefully, but the chances of that occurring in a real-world application are very slim. Any real-world application developers who attempted to transform arbitrary JPEG source images with TJPARAM_NOREALLOC set would very quickly realize that they cannot reliably do that without also setting TJXOPT_COPYNONE. Thus, I posit that the actual risk posed by this bug is low. Applications such as web browsers that are the most exposed to security risks from arbitrary JPEG source images do not use the TurboJPEG lossless transform feature. (None of those applications even use the TurboJPEG API, to the best of my knowledge, and the public libjpeg API has no equivalent transform function.) Our only command-line interface to the tj3Transform() function, TJBench, was not exposed to the bug because it had a compatible bug whereby it allocated the JPEG destination buffer to the same size that tj3Transform() erroneously expected. The TurboJPEG Java API was also not exposed to the bug because of a similar compatible bug in the Java_org_libjpegturbo_turbojpeg_TJTransformer_transform() JNI function. (This commit fixes both compatible bugs.) In short, best practices for tj3Transform() are to use TJPARAM_NOREALLOC only with JPEG source images that are known to be free of metadata (such as images generated by tj3Compress()) or to use TJXOPT_COPYNONE along with TJPARAM_NOREALLOC. Still, however, the function shouldn't segfault as long as the calling program allocates the suggested amount of space for the JPEG destination buffer. Usability notes: tj3Transform() could hypothetically require dstSizes[i] to be set regardless of the value of TJPARAM_NOREALLOC, but there are usability pitfalls either way. The main pitfall I sought to avoid with ff78e37595c8462f64fd100f928aa1d08539527e was a calling program failing to set dstSizes[i] at all, thus leaving its value undefined. It could be argued that requiring dstSizes[i] to be set in all cases is more consistent, but it could also be argued that not requiring it to be set when TJPARAM_NOREALLOC is set is more user-proof. tj3Transform() could also hypothetically set TJXOPT_COPYNONE automatically when TJPARAM_NOREALLOC is set, but that could lead to user confusion. Ultimately, I would like to address these issues in TurboJPEG v4 by using managed buffer objects, but that would be an extensive overhaul.
0d20aa15	2023-03-31T10:53:29	TJBench: Require known subsamp type w/tiled decomp (oversight from 386ec0abc7768922b0c51c3dc2e6efaff6278174) Tiled decompression will ultimately fail if the subsampling type of the JPEG input image is unknown, but the C version of TJBench needs to fail earlier in order to avoid using -1 (TJSAMP_UNKNOWN) as an array index for tjMCUWidth[]/tjMCUHeight[]. The Java version now fails earlier as well, although there is no benefit to that other than making the error message less cryptic.
9d2f189c	2023-03-13T16:36:04	TJBench: Change subsamp for transposed 4:*:1 img If we have transformed a 4:1:1 or 4:4:1 JPEG input image in such a way that the horizontal and vertical dimensions are transposed, then we need to change the subsampling type that is passed to the decomp() function. Otherwise, tj3YUVBufSize() may return an incorrect value. (oversight from fc881ebb211b2ba6292d35691a946e1f9c1374b4)
386ec0ab	2023-03-13T13:11:19	TJBench: w/JPEG input imgs, set min tile= MCU size When -tile is used with a JPEG input image, TJBench generates the tiles using lossless cropping, which will fail if the cropping region doesn't align with an MCU boundary. Furthermore, there is no reason to avoid 8x8 tiles when decompressing 4:4:4 or grayscale JPEG images.
fc881ebb	2023-03-09T20:55:43	TurboJPEG: Implement 4:4:1 chrominance subsampling This allows losslessly transposed or rotated 4:1:1 JPEG images to be losslessly cropped, partially decompressed, or decompressed to planar YUV images. Because tj3Transform() allows multiple lossless transformations to be chained together, all subsampling options need to have a corresponding transposed subsampling option. (This is why 4:4:0 was originally implemented as well.) Otherwise, the documentation would be technically incorrect. It says that images with unknown subsampling types cannot be losslessly cropped, partially decompressed, or decompressed to planar YUV images, but it doesn't say anything about images with known subsampling types whose subsampling type becomes unknown if the image is rotated or transposed. This is one of those situations in which it is easier to implement a feature that works around the problem than to document the problem. Closes #659
0205c6e0	2023-01-28T12:09:43	tjbench.c: Remove vestigial int overflow checks Since tj3Alloc() now accepts a size_t argument rather than an int argument, it is no longer necessary to check for signed integer overflow in the C version of TJBench.
427c3045	2023-01-27T14:31:48	tjbench.c: Fix Windows build error (regression introduced by d7790789a6c3f0867175d781948e9d10fc55520d)
d7790789	2023-01-27T12:49:45	tjbench.c: Clean up THROW_TJ*() macro usage - Don't report which function was being called when a TurboJPEG error occurred, because the TurboJPEG error message already contains that information. - Use THROW_TJG() for functions that report errors globally instead of through an instance handle. - Use THROW_TJ() for the image I/O functions. - Formatting tweaks
96bc40c1	2023-01-26T13:11:58	Implement arithmetic coding with 12-bit precision This actually works and apparently always has worked. It only failed because the libjpeg code, which did not originally support arithmetic coding, assumed that optimize_coding should always be TRUE for 12-bit data precision.
fc01f467	2023-01-05T06:36:46	TurboJPEG 3 API overhaul (ChangeLog update forthcoming) - Prefix all function names with "tj3" and remove version suffixes from function names. (Future API overhauls will increment the prefix to "tj4", etc., thus retaining backward API/ABI compatibility without versioning each individual function.) - Replace stateless boolean flags (including TJFLAG_ARITHMETIC and TJFLAG_LOSSLESS, which were never released) with stateful integer parameters, the value of which persists between function calls. * Use parameters for the JPEG quality and subsampling as well, in order to eliminate the awkwardness of specifying function arguments that weren't relevant for lossless compression. * tj3DecompressHeader() now stores all relevant information about the JPEG image, including the width, height, subsampling type, entropy coding type, etc. in parameters rather than returning that information in its arguments. * TJFLAG_LIMITSCANS has been reimplemented as an integer parameter (TJPARAM_SCANLIMIT) that allows the number of scans to be specified. - Use the const keyword for all pointer arguments to unmodified buffers, as well as for both dimensions of 2D pointers. Addresses #395. - Use size_t rather than unsigned long to represent buffer sizes, since unsigned long is a 32-bit type on Windows. Addresses #24. - Return 0 from all buffer size functions if an error occurs, rather than awkwardly trying to return -1 in an unsigned data type. - Implement 12-bit and 16-bit data precision using dedicated compression, decompression, and image I/O functions/methods. * Suffix the names of all data-precision-specific functions with 8, 12, or 16. * Because the YUV functions are intended to be used for video, they are currently only implemented with 8-bit data precision, but they can be expanded to 12-bit data precision in the future, if necessary. * Extend TJUnitTest and TJBench to test 12-bit and 16-bit data precision, using a new -precision option. * Add appropriate regression tests for all of the above to the 'test' target. * Extend tjbenchtest to test 12-bit and 16-bit data precision, and add separate 'tjtest12' and 'tjtest16' targets. * BufferedImage I/O in the Java API is currently limited to 8-bit data precision, since the BufferedImage class does not straightforwardly support higher data precisions. * Extend the PPM reader to convert 12-bit and 16-bit PBMPLUS files to grayscale or CMYK pixels, as it already does for 8-bit files. - Properly accommodate lossless JPEG using dedicated parameters (TJPARAM_LOSSLESS, TJPARAM_LOSSLESSPSV, and TJPARAM_LOSSLESSPT), rather than using a flag and awkwardly repurposing the JPEG quality. Update TJBench to properly reflect whether a JPEG image is lossless. - Re-organize the TJBench usage screen. - Update the Java docs using Java 11, to improve the formatting and eliminate HTML frames. - Use the accurate integer DCT algorithm by default for both compression and decompression, since the "fast" algorithm is a legacy feature, it does not pass the ISO compliance tests, and it is not actually faster on modern x86 CPUs. Remove the -accuratedct option from TJBench and TJExample. - Re-implement the 'tjtest' target using a CMake script that enables the appropriate tests, depending on the data precision and whether or not the Java API is part of the build. - Consolidate the C and Java versions of tjbenchtest into one script. - Consolidate the C and Java versions of tjexampletest into one script. - Combine all initialization functions into a single function (tj3Init()) that accepts an integer parameter specifying the subsystems to initialize. - Enable decompression scaling explicitly, using a new function/method (tj3SetScalingFactor()/TJDecompressor.setScalingFactor()), rather than implicitly using awkward "desired width"/"desired height" parameters. - Introduce a new macro/constant (TJUNSCALED/TJ.UNSCALED) that maps to a scaling factor of 1/1. - Implement partial image decompression, using a new function/method (tj3SetCroppingRegion()/TJDecompressor.setCroppingRegion()) and TJBench option (-crop). Extend tjbenchtest to test the new feature. Addresses #1. - Allow the JPEG colorspace to be specified explicitly when compressing, using a new parameter (TJPARAM_COLORSPACE). This allows JPEG images with the RGB and CMYK colorspaces to be created. - Remove the error/difference image feature from TJBench. Identical images to the ones that TJBench created can be generated using ImageMagick with 'magick composite <original_image> <output_image> -compose difference <diff_image>' - Handle JPEG images with unknown subsampling types. TJPARAM_SUBSAMP is set to TJSAMP_UNKNOWN (== -1) for such images, but they can still be decompressed fully into packed-pixel images or losslessly transformed (with the exception of lossless cropping.) They cannot be partially decompressed or decompressed into planar YUV images. Note also that TJBench, due to its lack of support for imperfect transforms, requires that the subsampling type be known when rotating, flipping, or transversely transposing an image. Addresses #436 - The Java version of TJBench now has identical functionality to the C version. This was accomplished by (somewhat hackishly) calling the TurboJPEG C image I/O functions through JNI and copying the pixels between the C heap and the Java heap. - Add parameters (TJPARAM_RESTARTROWS and TJPARAM_RESTARTBLOCKS) and a TJBench option (-restart) to allow the restart marker interval to be specified when compressing. Eliminate the undocumented TJ_RESTART environment variable. - Add a parameter (TJPARAM_OPTIMIZE), a transform option (TJOPT_OPTIMIZE), and a TJBench option (-optimize) to allow optimized baseline Huffman coding to be specified when compressing. Eliminate the undocumented TJ_OPTIMIZE environment variable. - Add parameters (TJPARAM_XDENSITY, TJPARAM_DENSITY, and TJDENSITYUNITS) to allow the pixel density to be specified when compressing or saving a Windows BMP image and to be queried when decompressing or loading a Windows BMP image. Addresses #77. - Refactor the fuzz targets to use the new API. * Extend decompression coverage to 12-bit and 16-bit data precision. * Replace the awkward cjpeg12 and cjpeg16 targets with proper TurboJPEG-based compress12, compress12-lossless, and compress16-lossless targets - Fix innocuous UBSan warnings uncovered by the new fuzzers. - Implement previous versions of the TurboJPEG API by wrapping the new functions (tested by running the 2.1.x versions of TJBench, via tjbenchtest, and TJUnitTest against the new implementation.) * Remove all JNI functions for deprecated Java methods and implement the deprecated methods using pure Java wrappers. It should be understood that backward API compatibility in Java applies only to the Java classes and that one cannot mix and match a JAR file from one version of libjpeg-turbo with a JNI library from another version. - tj3Destroy() now silently accepts a NULL handle. - tj3Alloc() and tj3Free() now return/accept void pointers, as malloc() and free() do. - The image I/O functions now accept a TurboJPEG instance handle, which is used to transmit/receive parameters and to receive error information. Closes #517
52659f4f	2023-01-23T09:55:13	Merge branch 'main' into dev
af1b4c8d	2023-01-21T18:31:20	TJBench: Unset TJ*OPT_CROP when disabling tiling Otherwise, if the input image is a JPEG image, then an unnecessary lossless transformation will be performed.
7ab6222c	2023-01-20T14:09:25	Merge branch 'main' into dev
98a64558	2023-01-20T13:14:11	TJBench: Set TJ*OPT_PROGRESSIVE with -progressive The documented behavior of the -progressive option is to use progressive entropy coding in JPEG images generated by compression and transform operations. However, setting TJFLAG_PROGRESSIVE was insufficient to accomplish that, because TJBench doesn't enable lossless transformation if xformOpt == 0.
28c2e607	2023-01-18T15:31:04	TJBench: Strictly check all non-boolean arguments + document that the value of -yuvpad must be a power of 2 (refer to d2608583955f060ae7efa950a94d921fdd387d58)
fb15efe9	2023-01-18T06:44:46	TurboJPEG: More documentation improvements - TJBench/TJUnitTest: Wordsmith command-line output - Java: "decompress operations"="decompression operations" - tjLoadImage(): Error message tweak - Don't mention compression performance in the description of TJXOPT_PROGRESSIVE/TJTransform.OPT_PROGRESSIVE, because the image has already been compressed at that point. (Oversights from 9a146f0f23b01869e1bf7c478e12b43f83d59c32)
d4589f4f	2023-01-14T18:07:53	Merge branch 'main' into dev
9a146f0f	2023-01-06T10:29:10	TurboJPEG: Numerous documentation improvements - Wordsmithing, formatting, and grammar tweaks - Various clarifications and corrections, including specifying whether a particular buffer or image is used as a source or destination - Accommodate/mention features that were introduced since the API documentation was created. - For clarity, use "packed-pixel" to describe uncompressed source/destination images that are not planar YUV. - Use "row" rather than "line" to refer to a single horizontal group of pixels or component values, for consistency with the libjpeg API documentation. (libjpeg also uses "scanline", which is a more archaic term.) - Use "alignment" rather than "padding" to refer to the number of bytes by which a row's width is evenly divisible. This consistifies the documention of the YUV functions and tjLoadImage(). ("Padding" typically refers to the number of bytes added to each row, which is not the same thing.) - Remove all references to "the underlying codec." Although the TurboJPEG API originated as a cross-platform wrapper for the Intel Integrated Performance Primitives, Sun mediaLib, QuickTime, and libjpeg, none of those TurboJPEG implementations has been maintained since 2009. Nothing would prevent someone from implementing the TurboJPEG API without libjpeg-turbo, but such an implementation would not necessarily have an "underlying codec." (It could be fully self-contained.) - Use "destination image" rather than "output image", for consistency, or describe the type of image that will be output. - Avoid the term "image buffer" and instead use "byte buffer" to refer to buffers that will hold JPEG images, or describe the type of image that will be contained in the buffer. (The Java documentation doesn't use "byte buffer", because the buffer arrays literally have "byte" in front of them, and since Java doesn't have pointers, it is not possible for mere mortals to store any other type of data in those arrays.) - C: Use "unified" to describe YUV images stored in a single buffer, for consistency with the Java documentation. - Use "planar YUV" rather than "YUV planar". Is is our convention to describe images using {component layout} {colorspace/pixel format} {image function}, e.g. "packed-pixel RGB source image" or "planar YUV destination image." - C: Document the TurboJPEG API version in which a particular function or macro was introduced, and reorder the backward compatibility function stubs in turbojpeg.h alphabetically by API version. - C: Use Markdown rather than HTML tags, where possible, in the Doxygen comments.
b03ee8b8	2023-01-05T11:17:40	TurboJPEG: Don't use backward compatibility macros Macros from older versions of the TurboJPEG API are supported but not documented, so using the current version of those macros makes the code more readable.
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
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.
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
548490fe	2022-02-10T11:37:06	Ensure that strncpy() dest strings are terminated - Since the ERREXITS() and TRACEMSS() macros are never used internally (they are a relic of the legacy memory managers that libjpeg provided), the only risk was that an external program might have invoked one of those macros with a string longer than 79 characters (JMSG_STR_PARM_MAX - 1). - TJBench never invokes the THROW_TJ() macro with a string longer than 199 (JMSG_LENGTH_MAX - 1) characters, so there was no risk. However, it's a good idea to explicitly terminate the destination strings so that anyone looking at the code can immediately tell that it is safe.
14ce28a9	2022-01-29T12:33:40	TJBench: Remove innocuous always-true condition This was accidentally introduced into tjbench.c in 890f1e0413b54c40b663208779d4ea9dae20eaef and ported into the Java version from there. Based on https://github.com/libjpeg-turbo/libjpeg-turbo/pull/571/commits/4be6d4e7bdd09a73ee8456aa07693afa31ef2148 Refer to #571
c81e91e8	2021-04-05T16:08:22	TurboJPEG: New flag for limiting prog JPEG scans This also fixes timeouts reported by OSS-Fuzz.
00607ec2	2020-01-08T14:22:35	Eliminate unnecessary NULL checks before tjFree() + document that tjFree() accepts NULL pointers without complaint. Effectively, it has had that behavior all along, but the API does not guarantee that tjFree() will be implemented with free() behind the scenes, so it's best to formalize the behavior.
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
c30b1e72	2019-11-12T12:27:22	64-bit tjbench: Fix signed int overflow/segfault ... that occurred when attempting to decompress images with more than 715827882 (204810241024 / 3) pixels. Fixes #388
ac59b2c5	2019-11-04T18:49:46	TJBench: Fix output with -componly -quiet
b25adabc	2019-07-12T17:27:37	tjbench.c: Fix minor code formatting errors (introduced by 2a9e3bd7430cfda1bc812d139e0609c6aca0b884)
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
031e16ec	2019-02-11T22:43:15	tjbench.c: Fix GCC 8 compiler warning
1ff90822	2019-01-01T21:08:27	TJBench: Fix FPE when decompressing 0-width JPEG Fixes #319
c701014d	2018-11-12T12:27:23	tjbench.c: Fix compiler warnings with GCC 8 strncpy() may fail to truncate dst if len == strlen(dst).
53bb9418	2018-05-15T14:51:49	Java: Reformat code per checkstyle recommendations ... and modify tjbench.c to match the variable name changes made to TJBench.java ("checkstyle" = http://checkstyle.sourceforge.net, not our regex-based checkstyle script)
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
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.
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.
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
5fce2e94	2017-11-14T15:30:06	tjbench.exe: Fix decompression access violation The program crashed when a JPEG image was passed on the command line, because we were mixing our metaphors vis-a-vis malloc()/free() and tjAlloc()/tjFree() (malloc()/free() uses the tjbench.exe heap, whereas tjAlloc()/tjFree() uses the turbojpeg.dll heap.)
f3ad13e3	2017-11-13T16:00:35	TJBench/TJUnitTest: Don't ignore mistyped args
c9453121	2017-06-29T16:49:09	TJBench: Recover from non-fatal errors if possible Previously, -stoponwarning only had an effect on the underlying TurboJPEG C functions, but TJBench still aborted if a non-fatal error occurred. This commit modifies the C version of TJBench such that it always recovers from a non-fatal error unless -stoponwarning is specified. Furthermore, the benchmark stores the details of the last non-fatal error and does not print any subsequent non-fatal error messages unless they differ from the last one. Due to limitations in the Java API (specifically, the fact that it cannot communicate errors, fatal or otherwise, to the calling program without throwing a TJException), it was only possible to make decompression operations fully recoverable within TJBench. With other operations, -stoponwarning still has an effect on the underlying C library but has no effect at the Java level. The Java API documentation has been amended to reflect that only certain methods are truly recoverable, regardless of the state of TJ.FLAG_STOPONWARNING.
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
dedce66e	2017-06-28T15:30:41	Merge branch 'master' into dev
1db1ce45	2017-06-27T14:22:39	TJBench: Improve consistency of results Given that libjpeg-turbo can often process hundreds of megapixels/second on modern hardware, the default of one warmup iteration was essentially meaningless. Furthermore, the -warmup option was a bit clunky, since it required some foreknowledge of how fast the benchmarks were going to execute. This commit introduces a 1-second warmup interval for each benchmark by default, and the -warmup option has been retasked to control the length of that interval.
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
6a2b0674	2017-05-11T18:33:47	TJBench: Code formatting tweaks Spaces-->tab + remove stray control character that was introduced in 95e4cb206085c3a715f0f017c174fdf367a2c1ff
11eec4a3	2017-06-26T20:48:02	TJBench: Fix errors when decomp. files w/ ICC data Embedded ICC profiles can cause the size of a JPEG file to exceed the size returned by tjBufSize() (which is really meant to be used for compression anyhow, not for decompression), and this was causing a segfault (C) or an ArrayIndexOutOfBoundsException (Java) when decompressing such files with TJBench. This commit modifies the benchmark such that, when tiled decompression is disabled, it re-uses the source buffer as the primary JPEG buffer.
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?
31280613	2016-02-01T11:03:39	TJBench: Fix segfault on Android For whatever reason, the "write" global variable in tjbench.c was overriding the linkage with the write() system function. This may have affected other platforms as well but was not known to.
9c8cee8c	2016-01-13T13:01:45	tjbench: Further tweaks to -nowrite feature * Do not compute compression error if -nowrite is specified * Adjust formatting of -nowrite usage description
eb59b6e7	2016-01-11T22:27:38	Add -nowrite arg to TJBench to improve consistency Prevents any images from being written to disk, thus making the performance of the benchmark as CPU-bound as possible.
cbc9970e	2015-01-16T06:29:52	Add the ability to benchmark YCCK JPEG compression/decompression. This is particularly useful since that is the only way to test the performance of the "plain" upsampling routines, which are accelerated on some platforms. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1511 632fc199-4ca6-4c93-a231-07263d6284db
2ab5ea6c	2015-01-14T19:39:01	Add the ability to benchmark YCCK JPEG compression/decompression. This is particularly useful since that is the only way to test the performance of the "plain" upsampling routines, which are accelerated on some platforms. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1505 632fc199-4ca6-4c93-a231-07263d6284db
eb66974f	2014-08-22T19:59:51	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. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1384 632fc199-4ca6-4c93-a231-07263d6284db
f5644c34	2014-08-22T19:27:28	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. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1383 632fc199-4ca6-4c93-a231-07263d6284db
684ace19	2014-08-22T03:04:06	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.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1374 632fc199-4ca6-4c93-a231-07263d6284db
43513893	2014-08-22T02:57:34	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.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1372 632fc199-4ca6-4c93-a231-07263d6284db
1a45b81f	2014-05-09T18:06:58	Remove trailing spaces (+ one additional tab in TJUnitTest.java that was missed in the previous commit) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1279 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
dd5fcdd0	2014-03-17T10:40:10	formatting tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1183 632fc199-4ca6-4c93-a231-07263d6284db
78b227e2	2014-03-14T04:15:43	Oops. This code should not have been removed. It is necessary for generating the error images. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1165 632fc199-4ca6-4c93-a231-07263d6284db
ce6891f0	2014-03-13T20:33:43	If we have transformed a 4:2:2 or 4:4:0 image in any way that transposes the horizontal and vertical dimensions, then we need to inform the decompression function that the subsampling type has changed. Otherwise, tjDecodeYUV() will not produce correct results. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1162 632fc199-4ca6-4c93-a231-07263d6284db
adf5551b	2014-03-12T07:17:23	Execute warmup runs with tjTransform() as well git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1159 632fc199-4ca6-4c93-a231-07263d6284db
e1efc8a0	2014-03-12T07:16:17	Fix a couple of output formatting issues git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1158 632fc199-4ca6-4c93-a231-07263d6284db
95e4cb20	2014-03-12T06:51:39	Since we now have a complete set of YUV functions, TJBench can be greatly simplified. It now tests YUV encoding/decoding as an intermediate step of JPEG compression/decompression, which eliminates the need for a separate YUV mode. Several other things have been streamlined in the process. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1157 632fc199-4ca6-4c93-a231-07263d6284db
0e9bf644	2014-03-12T06:17:12	Fix a segfault that would occur in decompress-only mode if -alloc was specified without -tile. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1156 632fc199-4ca6-4c93-a231-07263d6284db
dd59233d	2014-03-12T06:15:51	Fix a segfault that would occur in decompress-only mode if -alloc was specified without -tile. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1155 632fc199-4ca6-4c93-a231-07263d6284db
a15f19f2	2014-03-11T09:46:50	Wordsmithing & formatting tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1154 632fc199-4ca6-4c93-a231-07263d6284db
d4b453c2	2014-03-11T08:28:47	Back-port the -subsamp option from 1.4 rather than use the hackish approach of replacing 4:2:2 with 4:4:0. This has the added advantage of allowing the user to test only a specific level of subsampling. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1153 632fc199-4ca6-4c93-a231-07263d6284db
c6501f7f	2013-11-04T23:07:54	Add the ability to test scaling when decompressing to YUV; compression from YUV to JPEG; and YUV padding. Replace clunky -411 and -440 parameters with a -subsamp parameter that allows any of the subsampling options to be tested in isolation. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1074 632fc199-4ca6-4c93-a231-07263d6284db
07e982d9	2013-10-31T07:11:39	Deprecate and undocument the FORCE{MMX\|SSE\|SSE2\|SSE3} flags. These were originally introduced in TurboJPEG/IPP as a way to override the automatic CPU selection in the underlying IPP codec, which was closed source. They are not meaningful anymore, since libjpeg-turbo provides environment variables to accomplish the same thing and since it no longer necessarily uses x86 SIMD code behind the scenes. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1072 632fc199-4ca6-4c93-a231-07263d6284db
c45653e4	2013-10-12T21:52:48	Fix a couple of issues with return value checking. JFREAD(), which wraps fread(), will never return -1. fread() will instead return 0 or a short object count if an error occurs, and ferror() will return 1 in that case. The second issue was that we were assigning the return value of ftell() to an unsigned long prior to checking the value, so the value would never be < 0 if an error occurred. It would instead be (unsigned long)-1. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1061 632fc199-4ca6-4c93-a231-07263d6284db
490c7f95	2013-10-12T21:51:16	Fix a couple of issues with return value checking. JFREAD(), which wraps fread(), will never return -1. fread() will instead return 0 or a short object count if an error occurs, and ferror() will return 1 in that case. The second issue was that we were assigning the return value of ftell() to an unsigned long prior to checking the value, so the value would never be < 0 if an error occurred. It would instead be (unsigned long)-1. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1060 632fc199-4ca6-4c93-a231-07263d6284db
38cb1ec2	2013-08-23T04:45:43	Add CMYK support to the TurboJPEG Java API & clean up a few things in the C API git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1020 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
d081fd72	2013-08-18T09:15:37	Add note regarding the fact that 4:4:0 lacks full SIMD support; Add an option for benchmarking 4:4:0 subsampling in tjbench. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1009 632fc199-4ca6-4c93-a231-07263d6284db
07796da4	2013-08-18T09:13:00	Add note regarding the fact that 4:4:0 lacks full SIMD support; Add an option for benchmarking 4:4:0 subsampling in tjbench. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1008 632fc199-4ca6-4c93-a231-07263d6284db
cc336e7b	2012-06-29T23:51:35	Cosmetic fixes to argument lists git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@852 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
cac10513	2012-03-16T14:37:36	Fix the behavior of the alpha-enabled colorspace constants whenever libjpeg-turbo is built without SIMD support and merged upsampling is used. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@811 632fc199-4ca6-4c93-a231-07263d6284db
ffe4fc18	2012-03-16T14:30:46	Fix the behavior of the alpha-enabled colorspace constants whenever libjpeg-turbo is built without SIMD support and merged upsampling is used. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@810 632fc199-4ca6-4c93-a231-07263d6284db
ab2df6ea	2012-01-28T06:49:56	Expose new scaling factors in TurboJPEG API git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@757 632fc199-4ca6-4c93-a231-07263d6284db
e006f5c4	2012-01-28T06:31:44	Oops. Height of output buffer should equal scaled height, not JPEG height. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@755 632fc199-4ca6-4c93-a231-07263d6284db

0c23b0ad

2024-08-14T09:21:54

Various doc tweaks - "Optimized baseline entropy coding" = "Huffman table optimization" "Optimized baseline entropy coding" was meant to emphasize that the feature is only useful when generating baseline (single-scan lossy 8-bit-per-sample Huffman-coded) JPEG images, because it is automatically enabled when generating Huffman-coded progressive (multi-scan), 12-bit-per-sample, and lossless JPEG images. However, Huffman table optimization isn't actually an integral part of those non-baseline modes. You can forego Huffman table optimization with 12-bit data precision if you supply your own Huffman tables. The spec doesn't require it with progressive or lossless mode, either, although our implementation does. Furthermore, "baseline" describes more than just the type of entropy coding used. It was incorrect to say that optimized "baseline" entropy coding is automatically enabled for Huffman-coded progressive, 12-bit-per-sample, and lossless JPEG images, since those are clearly not baseline images. - "Progressive entropy coding" = "Progressive JPEG" "Progressive" describes more than just the type of entropy coding used. (In fact, both Huffman-coded and arithmetic-coded images can be progressive.) - Mention that TJPARAM_OPTIMIZE/TJ.PARAM_OPTIMIZE can be used with lossless transformation as well. - General wordsmithing - Formatting tweaks

51d021bf

2024-06-24T12:17:22

TurboJPEG: Fix 12-bit-per-sample arith-coded compr (Regression introduced by 7bb958b732e6b4f261595e2d1527d46964fe3aed) Because of 7bb958b732e6b4f261595e2d1527d46964fe3aed, the TurboJPEG compression and encoding functions no longer transfer the value of TJPARAM_OPTIMIZE into cinfo->data_precision unless the data precision is 8. The intent of that was to prevent using_std_huff_tables() from being called more than once when reusing the same compressor object to generate multiple 12-bit-per-sample JPEG images. However, because cinfo->optimize_coding is always set to TRUE by jpeg_set_defaults() if the data precision is 12, calling applications that use 12-bit data precision had to unset cinfo->optimize_coding if they set cinfo->arith_code after calling jpeg_set_defaults(). Because of 7bb958b732e6b4f261595e2d1527d46964fe3aed, the TurboJPEG API stopped doing that except with 8-bit data precision. Thus, attempting to generate a 12-bit-per-sample arithmetic-coded lossy JPEG image using the TurboJPEG API failed with "Requested features are incompatible." Since the compressor will always fail if cinfo->arith_code and cinfo->optimize_coding are both set, and since cinfo->optimize_coding has no relevance for arithmetic coding, the most robust and user-proof solution is for jinit_c_master_control() to set cinfo->optimize_coding to FALSE if cinfo->arith_code is TRUE. This commit also: - modifies TJBench so that it no longer reports that it is using optimized baseline entropy coding in modes where that setting is irrelevant, - amends the cjpeg documentation to clarify that -optimize is implied when specifying -progressive or '-precision 12' without -arithmetic, and - prevents jpeg_set_defaults() from uselessly checking the value of cinfo->arith_code immediately after it has been set to FALSE.

905ec0fa

2024-03-08T10:29:27

Avoid tautological comparisons Several TurboJPEG functions store their return value in an unsigned long long intermediate and compare it against the maximum value of unsigned long or size_t in order to avoid integer overflow. However, such comparisons are tautological (always true, i.e. redundant) unless the size of unsigned long or size_t is less than the size of unsigned long long. Explicitly guarding the comparisons with #if avoids compiler warnings with -Wtautological-constant-in-range-compare in Clang and also makes it clear to the reader that the comparisons are only intended for 32-bit code. Refer to #752

34c05585

2024-03-06T15:12:31

Fix warnings with -Wmissing-variable-declarations

55d342c7

2023-11-16T15:36:47

TurboJPEG: Expose/extend hidden "max pixels" param TJPARAM_MAXPIXELS was previously hidden and used only for fuzz testing, but it is potentially useful for calling applications as well, particularly if they want to guard against excessive memory consumption by the tj3LoadImage*() functions. The parameter has also been extended to decompression and lossless transformation functions/methods, mainly as a convenience. (It was already possible for calling applications to impose their own JPEG image size limits by reading the JPEG header prior to decompressing or transforming the image.)

df9dbff8

2023-11-11T12:25:03

TurboJPEG: New param to limit virt array mem usage This corresponds to max_memory_to_use in the jpeg_memory_mgr struct in the libjpeg API, except that the TurboJPEG parameter is specified in megabytes. Because this is 2023 and computers with less than 1 MB of memory are not a thing (at least not within the scope of libjpeg-turbo support), it isn't useful to allow a limit less than 1 MB to be specified. Furthermore, because TurboJPEG parameters are signed integers, if we allowed the memory limit to be specified in bytes, then it would be impossible to specify a limit larger than 2 GB on 64-bit machines. Because max_memory_to_use is a long signed integer, effectively we can specify a limit of up to 2 petabytes on 64-bit machines if the TurboJPEG parameter is specified in megabytes. (2 PB should be enough for anybody, right?) This commit also bumps the TurboJPEG API version to 3.0.1. Since the TurboJPEG API version no longer tracks the libjpeg-turbo version, it makes sense to increment the API revision number when adding constants, to increment the minor version number when adding functions, and to increment the major version number for a complete overhaul. This commit also removes the vestigial TJ_NUMPARAM macro, which was never defined because it proved unnecessary. Partially implements #735

c8d52f1c

2023-06-26T11:53:03

tj3Transform: Calc dst buf size from xformed dims When used with TJPARAM_NOREALLOC and with TJXOP_TRANSPOSE, TJXOP_TRANSVERSE, TJXOP_ROT90, or TJXOP_ROT270, tj3Transform() incorrectly based the destination buffer size for a transform on the source image dimensions rather than the transformed image dimensions. This was apparently a long-standing bug that had existed in the tj*Transform() function since its inception. As initially implemented in the evolving libjpeg-turbo v1.2 code base, tjTransform() required dstSizes[i] to be set regardless of whether TJFLAG_NOREALLOC (the predecessor to TJPARAM_NOREALLOC) was set. ff78e37595c8462f64fd100f928aa1d08539527e, which was introduced later in the evolving libjpeg-turbo v1.2 code base, removed that requirement and planted the seed for the bug. However, the bug was not activated until 9b49f0e4c77c727648c6d3a4915eefdf5436de4a was introduced still later in the evolving libjpeg-turbo v1.2 code base, adding a subsampling type argument to the (new at the time) tjBufSize() function and thus making the width and height arguments no longer commutative. The bug opened up the possibility that a JPEG source image could cause tj3Transform() to overflow the destination buffer for a transform if all of the following were true: - The JPEG source image used 4:2:2, 4:4:0, 4:1:1, or 4:4:1 subsampling. (These are the only subsampling types for which the width and height arguments to tj3JPEGBufSize() are not commutative.) - The width and height of the JPEG source image were such that tj3JPEGBufSize(height, width, subsamplingType) returned a smaller value than tj3JPEGBufSize(width, height, subsamplingType). - The JPEG source image contained enough metadata that the size of the transformed image was larger than tj3JPEGBufSize(height, width, subsamplingType). - TJPARAM_NOREALLOC was set. - TJXOP_TRANSPOSE, TJXOP_TRANSVERSE, TJXOP_ROT90, or TJXOP_ROT270 was used. - TJXOPT_COPYNONE was not set. - TJXOPT_CROP was not set. - The calling program allocated tj3JPEGBufSize(height, width, subsamplingType) bytes for the destination buffer, as the API documentation instructs. The API documentation cautions that JPEG source images containing a large amount of extraneous metadata (EXIF, IPTC, ICC, etc.) cannot reliably be transformed if TJPARAM_NOREALLOC is set and TJXOPT_COPYNONE is not set. Irrespective of the bug, there are still cases in which a JPEG source image with a large amount of metadata can, when transformed, exceed the worst-case transformed JPEG image size. For instance, if you try to losslessly crop a JPEG image with 3 kB of EXIF data to 16x16 pixels, then you are guaranteed to exceed the worst-case 16x16 JPEG image size unless you discard the EXIF data. Even without the bug, tj3Transform() will still fail with "Buffer passed to JPEG library is too small" when attempting to transform JPEG source images that meet the aforementioned criteria. The bug is that the function segfaults rather than failing gracefully, but the chances of that occurring in a real-world application are very slim. Any real-world application developers who attempted to transform arbitrary JPEG source images with TJPARAM_NOREALLOC set would very quickly realize that they cannot reliably do that without also setting TJXOPT_COPYNONE. Thus, I posit that the actual risk posed by this bug is low. Applications such as web browsers that are the most exposed to security risks from arbitrary JPEG source images do not use the TurboJPEG lossless transform feature. (None of those applications even use the TurboJPEG API, to the best of my knowledge, and the public libjpeg API has no equivalent transform function.) Our only command-line interface to the tj3Transform() function, TJBench, was not exposed to the bug because it had a compatible bug whereby it allocated the JPEG destination buffer to the same size that tj3Transform() erroneously expected. The TurboJPEG Java API was also not exposed to the bug because of a similar compatible bug in the Java_org_libjpegturbo_turbojpeg_TJTransformer_transform() JNI function. (This commit fixes both compatible bugs.) In short, best practices for tj3Transform() are to use TJPARAM_NOREALLOC only with JPEG source images that are known to be free of metadata (such as images generated by tj3Compress*()) or to use TJXOPT_COPYNONE along with TJPARAM_NOREALLOC. Still, however, the function shouldn't segfault as long as the calling program allocates the suggested amount of space for the JPEG destination buffer. Usability notes: tj3Transform() could hypothetically require dstSizes[i] to be set regardless of the value of TJPARAM_NOREALLOC, but there are usability pitfalls either way. The main pitfall I sought to avoid with ff78e37595c8462f64fd100f928aa1d08539527e was a calling program failing to set dstSizes[i] at all, thus leaving its value undefined. It could be argued that requiring dstSizes[i] to be set in all cases is more consistent, but it could also be argued that not requiring it to be set when TJPARAM_NOREALLOC is set is more user-proof. tj3Transform() could also hypothetically set TJXOPT_COPYNONE automatically when TJPARAM_NOREALLOC is set, but that could lead to user confusion. Ultimately, I would like to address these issues in TurboJPEG v4 by using managed buffer objects, but that would be an extensive overhaul.

0d20aa15

2023-03-31T10:53:29

TJBench: Require known subsamp type w/tiled decomp (oversight from 386ec0abc7768922b0c51c3dc2e6efaff6278174) Tiled decompression will ultimately fail if the subsampling type of the JPEG input image is unknown, but the C version of TJBench needs to fail earlier in order to avoid using -1 (TJSAMP_UNKNOWN) as an array index for tjMCUWidth[]/tjMCUHeight[]. The Java version now fails earlier as well, although there is no benefit to that other than making the error message less cryptic.

9d2f189c

2023-03-13T16:36:04

TJBench: Change subsamp for transposed 4:*:1 img If we have transformed a 4:1:1 or 4:4:1 JPEG input image in such a way that the horizontal and vertical dimensions are transposed, then we need to change the subsampling type that is passed to the decomp() function. Otherwise, tj3YUVBufSize() may return an incorrect value. (oversight from fc881ebb211b2ba6292d35691a946e1f9c1374b4)

386ec0ab

2023-03-13T13:11:19

TJBench: w/JPEG input imgs, set min tile= MCU size When -tile is used with a JPEG input image, TJBench generates the tiles using lossless cropping, which will fail if the cropping region doesn't align with an MCU boundary. Furthermore, there is no reason to avoid 8x8 tiles when decompressing 4:4:4 or grayscale JPEG images.

fc881ebb

2023-03-09T20:55:43

TurboJPEG: Implement 4:4:1 chrominance subsampling This allows losslessly transposed or rotated 4:1:1 JPEG images to be losslessly cropped, partially decompressed, or decompressed to planar YUV images. Because tj3Transform() allows multiple lossless transformations to be chained together, all subsampling options need to have a corresponding transposed subsampling option. (This is why 4:4:0 was originally implemented as well.) Otherwise, the documentation would be technically incorrect. It says that images with unknown subsampling types cannot be losslessly cropped, partially decompressed, or decompressed to planar YUV images, but it doesn't say anything about images with known subsampling types whose subsampling type becomes unknown if the image is rotated or transposed. This is one of those situations in which it is easier to implement a feature that works around the problem than to document the problem. Closes #659

0205c6e0

2023-01-28T12:09:43

tjbench.c: Remove vestigial int overflow checks Since tj3Alloc() now accepts a size_t argument rather than an int argument, it is no longer necessary to check for signed integer overflow in the C version of TJBench.

427c3045

2023-01-27T14:31:48

tjbench.c: Fix Windows build error (regression introduced by d7790789a6c3f0867175d781948e9d10fc55520d)

d7790789

2023-01-27T12:49:45

tjbench.c: Clean up THROW_TJ*() macro usage - Don't report which function was being called when a TurboJPEG error occurred, because the TurboJPEG error message already contains that information. - Use THROW_TJG() for functions that report errors globally instead of through an instance handle. - Use THROW_TJ() for the image I/O functions. - Formatting tweaks

96bc40c1

2023-01-26T13:11:58

Implement arithmetic coding with 12-bit precision This actually works and apparently always has worked. It only failed because the libjpeg code, which did not originally support arithmetic coding, assumed that optimize_coding should always be TRUE for 12-bit data precision.

fc01f467

2023-01-05T06:36:46

TurboJPEG 3 API overhaul (ChangeLog update forthcoming) - Prefix all function names with "tj3" and remove version suffixes from function names. (Future API overhauls will increment the prefix to "tj4", etc., thus retaining backward API/ABI compatibility without versioning each individual function.) - Replace stateless boolean flags (including TJ*FLAG_ARITHMETIC and TJ*FLAG_LOSSLESS, which were never released) with stateful integer parameters, the value of which persists between function calls. * Use parameters for the JPEG quality and subsampling as well, in order to eliminate the awkwardness of specifying function arguments that weren't relevant for lossless compression. * tj3DecompressHeader() now stores all relevant information about the JPEG image, including the width, height, subsampling type, entropy coding type, etc. in parameters rather than returning that information in its arguments. * TJ*FLAG_LIMITSCANS has been reimplemented as an integer parameter (TJ*PARAM_SCANLIMIT) that allows the number of scans to be specified. - Use the const keyword for all pointer arguments to unmodified buffers, as well as for both dimensions of 2D pointers. Addresses #395. - Use size_t rather than unsigned long to represent buffer sizes, since unsigned long is a 32-bit type on Windows. Addresses #24. - Return 0 from all buffer size functions if an error occurs, rather than awkwardly trying to return -1 in an unsigned data type. - Implement 12-bit and 16-bit data precision using dedicated compression, decompression, and image I/O functions/methods. * Suffix the names of all data-precision-specific functions with 8, 12, or 16. * Because the YUV functions are intended to be used for video, they are currently only implemented with 8-bit data precision, but they can be expanded to 12-bit data precision in the future, if necessary. * Extend TJUnitTest and TJBench to test 12-bit and 16-bit data precision, using a new -precision option. * Add appropriate regression tests for all of the above to the 'test' target. * Extend tjbenchtest to test 12-bit and 16-bit data precision, and add separate 'tjtest12' and 'tjtest16' targets. * BufferedImage I/O in the Java API is currently limited to 8-bit data precision, since the BufferedImage class does not straightforwardly support higher data precisions. * Extend the PPM reader to convert 12-bit and 16-bit PBMPLUS files to grayscale or CMYK pixels, as it already does for 8-bit files. - Properly accommodate lossless JPEG using dedicated parameters (TJ*PARAM_LOSSLESS, TJ*PARAM_LOSSLESSPSV, and TJ*PARAM_LOSSLESSPT), rather than using a flag and awkwardly repurposing the JPEG quality. Update TJBench to properly reflect whether a JPEG image is lossless. - Re-organize the TJBench usage screen. - Update the Java docs using Java 11, to improve the formatting and eliminate HTML frames. - Use the accurate integer DCT algorithm by default for both compression and decompression, since the "fast" algorithm is a legacy feature, it does not pass the ISO compliance tests, and it is not actually faster on modern x86 CPUs. * Remove the -accuratedct option from TJBench and TJExample. - Re-implement the 'tjtest' target using a CMake script that enables the appropriate tests, depending on the data precision and whether or not the Java API is part of the build. - Consolidate the C and Java versions of tjbenchtest into one script. - Consolidate the C and Java versions of tjexampletest into one script. - Combine all initialization functions into a single function (tj3Init()) that accepts an integer parameter specifying the subsystems to initialize. - Enable decompression scaling explicitly, using a new function/method (tj3SetScalingFactor()/TJDecompressor.setScalingFactor()), rather than implicitly using awkward "desired width"/"desired height" parameters. - Introduce a new macro/constant (TJUNSCALED/TJ.UNSCALED) that maps to a scaling factor of 1/1. - Implement partial image decompression, using a new function/method (tj3SetCroppingRegion()/TJDecompressor.setCroppingRegion()) and TJBench option (-crop). Extend tjbenchtest to test the new feature. Addresses #1. - Allow the JPEG colorspace to be specified explicitly when compressing, using a new parameter (TJ*PARAM_COLORSPACE). This allows JPEG images with the RGB and CMYK colorspaces to be created. - Remove the error/difference image feature from TJBench. Identical images to the ones that TJBench created can be generated using ImageMagick with 'magick composite <original_image> <output_image> -compose difference <diff_image>' - Handle JPEG images with unknown subsampling types. TJ*PARAM_SUBSAMP is set to TJ*SAMP_UNKNOWN (== -1) for such images, but they can still be decompressed fully into packed-pixel images or losslessly transformed (with the exception of lossless cropping.) They cannot be partially decompressed or decompressed into planar YUV images. Note also that TJBench, due to its lack of support for imperfect transforms, requires that the subsampling type be known when rotating, flipping, or transversely transposing an image. Addresses #436 - The Java version of TJBench now has identical functionality to the C version. This was accomplished by (somewhat hackishly) calling the TurboJPEG C image I/O functions through JNI and copying the pixels between the C heap and the Java heap. - Add parameters (TJ*PARAM_RESTARTROWS and TJ*PARAM_RESTARTBLOCKS) and a TJBench option (-restart) to allow the restart marker interval to be specified when compressing. Eliminate the undocumented TJ_RESTART environment variable. - Add a parameter (TJ*PARAM_OPTIMIZE), a transform option (TJ*OPT_OPTIMIZE), and a TJBench option (-optimize) to allow optimized baseline Huffman coding to be specified when compressing. Eliminate the undocumented TJ_OPTIMIZE environment variable. - Add parameters (TJ*PARAM_XDENSITY, TJ*PARAM_DENSITY, and TJ*DENSITYUNITS) to allow the pixel density to be specified when compressing or saving a Windows BMP image and to be queried when decompressing or loading a Windows BMP image. Addresses #77. - Refactor the fuzz targets to use the new API. * Extend decompression coverage to 12-bit and 16-bit data precision. * Replace the awkward cjpeg12 and cjpeg16 targets with proper TurboJPEG-based compress12, compress12-lossless, and compress16-lossless targets - Fix innocuous UBSan warnings uncovered by the new fuzzers. - Implement previous versions of the TurboJPEG API by wrapping the new functions (tested by running the 2.1.x versions of TJBench, via tjbenchtest, and TJUnitTest against the new implementation.) * Remove all JNI functions for deprecated Java methods and implement the deprecated methods using pure Java wrappers. It should be understood that backward API compatibility in Java applies only to the Java classes and that one cannot mix and match a JAR file from one version of libjpeg-turbo with a JNI library from another version. - tj3Destroy() now silently accepts a NULL handle. - tj3Alloc() and tj3Free() now return/accept void pointers, as malloc() and free() do. - The image I/O functions now accept a TurboJPEG instance handle, which is used to transmit/receive parameters and to receive error information. Closes #517

52659f4f

2023-01-23T09:55:13

Merge branch 'main' into dev

af1b4c8d

2023-01-21T18:31:20

TJBench: Unset TJ*OPT_CROP when disabling tiling Otherwise, if the input image is a JPEG image, then an unnecessary lossless transformation will be performed.

7ab6222c

2023-01-20T14:09:25

Merge branch 'main' into dev

98a64558

2023-01-20T13:14:11

TJBench: Set TJ*OPT_PROGRESSIVE with -progressive The documented behavior of the -progressive option is to use progressive entropy coding in JPEG images generated by compression and transform operations. However, setting TJFLAG_PROGRESSIVE was insufficient to accomplish that, because TJBench doesn't enable lossless transformation if xformOpt == 0.

28c2e607

2023-01-18T15:31:04

TJBench: Strictly check all non-boolean arguments + document that the value of -yuvpad must be a power of 2 (refer to d2608583955f060ae7efa950a94d921fdd387d58)

fb15efe9

2023-01-18T06:44:46

TurboJPEG: More documentation improvements - TJBench/TJUnitTest: Wordsmith command-line output - Java: "decompress operations"="decompression operations" - tjLoadImage(): Error message tweak - Don't mention compression performance in the description of TJXOPT_PROGRESSIVE/TJTransform.OPT_PROGRESSIVE, because the image has already been compressed at that point. (Oversights from 9a146f0f23b01869e1bf7c478e12b43f83d59c32)

d4589f4f

2023-01-14T18:07:53

Merge branch 'main' into dev

9a146f0f

2023-01-06T10:29:10

TurboJPEG: Numerous documentation improvements - Wordsmithing, formatting, and grammar tweaks - Various clarifications and corrections, including specifying whether a particular buffer or image is used as a source or destination - Accommodate/mention features that were introduced since the API documentation was created. - For clarity, use "packed-pixel" to describe uncompressed source/destination images that are not planar YUV. - Use "row" rather than "line" to refer to a single horizontal group of pixels or component values, for consistency with the libjpeg API documentation. (libjpeg also uses "scanline", which is a more archaic term.) - Use "alignment" rather than "padding" to refer to the number of bytes by which a row's width is evenly divisible. This consistifies the documention of the YUV functions and tjLoadImage(). ("Padding" typically refers to the number of bytes added to each row, which is not the same thing.) - Remove all references to "the underlying codec." Although the TurboJPEG API originated as a cross-platform wrapper for the Intel Integrated Performance Primitives, Sun mediaLib, QuickTime, and libjpeg, none of those TurboJPEG implementations has been maintained since 2009. Nothing would prevent someone from implementing the TurboJPEG API without libjpeg-turbo, but such an implementation would not necessarily have an "underlying codec." (It could be fully self-contained.) - Use "destination image" rather than "output image", for consistency, or describe the type of image that will be output. - Avoid the term "image buffer" and instead use "byte buffer" to refer to buffers that will hold JPEG images, or describe the type of image that will be contained in the buffer. (The Java documentation doesn't use "byte buffer", because the buffer arrays literally have "byte" in front of them, and since Java doesn't have pointers, it is not possible for mere mortals to store any other type of data in those arrays.) - C: Use "unified" to describe YUV images stored in a single buffer, for consistency with the Java documentation. - Use "planar YUV" rather than "YUV planar". Is is our convention to describe images using {component layout} {colorspace/pixel format} {image function}, e.g. "packed-pixel RGB source image" or "planar YUV destination image." - C: Document the TurboJPEG API version in which a particular function or macro was introduced, and reorder the backward compatibility function stubs in turbojpeg.h alphabetically by API version. - C: Use Markdown rather than HTML tags, where possible, in the Doxygen comments.

b03ee8b8

2023-01-05T11:17:40

TurboJPEG: Don't use backward compatibility macros Macros from older versions of the TurboJPEG API are supported but not documented, so using the current version of those macros makes the code more readable.

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

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.

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

548490fe

2022-02-10T11:37:06

Ensure that strncpy() dest strings are terminated - Since the ERREXITS() and TRACEMSS() macros are never used internally (they are a relic of the legacy memory managers that libjpeg provided), the only risk was that an external program might have invoked one of those macros with a string longer than 79 characters (JMSG_STR_PARM_MAX - 1). - TJBench never invokes the THROW_TJ() macro with a string longer than 199 (JMSG_LENGTH_MAX - 1) characters, so there was no risk. However, it's a good idea to explicitly terminate the destination strings so that anyone looking at the code can immediately tell that it is safe.

14ce28a9

2022-01-29T12:33:40

TJBench: Remove innocuous always-true condition This was accidentally introduced into tjbench.c in 890f1e0413b54c40b663208779d4ea9dae20eaef and ported into the Java version from there. Based on https://github.com/libjpeg-turbo/libjpeg-turbo/pull/571/commits/4be6d4e7bdd09a73ee8456aa07693afa31ef2148 Refer to #571

c81e91e8

2021-04-05T16:08:22

TurboJPEG: New flag for limiting prog JPEG scans This also fixes timeouts reported by OSS-Fuzz.

00607ec2

2020-01-08T14:22:35

Eliminate unnecessary NULL checks before tjFree() + document that tjFree() accepts NULL pointers without complaint. Effectively, it has had that behavior all along, but the API does not guarantee that tjFree() will be implemented with free() behind the scenes, so it's best to formalize the behavior.

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

c30b1e72

2019-11-12T12:27:22

64-bit tjbench: Fix signed int overflow/segfault ... that occurred when attempting to decompress images with more than 715827882 (2048*1024*1024 / 3) pixels. Fixes #388

ac59b2c5

2019-11-04T18:49:46

TJBench: Fix output with -componly -quiet

b25adabc

2019-07-12T17:27:37

tjbench.c: Fix minor code formatting errors (introduced by 2a9e3bd7430cfda1bc812d139e0609c6aca0b884)

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

031e16ec

2019-02-11T22:43:15

tjbench.c: Fix GCC 8 compiler warning

1ff90822

2019-01-01T21:08:27

TJBench: Fix FPE when decompressing 0-width JPEG Fixes #319

c701014d

2018-11-12T12:27:23

tjbench.c: Fix compiler warnings with GCC 8 strncpy() may fail to truncate dst if len == strlen(dst).

53bb9418

2018-05-15T14:51:49

Java: Reformat code per checkstyle recommendations ... and modify tjbench.c to match the variable name changes made to TJBench.java ("checkstyle" = http://checkstyle.sourceforge.net, not our regex-based checkstyle script)

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

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.

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.

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

5fce2e94

2017-11-14T15:30:06

tjbench.exe: Fix decompression access violation The program crashed when a JPEG image was passed on the command line, because we were mixing our metaphors vis-a-vis malloc()/free() and tjAlloc()/tjFree() (malloc()/free() uses the tjbench.exe heap, whereas tjAlloc()/tjFree() uses the turbojpeg.dll heap.)

f3ad13e3

2017-11-13T16:00:35

TJBench/TJUnitTest: Don't ignore mistyped args

c9453121

2017-06-29T16:49:09

TJBench: Recover from non-fatal errors if possible Previously, -stoponwarning only had an effect on the underlying TurboJPEG C functions, but TJBench still aborted if a non-fatal error occurred. This commit modifies the C version of TJBench such that it always recovers from a non-fatal error unless -stoponwarning is specified. Furthermore, the benchmark stores the details of the last non-fatal error and does not print any subsequent non-fatal error messages unless they differ from the last one. Due to limitations in the Java API (specifically, the fact that it cannot communicate errors, fatal or otherwise, to the calling program without throwing a TJException), it was only possible to make decompression operations fully recoverable within TJBench. With other operations, -stoponwarning still has an effect on the underlying C library but has no effect at the Java level. The Java API documentation has been amended to reflect that only certain methods are truly recoverable, regardless of the state of TJ.FLAG_STOPONWARNING.

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

dedce66e

2017-06-28T15:30:41

Merge branch 'master' into dev

1db1ce45

2017-06-27T14:22:39

TJBench: Improve consistency of results Given that libjpeg-turbo can often process hundreds of megapixels/second on modern hardware, the default of one warmup iteration was essentially meaningless. Furthermore, the -warmup option was a bit clunky, since it required some foreknowledge of how fast the benchmarks were going to execute. This commit introduces a 1-second warmup interval for each benchmark by default, and the -warmup option has been retasked to control the length of that interval.

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

6a2b0674

2017-05-11T18:33:47

TJBench: Code formatting tweaks Spaces-->tab + remove stray control character that was introduced in 95e4cb206085c3a715f0f017c174fdf367a2c1ff

11eec4a3

2017-06-26T20:48:02

TJBench: Fix errors when decomp. files w/ ICC data Embedded ICC profiles can cause the size of a JPEG file to exceed the size returned by tjBufSize() (which is really meant to be used for compression anyhow, not for decompression), and this was causing a segfault (C) or an ArrayIndexOutOfBoundsException (Java) when decompressing such files with TJBench. This commit modifies the benchmark such that, when tiled decompression is disabled, it re-uses the source buffer as the primary JPEG buffer.

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?

31280613

2016-02-01T11:03:39

TJBench: Fix segfault on Android For whatever reason, the "write" global variable in tjbench.c was overriding the linkage with the write() system function. This may have affected other platforms as well but was not known to.

9c8cee8c

2016-01-13T13:01:45

tjbench: Further tweaks to -nowrite feature * Do not compute compression error if -nowrite is specified * Adjust formatting of -nowrite usage description

eb59b6e7

2016-01-11T22:27:38

Add -nowrite arg to TJBench to improve consistency Prevents any images from being written to disk, thus making the performance of the benchmark as CPU-bound as possible.

cbc9970e

2015-01-16T06:29:52

Add the ability to benchmark YCCK JPEG compression/decompression. This is particularly useful since that is the only way to test the performance of the "plain" upsampling routines, which are accelerated on some platforms. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1511 632fc199-4ca6-4c93-a231-07263d6284db

2ab5ea6c

2015-01-14T19:39:01

Add the ability to benchmark YCCK JPEG compression/decompression. This is particularly useful since that is the only way to test the performance of the "plain" upsampling routines, which are accelerated on some platforms. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1505 632fc199-4ca6-4c93-a231-07263d6284db

eb66974f

2014-08-22T19:59:51

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. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1384 632fc199-4ca6-4c93-a231-07263d6284db

f5644c34

2014-08-22T19:27:28

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. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1383 632fc199-4ca6-4c93-a231-07263d6284db

684ace19

2014-08-22T03:04:06

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.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1374 632fc199-4ca6-4c93-a231-07263d6284db

43513893

2014-08-22T02:57:34

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.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1372 632fc199-4ca6-4c93-a231-07263d6284db

1a45b81f

2014-05-09T18:06:58

Remove trailing spaces (+ one additional tab in TJUnitTest.java that was missed in the previous commit) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1279 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

dd5fcdd0

2014-03-17T10:40:10

formatting tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1183 632fc199-4ca6-4c93-a231-07263d6284db

78b227e2

2014-03-14T04:15:43

Oops. This code should not have been removed. It is necessary for generating the error images. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1165 632fc199-4ca6-4c93-a231-07263d6284db

ce6891f0

2014-03-13T20:33:43

If we have transformed a 4:2:2 or 4:4:0 image in any way that transposes the horizontal and vertical dimensions, then we need to inform the decompression function that the subsampling type has changed. Otherwise, tjDecodeYUV() will not produce correct results. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1162 632fc199-4ca6-4c93-a231-07263d6284db

adf5551b

2014-03-12T07:17:23

Execute warmup runs with tjTransform() as well git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1159 632fc199-4ca6-4c93-a231-07263d6284db

e1efc8a0

2014-03-12T07:16:17

Fix a couple of output formatting issues git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1158 632fc199-4ca6-4c93-a231-07263d6284db

95e4cb20

2014-03-12T06:51:39

Since we now have a complete set of YUV functions, TJBench can be greatly simplified. It now tests YUV encoding/decoding as an intermediate step of JPEG compression/decompression, which eliminates the need for a separate YUV mode. Several other things have been streamlined in the process. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1157 632fc199-4ca6-4c93-a231-07263d6284db

0e9bf644

2014-03-12T06:17:12

Fix a segfault that would occur in decompress-only mode if -alloc was specified without -tile. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1156 632fc199-4ca6-4c93-a231-07263d6284db

dd59233d

2014-03-12T06:15:51

Fix a segfault that would occur in decompress-only mode if -alloc was specified without -tile. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1155 632fc199-4ca6-4c93-a231-07263d6284db

a15f19f2

2014-03-11T09:46:50

Wordsmithing & formatting tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1154 632fc199-4ca6-4c93-a231-07263d6284db

d4b453c2

2014-03-11T08:28:47

Back-port the -subsamp option from 1.4 rather than use the hackish approach of replacing 4:2:2 with 4:4:0. This has the added advantage of allowing the user to test only a specific level of subsampling. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1153 632fc199-4ca6-4c93-a231-07263d6284db

c6501f7f

2013-11-04T23:07:54

Add the ability to test scaling when decompressing to YUV; compression from YUV to JPEG; and YUV padding. Replace clunky -411 and -440 parameters with a -subsamp parameter that allows any of the subsampling options to be tested in isolation. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1074 632fc199-4ca6-4c93-a231-07263d6284db

07e982d9

2013-10-31T07:11:39

Deprecate and undocument the FORCE{MMX|SSE|SSE2|SSE3} flags. These were originally introduced in TurboJPEG/IPP as a way to override the automatic CPU selection in the underlying IPP codec, which was closed source. They are not meaningful anymore, since libjpeg-turbo provides environment variables to accomplish the same thing and since it no longer necessarily uses x86 SIMD code behind the scenes. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1072 632fc199-4ca6-4c93-a231-07263d6284db

c45653e4

2013-10-12T21:52:48

Fix a couple of issues with return value checking. JFREAD(), which wraps fread(), will never return -1. fread() will instead return 0 or a short object count if an error occurs, and ferror() will return 1 in that case. The second issue was that we were assigning the return value of ftell() to an unsigned long prior to checking the value, so the value would never be < 0 if an error occurred. It would instead be (unsigned long)-1. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1061 632fc199-4ca6-4c93-a231-07263d6284db

490c7f95

2013-10-12T21:51:16

Fix a couple of issues with return value checking. JFREAD(), which wraps fread(), will never return -1. fread() will instead return 0 or a short object count if an error occurs, and ferror() will return 1 in that case. The second issue was that we were assigning the return value of ftell() to an unsigned long prior to checking the value, so the value would never be < 0 if an error occurred. It would instead be (unsigned long)-1. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1060 632fc199-4ca6-4c93-a231-07263d6284db

38cb1ec2

2013-08-23T04:45:43

Add CMYK support to the TurboJPEG Java API & clean up a few things in the C API git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1020 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

d081fd72

2013-08-18T09:15:37

Add note regarding the fact that 4:4:0 lacks full SIMD support; Add an option for benchmarking 4:4:0 subsampling in tjbench. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1009 632fc199-4ca6-4c93-a231-07263d6284db

07796da4

2013-08-18T09:13:00

Add note regarding the fact that 4:4:0 lacks full SIMD support; Add an option for benchmarking 4:4:0 subsampling in tjbench. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1008 632fc199-4ca6-4c93-a231-07263d6284db

cc336e7b

2012-06-29T23:51:35

Cosmetic fixes to argument lists git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@852 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

cac10513

2012-03-16T14:37:36

Fix the behavior of the alpha-enabled colorspace constants whenever libjpeg-turbo is built without SIMD support and merged upsampling is used. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@811 632fc199-4ca6-4c93-a231-07263d6284db

ffe4fc18

2012-03-16T14:30:46

Fix the behavior of the alpha-enabled colorspace constants whenever libjpeg-turbo is built without SIMD support and merged upsampling is used. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@810 632fc199-4ca6-4c93-a231-07263d6284db

ab2df6ea

2012-01-28T06:49:56

Expose new scaling factors in TurboJPEG API git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@757 632fc199-4ca6-4c93-a231-07263d6284db

e006f5c4

2012-01-28T06:31:44

Oops. Height of output buffer should equal scaled height, not JPEG height. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@755 632fc199-4ca6-4c93-a231-07263d6284db

kc3-lang/libjpeg-turbo/tjbench.c

tjbench.c

Log