kmx git

Commit	Date	Message
8d76e4e5	2024-08-31T15:33:55	Doc: "EXIF" = "Exif"
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.
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.)
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
96bc40c1	2023-01-26T13:11:58	Implement arithmetic coding with 12-bit precision This actually works and apparently always has worked. It only failed because the libjpeg code, which did not originally support arithmetic coding, assumed that optimize_coding should always be TRUE for 12-bit data precision.
fc01f467	2023-01-05T06:36:46	TurboJPEG 3 API overhaul (ChangeLog update forthcoming) - Prefix all function names with "tj3" and remove version suffixes from function names. (Future API overhauls will increment the prefix to "tj4", etc., thus retaining backward API/ABI compatibility without versioning each individual function.) - Replace stateless boolean flags (including TJFLAG_ARITHMETIC and TJFLAG_LOSSLESS, which were never released) with stateful integer parameters, the value of which persists between function calls. * Use parameters for the JPEG quality and subsampling as well, in order to eliminate the awkwardness of specifying function arguments that weren't relevant for lossless compression. * tj3DecompressHeader() now stores all relevant information about the JPEG image, including the width, height, subsampling type, entropy coding type, etc. in parameters rather than returning that information in its arguments. * TJFLAG_LIMITSCANS has been reimplemented as an integer parameter (TJPARAM_SCANLIMIT) that allows the number of scans to be specified. - Use the const keyword for all pointer arguments to unmodified buffers, as well as for both dimensions of 2D pointers. Addresses #395. - Use size_t rather than unsigned long to represent buffer sizes, since unsigned long is a 32-bit type on Windows. Addresses #24. - Return 0 from all buffer size functions if an error occurs, rather than awkwardly trying to return -1 in an unsigned data type. - Implement 12-bit and 16-bit data precision using dedicated compression, decompression, and image I/O functions/methods. * Suffix the names of all data-precision-specific functions with 8, 12, or 16. * Because the YUV functions are intended to be used for video, they are currently only implemented with 8-bit data precision, but they can be expanded to 12-bit data precision in the future, if necessary. * Extend TJUnitTest and TJBench to test 12-bit and 16-bit data precision, using a new -precision option. * Add appropriate regression tests for all of the above to the 'test' target. * Extend tjbenchtest to test 12-bit and 16-bit data precision, and add separate 'tjtest12' and 'tjtest16' targets. * BufferedImage I/O in the Java API is currently limited to 8-bit data precision, since the BufferedImage class does not straightforwardly support higher data precisions. * Extend the PPM reader to convert 12-bit and 16-bit PBMPLUS files to grayscale or CMYK pixels, as it already does for 8-bit files. - Properly accommodate lossless JPEG using dedicated parameters (TJPARAM_LOSSLESS, TJPARAM_LOSSLESSPSV, and TJPARAM_LOSSLESSPT), rather than using a flag and awkwardly repurposing the JPEG quality. Update TJBench to properly reflect whether a JPEG image is lossless. - Re-organize the TJBench usage screen. - Update the Java docs using Java 11, to improve the formatting and eliminate HTML frames. - Use the accurate integer DCT algorithm by default for both compression and decompression, since the "fast" algorithm is a legacy feature, it does not pass the ISO compliance tests, and it is not actually faster on modern x86 CPUs. Remove the -accuratedct option from TJBench and TJExample. - Re-implement the 'tjtest' target using a CMake script that enables the appropriate tests, depending on the data precision and whether or not the Java API is part of the build. - Consolidate the C and Java versions of tjbenchtest into one script. - Consolidate the C and Java versions of tjexampletest into one script. - Combine all initialization functions into a single function (tj3Init()) that accepts an integer parameter specifying the subsystems to initialize. - Enable decompression scaling explicitly, using a new function/method (tj3SetScalingFactor()/TJDecompressor.setScalingFactor()), rather than implicitly using awkward "desired width"/"desired height" parameters. - Introduce a new macro/constant (TJUNSCALED/TJ.UNSCALED) that maps to a scaling factor of 1/1. - Implement partial image decompression, using a new function/method (tj3SetCroppingRegion()/TJDecompressor.setCroppingRegion()) and TJBench option (-crop). Extend tjbenchtest to test the new feature. Addresses #1. - Allow the JPEG colorspace to be specified explicitly when compressing, using a new parameter (TJPARAM_COLORSPACE). This allows JPEG images with the RGB and CMYK colorspaces to be created. - Remove the error/difference image feature from TJBench. Identical images to the ones that TJBench created can be generated using ImageMagick with 'magick composite <original_image> <output_image> -compose difference <diff_image>' - Handle JPEG images with unknown subsampling types. TJPARAM_SUBSAMP is set to TJSAMP_UNKNOWN (== -1) for such images, but they can still be decompressed fully into packed-pixel images or losslessly transformed (with the exception of lossless cropping.) They cannot be partially decompressed or decompressed into planar YUV images. Note also that TJBench, due to its lack of support for imperfect transforms, requires that the subsampling type be known when rotating, flipping, or transversely transposing an image. Addresses #436 - The Java version of TJBench now has identical functionality to the C version. This was accomplished by (somewhat hackishly) calling the TurboJPEG C image I/O functions through JNI and copying the pixels between the C heap and the Java heap. - Add parameters (TJPARAM_RESTARTROWS and TJPARAM_RESTARTBLOCKS) and a TJBench option (-restart) to allow the restart marker interval to be specified when compressing. Eliminate the undocumented TJ_RESTART environment variable. - Add a parameter (TJPARAM_OPTIMIZE), a transform option (TJOPT_OPTIMIZE), and a TJBench option (-optimize) to allow optimized baseline Huffman coding to be specified when compressing. Eliminate the undocumented TJ_OPTIMIZE environment variable. - Add parameters (TJPARAM_XDENSITY, TJPARAM_DENSITY, and TJDENSITYUNITS) to allow the pixel density to be specified when compressing or saving a Windows BMP image and to be queried when decompressing or loading a Windows BMP image. Addresses #77. - Refactor the fuzz targets to use the new API. * Extend decompression coverage to 12-bit and 16-bit data precision. * Replace the awkward cjpeg12 and cjpeg16 targets with proper TurboJPEG-based compress12, compress12-lossless, and compress16-lossless targets - Fix innocuous UBSan warnings uncovered by the new fuzzers. - Implement previous versions of the TurboJPEG API by wrapping the new functions (tested by running the 2.1.x versions of TJBench, via tjbenchtest, and TJUnitTest against the new implementation.) * Remove all JNI functions for deprecated Java methods and implement the deprecated methods using pure Java wrappers. It should be understood that backward API compatibility in Java applies only to the Java classes and that one cannot mix and match a JAR file from one version of libjpeg-turbo with a JNI library from another version. - tj3Destroy() now silently accepts a NULL handle. - tj3Alloc() and tj3Free() now return/accept void pointers, as malloc() and free() do. - The image I/O functions now accept a TurboJPEG instance handle, which is used to transmit/receive parameters and to receive error information. Closes #517
7ab6222c	2023-01-20T14:09:25	Merge branch 'main' into dev
fb15efe9	2023-01-18T06:44:46	TurboJPEG: More documentation improvements - TJBench/TJUnitTest: Wordsmith command-line output - Java: "decompress operations"="decompression operations" - tjLoadImage(): Error message tweak - Don't mention compression performance in the description of TJXOPT_PROGRESSIVE/TJTransform.OPT_PROGRESSIVE, because the image has already been compressed at that point. (Oversights from 9a146f0f23b01869e1bf7c478e12b43f83d59c32)
d4589f4f	2023-01-14T18:07:53	Merge branch 'main' into dev
9a146f0f	2023-01-06T10:29:10	TurboJPEG: Numerous documentation improvements - Wordsmithing, formatting, and grammar tweaks - Various clarifications and corrections, including specifying whether a particular buffer or image is used as a source or destination - Accommodate/mention features that were introduced since the API documentation was created. - For clarity, use "packed-pixel" to describe uncompressed source/destination images that are not planar YUV. - Use "row" rather than "line" to refer to a single horizontal group of pixels or component values, for consistency with the libjpeg API documentation. (libjpeg also uses "scanline", which is a more archaic term.) - Use "alignment" rather than "padding" to refer to the number of bytes by which a row's width is evenly divisible. This consistifies the documention of the YUV functions and tjLoadImage(). ("Padding" typically refers to the number of bytes added to each row, which is not the same thing.) - Remove all references to "the underlying codec." Although the TurboJPEG API originated as a cross-platform wrapper for the Intel Integrated Performance Primitives, Sun mediaLib, QuickTime, and libjpeg, none of those TurboJPEG implementations has been maintained since 2009. Nothing would prevent someone from implementing the TurboJPEG API without libjpeg-turbo, but such an implementation would not necessarily have an "underlying codec." (It could be fully self-contained.) - Use "destination image" rather than "output image", for consistency, or describe the type of image that will be output. - Avoid the term "image buffer" and instead use "byte buffer" to refer to buffers that will hold JPEG images, or describe the type of image that will be contained in the buffer. (The Java documentation doesn't use "byte buffer", because the buffer arrays literally have "byte" in front of them, and since Java doesn't have pointers, it is not possible for mere mortals to store any other type of data in those arrays.) - C: Use "unified" to describe YUV images stored in a single buffer, for consistency with the Java documentation. - Use "planar YUV" rather than "YUV planar". Is is our convention to describe images using {component layout} {colorspace/pixel format} {image function}, e.g. "packed-pixel RGB source image" or "planar YUV destination image." - C: Document the TurboJPEG API version in which a particular function or macro was introduced, and reorder the backward compatibility function stubs in turbojpeg.h alphabetically by API version. - C: Use Markdown rather than HTML tags, where possible, in the Doxygen comments.
25ccad99	2022-11-16T15:57:25	TurboJPEG: 8-bit lossless JPEG support
6002720c	2022-11-15T23:10:35	TurboJPEG: Opt. enable arithmetic entropy coding
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)
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
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
67bee868	2013-04-27T12:36:07	Code formatting tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@968 632fc199-4ca6-4c93-a231-07263d6284db
65d4a46d	2013-04-27T01:06:52	Java doc tweaks git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@966 632fc199-4ca6-4c93-a231-07263d6284db
80803ae5	2011-12-15T13:12:59	"which"="that" git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@730 632fc199-4ca6-4c93-a231-07263d6284db
f5467110	2011-09-20T05:02:19	Implement custom filter callback in Java git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@707 632fc199-4ca6-4c93-a231-07263d6284db
86e51f22	2011-04-01T20:31:03	Fix compiler warning with OpenJDK git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@556 632fc199-4ca6-4c93-a231-07263d6284db
2c74e512	2011-03-16T00:02:53	More Java API cleanup git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@519 632fc199-4ca6-4c93-a231-07263d6284db
92549de2	2011-03-15T20:52:02	Java code cleanup + Java docs git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@518 632fc199-4ca6-4c93-a231-07263d6284db
6bd084af	2011-03-04T14:10:29	Oops. Forgot to add TJTransform class git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@509 632fc199-4ca6-4c93-a231-07263d6284db

