kc3-lang/libjpeg-turbo/tjbench.c

tjbench.c

Log

Author Commit Date CI Message
DRC 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.)
DRC 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
DRC 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.
DRC 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.
DRC 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)
DRC 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.
DRC 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
DRC 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.
DRC 427c3045 2023-01-27T14:31:48 tjbench.c: Fix Windows build error (regression introduced by d7790789a6c3f0867175d781948e9d10fc55520d)
DRC 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
DRC 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.
DRC 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
DRC 52659f4f 2023-01-23T09:55:13 Merge branch 'main' into dev
DRC 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.
DRC 7ab6222c 2023-01-20T14:09:25 Merge branch 'main' into dev
DRC 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.
DRC 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)
DRC 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)
DRC d4589f4f 2023-01-14T18:07:53 Merge branch 'main' into dev
DRC 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.
DRC 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.
DRC 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.
DRC 25ccad99 2022-11-16T15:57:25 TurboJPEG: 8-bit lossless JPEG support
DRC 6002720c 2022-11-15T23:10:35 TurboJPEG: Opt. enable arithmetic entropy coding
DRC 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.
DRC 13377e6b 2022-02-11T13:58:31 MSVC: Eliminate int conversion warnings (C4244)
DRC 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
DRC 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.
DRC 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
DRC c81e91e8 2021-04-05T16:08:22 TurboJPEG: New flag for limiting prog JPEG scans This also fixes timeouts reported by OSS-Fuzz.
DRC 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.
DRC 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
DRC 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
DRC ac59b2c5 2019-11-04T18:49:46 TJBench: Fix output with -componly -quiet
DRC b25adabc 2019-07-12T17:27:37 tjbench.c: Fix minor code formatting errors (introduced by 2a9e3bd7430cfda1bc812d139e0609c6aca0b884)
DRC 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
DRC 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)
DRC bce58f48 2019-04-12T07:49:35 Consistify formatting of macros in TurboJPEG code
DRC 031e16ec 2019-02-11T22:43:15 tjbench.c: Fix GCC 8 compiler warning
DRC 1ff90822 2019-01-01T21:08:27 TJBench: Fix FPE when decompressing 0-width JPEG Fixes #319
DRC c701014d 2018-11-12T12:27:23 tjbench.c: Fix compiler warnings with GCC 8 strncpy() may fail to truncate dst if len == strlen(dst).
DRC 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)
DRC 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
DRC 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.
DRC 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.
DRC 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.
DRC 4893e5d8 2017-11-17T19:00:53 Merge branch 'master' into dev
DRC 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.)
DRC f3ad13e3 2017-11-13T16:00:35 TJBench/TJUnitTest: Don't ignore mistyped args
DRC 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.
DRC 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
DRC dedce66e 2017-06-28T15:30:41 Merge branch 'master' into dev
DRC 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.
DRC 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.)
DRC 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
DRC 6a2b0674 2017-05-11T18:33:47 TJBench: Code formatting tweaks Spaces-->tab + remove stray control character that was introduced in 95e4cb206085c3a715f0f017c174fdf367a2c1ff
DRC 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.
DRC 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?
DRC 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.
DRC 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
DRC 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.
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 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
DRC 20c7dbc6 2011-10-18T22:06:22 Fix compiler warning git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@713 632fc199-4ca6-4c93-a231-07263d6284db
DRC f5467110 2011-09-20T05:02:19 Implement custom filter callback in Java git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@707 632fc199-4ca6-4c93-a231-07263d6284db
DRC 57a37362 2011-09-17T00:41:14 git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@704 632fc199-4ca6-4c93-a231-07263d6284db
DRC 7bf04d39 2011-09-17T00:18:31 Implement a custom DCT filter callback for lossless transforms git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@703 632fc199-4ca6-4c93-a231-07263d6284db
kmx.io     mail     discord kmxgit v0.4.0