kc3-lang/libjpeg-turbo/java

java

Log

Author Commit Date CI Message
DRC 758e8a8e 2024-09-05T14:55:50 Java: Use Java-style method nomenclature :: is a C++ thing.
DRC 5550c80f 2024-09-03T17:20:10 Doc: "compress operation"="compression operation" (consistification)
DRC 797c6ccd 2024-09-01T11:23:31 Doc: Further clarify MCU definition
DRC 8d76e4e5 2024-08-31T15:33:55 Doc: "EXIF" = "Exif"
DRC 9983840e 2024-08-31T12:41:13 TJ/xform: Check crop region against dest. image Lossless cropping is performed after other lossless transform operations, so the cropping region must be specified relative to the destination image dimensions and level of chrominance subsampling, not the source image dimensions and level of chrominance subsampling. More specifically, if the lossless transform operation swaps the X and Y axes, or if the image is converted to grayscale, then that changes the cropping region requirements.
DRC 8456d2b9 2024-08-30T10:50:13 Doc: "MCU block" = "iMCU" or "MCU" The JPEG-1 spec never uses the term "MCU block". That term is rarely used in other literature to describe the equivalent of an MCU in an interleaved JPEG image, but the libjpeg documentation uses "iMCU" to describe the same thing. "iMCU" is a better term, since the equivalent of an interleaved MCU can contain multiple DCT blocks (or samples in lossless mode) that are only grouped together if the image is interleaved. In the case of restart markers, "MCU block" was used in the libjpeg documentation instead of "MCU", but "MCU" is more accurate and less confusing. (The restart interval is literally in MCUs, where one MCU is one data unit in a non-interleaved JPEG image and multiple data units in a multi-component interleaved JPEG image.) In the case of 9b704f96b2dccc54363ad7a2fe8e378fc1a2893b, the issue was actually with progressive JPEG images exactly two DCT blocks wide, not two MCU blocks wide. This commit also defines "MCU" and "MCU row" in the description of the various restart marker options/parameters. Although an MCU row is technically always a row of samples in lossless mode, "sample row" was confusing, since it is used in other places to describe a row of samples for a single component (whereas an MCU row in a typical lossless JPEG image consists of a row of interleaved samples for all components.)
DRC 5cf79606 2024-08-28T18:36:37 Undocument TJ*PARAM_RESTARTBLOCKS for lossless TJ*PARAM_RESTARTBLOCKS technically works with lossless compression, but it is not useful, since the value must be equal to the number of samples in a row. (In other words, it is no different than TJ*PARAM_RESTARTINROWS, except that it requires the user to do more math.)
DRC d6207971 2024-08-28T18:00:14 TJBench: Don't override subsamp until args parsed Otherwise, passing -subsamp after -lossless might cause the worst-case JPEG buffer size to be too small.
DRC 548f7324 2024-08-26T10:14:11 TJBench: Usage screen tweak Indicate that -maxmemory and -maxpixels take an integer argument.
DRC de4bbac5 2024-08-23T12:48:01 TJCompressor.compress(): Fix lossls buf size calc
DRC d44fc54f 2024-08-21T15:00:58 Java: Unset srcBuf12/16 with BufferedImage/YUV src Due to an oversight in the multi-precision feature, TJCompressor.srcBuf12 and TJCompressor.srcBuf16 were not set to null in TJCompressor.setSourceImage(YUVImage) or TJCompressor.setSourceImage(BufferedImage, ...). Thus, if an application set a 12-bit or 16-bit packed-pixel buffer as the source image then set a BufferedImage with integer pixels as the source image, TJCompress.compress() would compress from the 12-bit or 16-bit packed-pixel buffer instead of the BufferedImage. The odds of an application actually doing that are very slim, however.
DRC 8c2e7306 2024-08-21T13:03:41 Java doc: Minor formatting tweak
DRC 49f1b580 2024-08-20T12:57:37 TJBench.java: Explicitly set restartIntervalBlocks This is just a readability thing. Java initializes integer fields to 0 by default.
DRC 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
DRC 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.
DRC 94c64ead 2024-06-17T20:27:57 Various doc tweaks - "bits per component" = "bits per sample" Describing the data precision of a JPEG image using "bits per component" is technically correct, but "bits per sample" is the terminology that the JPEG-1 spec uses. Also, "bits per component" is more commonly used to describe the precision of packed-pixel formats (as opposed to "bits per pixel") rather than planar formats, in which all components are grouped together. - Unmention legacy display technologies. Colormapped and monochrome displays aren't a thing anymore, and even when they were still a thing, it was possible to display full-color images to them. In 1991, when JPEG decompression time was measured in minutes per megapixel, it made sense to keep a decompressed copy of JPEG images on disk, in a format that could be displayed without further color conversion (since color conversion was slow and memory-intensive.) In 2024, JPEG decompression time is measured in milliseconds per megapixel, and color conversion is even faster. Thus, JPEG images can be decompressed, displayed, and color-converted (if necessary) "on the fly" at speeds too fast for human vision to perceive. (In fact, your TV performs much more complicated decompression algorithms at least 60 times per second.) - Document that color quantization (and associated features), GIF input/output, Targa input/output, and OS/2 BMP input/output are legacy features. Legacy status doesn't necessarily mean that the features are deprecated. Rather, it is meant to discourage users from using features that may be of little or no benefit on modern machines (such as low-quality modes that had significant performance advantages in the early 1990s but no longer do) and that are maintained on a break/fix basis only. - General wordsmithing, grammar/punctuation policing, and formatting tweaks - Clarify which data precisions each cjpeg input format and each djpeg output format supports. - cjpeg.1: Remove unnecessary and impolitic statement about the -targa switch. - Adjust or remove performance claims to reflect the fact that: * On modern machines, the djpeg "-fast" switch has a negligible effect on performance. * There is a measurable difference between the performance of Floyd- Steinberg dithering and no dithering, but it is not likely perceptible to most users. * There is a measurable difference between the performance of 1-pass and 2-pass color quantization, but it is not likely perceptible to most users. * There is a measurable difference between the performance of full-color and grayscale output when decompressing a full-color JPEG image, but it is not likely perceptible to most users. * IDCT scaling does not necessarily improve performance. (It generally does if the scaling factor is <= 1/2 and generally doesn't if the scaling factor is > 1/2, at least on my machine. The performance claim made in jpeg-6b was probably invalidated when we merged the additional scaling factors from jpeg-7.) - Clarify which djpeg switches/output formats cannot be used when decompressing lossless JPEG images. - Remove djpeg hints, since those involve quality vs. speed tradeoffs that are no longer relevant for modern machines. - Remove documentation regarding using color quantization with 16-bit data precision. (Color quantization requires lossy mode.) - Java: Fix typos in TJDecompressor.decompress12() and TJDecompressor.decompress16() documentation. - jpegtran.1: Fix truncated paragraph In a man page, a single quote at the start of a line is interpreted as a macro. Closes #775 - libjpeg.txt: * Mention J16SAMPLE data type (oversight.) * Remove statement about extending jdcolor.c. (libjpeg-turbo is not quite as DIY as libjpeg once was.) * Remove paragraph about tweaking the various typedefs in jmorecfg.h. It is no longer relevant for modern machines. * Remove caveat regarding systems with ints less than 16 bits wide. (ANSI/ISO C requires an int to be at least 16 bits wide, and libjpeg-turbo has never supported non-ANSI compilers.) - usage.txt: * Add copyright header. * Document cjpeg -icc, -memdst, -report, -strict, and -version switches. * Document djpeg -icc, -maxscans, -memsrc, -report, -skip, -crop, -strict, and -version switches. * Document jpegtran -icc, -maxscans, -report, -strict, and -version switches.
Kleis Auke Wolthuizen 24e09baa 2024-04-12T11:46:21 Build: Add COMPONENT to all install() commands This makes it possible for downstream packagers and other integrators of libjpeg-turbo to include only specific directories from the libjpeg-turbo installation (or to install specific directories under a different prefix, etc.) The names of the components correspond to the directories into which they will be installed. Refer to libvips/libvips#3931, #265, #338 Closes #756
DRC d59b1a3b 2024-01-30T15:40:51 Build: Reformat lines longer than 80 columns ... ... to ensure that no function argument starts beyond the 80th column.
DRC be96fa0a 2023-12-14T13:18:20 Doc: Lossless JPEG clarifications - Clarify that lossless JPEG is slower than and doesn't compress as well as lossy JPEG. (That should be obvious, because "lossy" literally means that data is thrown away.) - Re-generate TurboJPEG C API documentation using Doxygen 1.9.8. - Clarify that setting the data_precision field in jpeg_compress_struct to 16 requires lossless mode. - Explain what the predictor selection value actually does. (Refer to Recommendation ITU-T T.81 (1992) | ISO/IEC 10918-1:1994, Section H.1.2.1.)
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 6136a9e2 2023-11-16T14:12:28 Java doc: Terminology tweaks - "function" = "method" - "decompression and transform functions" = "decompression and transform operations" (for consistency with the 2.1.x documentation) - "return an error" = "throw an error" - "ceil()" = "Math.ceil()"
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 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 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 1a1ea4ee 2023-01-25T12:28:42 Merge branch 'main' into dev
DRC 27f4ff80 2023-01-25T11:09:36 Java: Guard against int overflow in size methods Because Java array sizes are ints, the various size methods in the TJ class have int return values. Thus, we have to guard against signed int overflow at the JNI level, because the C functions can return sizes greater than INT_MAX. This also adds a test for TJ.planeWidth() and TJ.planeHeight(), in order to validate 8a1526a442a9eca8813fcf878fa5cfdd4260be83 in Java.
DRC 52659f4f 2023-01-23T09:55:13 Merge branch 'main' into dev
DRC edbb7e6d 2023-01-23T09:32:57 Java doc: TJ.pixelSize --> TJ.getPixelSize() TJ.pixelSize isn't actually a thing. Oops.
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 2aac5458 2023-01-20T16:02:30 TJExample: Remove "underlying codec" references (Oversight from 9a146f0f23b01869e1bf7c478e12b43f83d59c32)
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 b99e7590 2023-01-20T10:50:21 TJBench/Java: Fix parsing of quality ranges
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 6a060d8c 2023-01-17T18:32:15 TJCompressor.java: (C) header formatting tweak (apparently borked by one of the previous merge commits)
DRC c7c02d92 2023-01-17T18:31:31 Merge branch 'main' into dev
DRC 7ed186ed 2023-01-17T18:18:27 TJDecompressor.java: Exception message tweak NO_ASSOC_ERROR is specific to JPEG source images, but the decompress() methods can handle YUV source images as well.
DRC 155a8b03 2023-01-16T17:02:01 Merge branch 'main' into dev
DRC 0c0df2d0 2023-01-16T16:52:46 TJDecompressor.java: "YUV" = "planar YUV" (Oversight from 9a146f0f23b01869e1bf7c478e12b43f83d59c32)
DRC 22a66368 2023-01-16T15:32:49 Java: Don't allow int overflow in buf size methods This is similar to the fix that 2a9e3bd7430cfda1bc812d139e0609c6aca0b884 applied to the C API. We have to apply it separately at the JNI level because the Java API always stores buffer sizes in 32-bit integers, and the C buffer size functions could overflow an int when using 64-bit code. (NOTE: The Java API stores buffer sizes in 32-bit integers because Java itself always uses 32-bit integers for array sizes.) Since Java don't allow no buffer overruns 'round here, this commit doesn't change the ultimate outcome. It just makes the inevitable exception easier to diagnose.
DRC d859232d 2023-01-14T18:27:37 TurboJPEG: Use 4:4:4 for lossless JPEG buf calcs
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 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 b3d3cbf4 2022-09-12T14:41:34 JNI: Remove deprecated methods (oversight from 931884e78dc8777e6477451e984af8b263e450b1)
DRC 931884e7 2022-08-08T15:41:01 Java: Remove deprecated fields, ctors, and methods Most of these have been deprecated since libjpeg-turbo 1.4.x. It's time.
DRC ba22c0f7 2022-06-24T14:03:03 tjDecompressHeader3(): Accept tables-only streams Inspired by: https://github.com/amyspark/libjpeg-turbo/commit/b3b15cfe74cf07914122e26cf1e408a9a9cf3135 Closes #604 Closes #605
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 ffc1aa96 2021-04-21T11:06:22 Include TJ.FLAG_LIMITSCANS in JNI header (oversight from c81e91e8ca34f4e8b43cf48277c2becf3fe9447d) This is purely cosmetic, since the JNI wrapper doesn't actually use that flag.
DRC c81e91e8 2021-04-05T16:08:22 TurboJPEG: New flag for limiting prog JPEG scans This also fixes timeouts reported by OSS-Fuzz.
DRC 1d7faf84 2020-10-01T18:17:46 Merge branch 'master' into dev
DRC 8e895c79 2020-10-01T18:13:35 Java dox: Fix errors w/ javadoc in Java 8 or later
DRC fb6f5e8b 2020-06-25T21:31:11 Java/Mac:Remove obsolete libturbojpeg.jnilib alias IIRC, this was only necessary with the version of Java 1.5 that shipped with OS X 10.4 "Tiger". Apple's implementation of Java 6 ("Java for OS X Systems") supported both .jnilib and .dylib extensions for JNI libraries, but Oracle's implementation of Java has only ever supported the .dylib extension.
DRC 8cc1277b 2020-02-24T13:29:50 TJCompressor.compress(int): Fix YUV-to-JPEG error Due to an oversight, the TJCompressor.compress(int) method did not handle YUV source images. Fixes #413
DRC ac59b2c5 2019-11-04T18:49:46 TJBench: Fix output with -componly -quiet
DRC ad8330af 2019-07-12T17:28:55 TJBench.java: Remove space in method invocation (to make checkstyle happy)
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 0fa5ae6b 2019-01-01T21:16:33 TJBench Java: Properly handle transform warnings + warnings from TJDecompressor.decompressHeader()
DRC f2729c98 2018-09-21T15:50:08 Build: Update javah target to work with JDK 10+ javah is no longer a thing, but 'javac -h' can accomplish the same task.
DRC eb8bba62 2018-05-16T10:49:09 Java: Further style refinements (detected by enabling additional checkstyle modules) This commit also removes unnecessary uses of the "private" modifier in the Java tests/examples. The default access modifier disallows access outside of the package, and none of these classes is in a package. The only reason we use "private" with member variables in these classes is to make checkstyle happy, because we want it to enforce that behavior in the TurboJPEG API code.
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 b2d000e6 2018-04-11T10:47:16 "Further" = "Furthermore" Grammar Police. Has Ray Stevens taught me nothing?
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 8c40ac8a 2017-11-16T18:46:01 Add TurboJPEG C example and clean up Java example Also rename example.c --> example.txt and add a disclaimer to that file so people will stop trying to compile it.
DRC dc4b9002 2017-11-16T20:43:12 TurboJPEG: Add alpha offset array/method Also, set the red/green/blue offsets for TJPF_GRAY to -1 rather than 0. It was undefined behavior for an application to use those arrays/methods with TJPF_GRAY anyhow, and this makes it easier for applications to programmatically detect whether a given pixel format has red, green, and blue components.
DRC 4893e5d8 2017-11-17T19:00:53 Merge branch 'master' into dev
DRC 19b393b6 2017-11-17T18:45:08 TJExample: Fix array index OOB w/ 4:1:1 JPEG input
DRC 468f2fed 2017-11-15T19:33:06 TJExample.java: Don't ignore mistyped args
DRC f3ad13e3 2017-11-13T16:00:35 TJBench/TJUnitTest: Don't ignore mistyped args
DRC 7106ffe5 2017-09-02T04:20:03 Merge branch 'master' into dev
DRC 5426a4cb 2017-09-02T04:08:06 TJUnitTest: Usage formatting tweaks
DRC d0bac69a 2017-09-02T03:40:46 Java: Fix TJUnitTest on big endian platforms It is necessary for the C code to be aware of the machine's endianness, which is why the TurboJPEG Java wrapper sets a different pixel format for integer BufferedImages depending on ByteOrder.nativeOrder(). However, it isn't necessary to handle endianness in pure Java code such as TJUnitTest (d'oh!) This was a product of porting the C version of TJUnitTest too literally, and of insufficient testing (historically, the big endian systems I had available for testing didn't have Java.)
DRC c0f3512d 2017-08-31T20:57:19 Merge branch 'master' into dev
DRC 32120054 2017-08-14T10:54:27 Java: Fix NullPointerException in YUVImage planes == null is a valid argument to setBuf() if alloc == true, so we need to make sure that planes is non-null before validating its length. We also need to allocate one dimension of the planes array if it's null. Fixes #168
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 e248d430 2017-06-28T14:40:35 Java TJBench: Fix parsing of -warmup argument Due to an oversight, this wasn't included in 1db1ce45da2e78d87ff05119b674c71d630926aa.
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 42e1e2d8 2017-06-26T19:19:44 Build: Custom target for generating JNI headers
DRC 25c912c1 2017-05-11T21:29:07 Build: Add custom target for generating Java docs
DRC 178796e7 2017-05-11T21:23:45 Build: Fix buglet in java/CMakeLists.txt (MSYS) CMAKE_HOST_SYSTEM_NAME should be restored with the value of CMAKE_HOST_SYSTEM_NAME_BAK.
DRC 2ac4e9d9 2017-06-26T21:58:32 Merge branch 'master' into dev
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 6530203f 2016-12-09T10:21:29 Build: More GNUInstallDirs improvements These improvements enable build systems to use GNUInstallDirs to define custom directory variables. - The set_dir() macro was renamed to GNUInstallDirs_set_install_dir(), in keeping with the module's established macro naming convention. - Rather than detecting whether the prefix has changed, the new GNUInstallDirs_set_install_dir() macro instead examines whether the default for the variable in question has changed. This allows for more flexibility, since build systems may decide to change the defaults based on factors other than the prefix. It also enables the macro to work properly outside of the module. - The module now performs directory variable substitution within the body of GNUInstallDirs_get_absolute_install_dir(). - The JAVADIR variable is no longer included in GNUInstallDirs. That directory is not part of the GNU spec, and it turns out that various operating systems use different conventions for the location of Java classes. Instead, the variable is now implemented in our build system as a demonstration of the aforementioned GNUInstallDirs enhancements.
DRC d681fa76 2016-12-07T10:54:54 Build: Set install dirs in a more GNU-friendly way This builds upon the existing GNUInstallDirs module in CMake but adds the following features to that module: - The ability to override the defaults for each install directory through a new set of variables (`CMAKE_INSTALL_DEFAULT_*DIR`). Before operating system vendors began shipping libjpeg-turbo, it was meant to be a run-time drop-in replacement for the system's distribution of libjpeg, so it has traditionally installed itself under /opt/libjpeg-turbo on Un*x systems by default. On Windows, it has traditionally installed itself under %SystemDrive%\libjpeg-turbo*, which is not uncommon behavior for open source libraries (open source SDKs tend to install outside of the Program Files directory so as to avoid spaces in the directory name.) At least in the case of Un*x, the install directory behavior is based somewhat on the Solaris standard, which requires all non-O/S packages to install their files under /opt/{package_name}. I adopted that standard for VirtualGL and TurboVNC while working at Sun, because it allowed those packages to be located under the same directory on all platforms. I adopted it for libjpeg-turbo because it ensured that our files would never conflict with the system's version of libjpeg. Even though many Un*x distributions ship libjpeg-turbo these days, not all of them ship the TurboJPEG API library or the Java classes or even the latest version of the libjpeg API library, so there are still many cases in which it is desirable to install a separate version of libjpeg-turbo than the one installed by the system. Furthermore, installing the files under /opt mimics the directory structure of our official binary packages, and it makes it very easy to uninstall libjpeg-turbo. For these reasons, our build system needs to be able to use non-GNU-compliant defaults for each install directory if `CMAKE_INSTALL_PREFIX` is set to the default value. - For each directory variable, the module now detects changes to `CMAKE_INSTALL_PREFIX` and changes the directory variable accordingly, if the variable has not been changed by the user. This makes it easy to switch between our "official" directory structure and the GNU-compliant directory structure "on the fly" simply by changing `CMAKE_INSTALL_PREFIX`. Also, this new mechanism eliminated the need for the crufty mechanism that previously did the same thing just for the library directory variable. How it should work: - If a dir variable is unset, then the module will set an internal property indicating that the dir variable was initialized to its default value. - If the dir variable ever diverges from its default value, then the internal property is cleared, and it cannot be set again without unsetting the dir variable. - If the install prefix changes, and if the internal property indicates that the dir variable is still set to its default value, and if the dir variable's value is not being manually changed at the same time that the install prefix is being changed, then the dir variable's value is automatically changed to the new default value for that variable (as determined by the new install prefix.) - The directory variables are now always cached, regardless of whether they were set on the command line or not. This ensures that they can easily be examined and modified after being set, regardless of how they were set. This was made possible by the introduction of the aforementioned `CMAKE_INSTALL_DEFAULT_*DIR` variables. - Improved directory variable documentation (based on descriptions at https://www.gnu.org/prep/standards/html_node/Directory-Variables.html) - The module now allows "<DATAROOTDIR>" to be used as a placeholder in relative directory variables. It is replaced "on the fly" with the actual path of `CMAKE_INSTALL_DATAROOTDIR`. This should more closely mimic the behavior of the old autotools build system while retaining our customizations to it, and it should retain the behavior of the old CMake build system. Closes #124
DRC 6abd3916 2016-11-15T08:47:43 Unified CMake-based build system See #56 for discussion. Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73 Obviates #82 See also: https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/ https://sourceforge.net/p/libjpeg-turbo/patches/5/
DRC 74e4c793 2016-11-16T15:08:16 TJBench: Fix regression/-nowrite always enabled Introduced by eb59b6e72d8098a1f7b8c7e0c710b32eb6f5dc45
DRC 7cb8de4a 2016-03-02T09:53:11 Java: Fix parallel make with autotools Running 'make -j{jobs}' on a build that was configured with Java (--with-java) would previously cause an error: make: *** No rule to make target `TJExample.class', needed by `turbojpeg.jar'. It seems that parallel make doesn't understand that the files in $(JAVA_CLASSES) are all generated from the same invocation of javac, so it tries to parallelize the building of those files (which of course doesn't work.) This patch instead makes turbojpeg.jar depend on classnoinst.stamp. This effectively creates a synchronization fence, since that file is only created when all of the class files have been built. Fixes #62
DRC d123c125 2016-02-09T01:35:39 Java: Avoid OOM error when running 'make test' We need to garbage collect between iterations of the outside loop in bufSizeTest() in order to avoid exhausting the heap when running with Java 6 (which is still used on Linux to test the 32-bit version of libjpeg-turbo in automated builds.)
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.
kmx.io     mail     discord kmxgit v0.4.0