8d76e4e5

2024-08-31T15:33:55

Doc: "EXIF" = "Exif"

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.

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.)

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

96bc40c1

2023-01-26T13:11:58

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

fc01f467

2023-01-05T06:36:46

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

7ab6222c

2023-01-20T14:09:25

Merge branch 'main' into dev

fb15efe9

2023-01-18T06:44:46

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

d4589f4f

2023-01-14T18:07:53

Merge branch 'main' into dev

9a146f0f

2023-01-06T10:29:10

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

25ccad99

2022-11-16T15:57:25

TurboJPEG: 8-bit lossless JPEG support

6002720c

2022-11-15T23:10:35

TurboJPEG: Opt. enable arithmetic entropy coding

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)

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

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

67bee868

2013-04-27T12:36:07

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

65d4a46d

2013-04-27T01:06:52

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

80803ae5

2011-12-15T13:12:59

"which"="that" git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@730 632fc199-4ca6-4c93-a231-07263d6284db

f5467110

2011-09-20T05:02:19

Implement custom filter callback in Java git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@707 632fc199-4ca6-4c93-a231-07263d6284db

86e51f22

2011-04-01T20:31:03

Fix compiler warning with OpenJDK git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@556 632fc199-4ca6-4c93-a231-07263d6284db

2c74e512

2011-03-16T00:02:53

More Java API cleanup git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@519 632fc199-4ca6-4c93-a231-07263d6284db

92549de2

2011-03-15T20:52:02

Java code cleanup + Java docs git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@518 632fc199-4ca6-4c93-a231-07263d6284db

6bd084af

2011-03-04T14:10:29

Oops. Forgot to add TJTransform class git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@509 632fc199-4ca6-4c93-a231-07263d6284db

kc3-lang/libjpeg-turbo/java/org/libjpegturbo/turbojpeg/TJTransform.java

java/org/libjpegturbo/turbojpeg/TJTransform.java

Log