kc3-lang/libjpeg-turbo/java

java

Log

Author Commit Date CI Message
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.
DRC 739edeb8 2015-07-21T09:34:02 Further exception cleanup Use a new checked exception type (TJException) when passing through errors from the underlying C library. This gives the application a choice of catching all exceptions or just those from TurboJPEG. Throw IllegalArgumentException at the JNI level when arguments to the JNI function are incorrect, and when one of the TurboJPEG "utility" functions returns an error (because, per the C API specification, those functions will only return an error if one of their arguments is out of range.) Remove "throws Exception" from the signature of any methods that no longer pass through an error from the TurboJPEG C library. Credit Viktor for the new code Code formatting tweaks
DRC b3817dab 2015-07-14T20:42:52 Throw idiomatic unchecked exceptions from the Java classes and JNI wrapper if there is an unrecoverable error caused by incorrect API usage (such as illegal arguments, etc.), and throw Errors if there is an unrecoverable error at the C level (such as a failed malloc() call.) Change the behavior of the bailif0() macro in the JNI wrapper so that it doesn't throw an exception for an unexpected NULL condition. In fact, in all cases, the underlying JNI API function (such as GetFieldID(), etc.) will throw an Error on its own whenever it returns NULL, so our custom exceptions were never being thrown in that case anyhow. All we need to do is just detect the error and bail out of the C code. This also corrects a couple of formatting issues (semicolons aren't needed at the end of class definitions, and @Override should be specified for the methods we're overriding from super-classes, so the compiler can sanity-check that we're actually overriding a method and not declaring a new one.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1595 632fc199-4ca6-4c93-a231-07263d6284db
DRC 1a4778f8 2015-07-07T16:39:03 Allow TJCompressor and TJDecompressor to be used with a try-with-resources statement in Java 7 and later. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1594 632fc199-4ca6-4c93-a231-07263d6284db
DRC 7a8c53e4 2015-06-19T16:07:14 Clarify that the TurboJPEG API functions/methods do not modify the source buffer. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1567 632fc199-4ca6-4c93-a231-07263d6284db
DRC 2e429094 2015-01-27T21:00:22 Oops. Need to set the alpha channel when using TYPE_4BYTE_ABGR*. This has no bearing on the actual tests, but it prevents the PNG pre-encode reference images for those tests from being blank. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1526 632fc199-4ca6-4c93-a231-07263d6284db
DRC dcf9f15d 2015-01-27T20:59:16 Oops. Need to set the alpha channel when using TYPE_4BYTE_ABGR*. This has no bearing on the actual tests, but it prevents the PNG pre-encode reference images for those tests from being blank. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1525 632fc199-4ca6-4c93-a231-07263d6284db
DRC ef263e3e 2014-11-21T15:35:33 Make TJCompressor.close() and TJDecompressor.close() idempotent git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1420 632fc199-4ca6-4c93-a231-07263d6284db
DRC 3ebcf7cf 2014-11-18T21:45:34 Make TJCompressor.close() and TJDecompressor.close() idempotent git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1416 632fc199-4ca6-4c93-a231-07263d6284db
DRC d92949b0 2014-08-22T03:00:37 Run the TurboJPEG conformance tests out of a directory in /tmp (for improved performance, if the source directory is on a remote file share.) Fix an issue in TJBench.java that prevented it from working properly if the source image resided in a directory with a dot in the name. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1373 632fc199-4ca6-4c93-a231-07263d6284db
DRC a1a920cc 2014-08-22T02:51:16 Run the TurboJPEG conformance tests out of a directory in /tmp (for improved performance, if the source directory is on a remote file share.) Fix an issue in TJBench.java that prevented it from working properly if the source image resided in a directory with a dot in the name. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1371 632fc199-4ca6-4c93-a231-07263d6284db
DRC 40dd3146 2014-08-17T12:23:49 Refactored YUVImage Java class so that it supports both unified YUV image buffers as well as separate YUV image planes; modified the JNI functions accordingly and added new helper functions to the TurboJPEG C API (tjPlaneWidth(), tjPlaneHeight(), tjPlaneSizeYUV()) to facilitate those modifications; changed potentially confusing "component width" and "component height" terms to "plane width" and "plane height" and modified variable names in turbojpeg.c to reflect this; numerous other documentation tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1360 632fc199-4ca6-4c93-a231-07263d6284db
DRC 580f3915 2014-08-15T14:40:36 Fix build broken by r1349 git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1351 632fc199-4ca6-4c93-a231-07263d6284db
DRC 26dd86bd 2014-08-15T14:01:21 Restore backward compatibility between libjpeg-turbo 1.3.x JAR and the new JNI library git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1349 632fc199-4ca6-4c93-a231-07263d6284db
DRC 493be617 2014-08-10T20:12:17 Clean up and consolidate notes regarding the YUV image format. This also corrects a factual error regarding the padding of the luminance plane-- because we now support 4:1:1, the component width is not necessarily padded to the nearest multiple of 2 if horizontal subsampling is used. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1342 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 6f92ff61 2014-03-22T23:03:03 Fix Windows build git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1206 632fc199-4ca6-4c93-a231-07263d6284db
DRC 7a6ed075 2014-03-17T11:14:52 Extend YUVImage class to allow reuse of the same buffer with different metadata; port TJBench changes that treat YUV encoding/decoding as an intermediate step of the JPEG compression/decompression pipeline rather than a separate test case; add YUV encode/decode tests to the Java version of tjbenchtest git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1184 632fc199-4ca6-4c93-a231-07263d6284db
DRC 6e11d689 2014-03-17T10:19:42 Fix an error that occurred when trying to use the lossless transform feature without specifying -quiet; formatting tweak git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1182 632fc199-4ca6-4c93-a231-07263d6284db
DRC 2ae7918a 2014-03-17T10:14:18 Fix an error that occurred when trying to use the lossless transform feature without specifying -quiet; formatting tweak git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1181 632fc199-4ca6-4c93-a231-07263d6284db
DRC 4dafea68 2014-03-17T10:13:17 Move the garbage collection of the JPEG tiles into the decompression function to increase the chances that tiled decompression of large images will succeed without an OutOfMemoryError. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1180 632fc199-4ca6-4c93-a231-07263d6284db
DRC 88f260c7 2014-03-17T10:12:11 Move the garbage collection of the JPEG tiles into the decompression function to increase the chances that tiled decompression of large images will succeed without an OutOfMemoryError. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1179 632fc199-4ca6-4c93-a231-07263d6284db
DRC 6ffed933 2014-03-16T23:12:25 Generate the Java documentation using javadoc 7, to improve readability. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1178 632fc199-4ca6-4c93-a231-07263d6284db
DRC ee443719 2014-03-16T22:59:51 This should have been checked in with the previous commit. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1177 632fc199-4ca6-4c93-a231-07263d6284db
DRC fc26b657 2014-03-16T22:56:26 Extend the YUV decode functionality to the TurboJPEG Java API, and port the TJUnitTest modifications that treat YUV encoding/decoding as an intermediate step of the JPEG compression/decompression pipeline rather than a separate test case; Add the ability to encode YUV images from an arbitrary position in a large image buffer; Significantly refactor the handling of YUV images; numerous doc tweaks; other Java API cleanup and usability improvements git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1176 632fc199-4ca6-4c93-a231-07263d6284db
DRC 40a0a023 2014-03-16T19:33:23 Update (C) year git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1175 632fc199-4ca6-4c93-a231-07263d6284db
DRC 695b6e86 2014-03-16T19:33:07 Don't use deprecated constructor git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1174 632fc199-4ca6-4c93-a231-07263d6284db
kmx.io     mail     discord kmxgit v0.4.0