ryan/mozjpeg
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Various doc tweaks

Browse Source 
- "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
This commit is contained in:
DRC
2024-08-14 09:21:54 -04:00
parent b4336c3afb
commit 0c23b0ad60
20 changed files with 1016 additions and 870 deletions
Download Patch File Download Diff File Expand all files Collapse all files

367
java/org/libjpegturbo/turbojpeg/TJ.java
View File

@@ -1,5 +1,5 @@
/*
* Copyright (C)2011-2013, 2017-2018, 2020-2023 D. R. Commander.
* Copyright (C)2011-2013, 2017-2018, 2020-2024 D. R. Commander.
* All Rights Reserved.
* Copyright (C)2015 Viktor Szathmáry. All Rights Reserved.
*
@@ -44,57 +44,72 @@ public final class TJ {
*/
public static final int NUMSAMP = 7;
/**
* 4:4:4 chrominance subsampling (no chrominance subsampling). The JPEG
* or YUV image will contain one chrominance component for every pixel in the
* source image.
* 4:4:4 chrominance subsampling (no chrominance subsampling)
*
* <p>The JPEG or YUV image will contain one chrominance component for every
* pixel in the source image.
*/
public static final int SAMP_444 = 0;
/**
* 4:2:2 chrominance subsampling. The JPEG or YUV image will contain one
* chrominance component for every 2x1 block of pixels in the source image.
* 4:2:2 chrominance subsampling
*
* <p>The JPEG or YUV image will contain one chrominance component for every
* 2x1 block of pixels in the source image.
*/
public static final int SAMP_422 = 1;
/**
* 4:2:0 chrominance subsampling. The JPEG or YUV image will contain one
* chrominance component for every 2x2 block of pixels in the source image.
* 4:2:0 chrominance subsampling
*
* <p>The JPEG or YUV image will contain one chrominance component for every
* 2x2 block of pixels in the source image.
*/
public static final int SAMP_420 = 2;
/**
* Grayscale. The JPEG or YUV image will contain no chrominance components.
* Grayscale
*
* <p>The JPEG or YUV image will contain no chrominance components.
*/
public static final int SAMP_GRAY = 3;
/**
* 4:4:0 chrominance subsampling. The JPEG or YUV image will contain one
* chrominance component for every 1x2 block of pixels in the source image.
* Note that 4:4:0 subsampling is not fully accelerated in libjpeg-turbo.
* 4:4:0 chrominance subsampling
*
* <p>The JPEG or YUV image will contain one chrominance component for every
* 1x2 block of pixels in the source image.
*
* <p>NOTE: 4:4:0 subsampling is not fully accelerated in libjpeg-turbo.
*/
public static final int SAMP_440 = 4;
/**
* 4:1:1 chrominance subsampling. The JPEG or YUV image will contain one
* chrominance component for every 4x1 block of pixels in the source image.
* JPEG images compressed with 4:1:1 subsampling will be almost exactly the
* same size as those compressed with 4:2:0 subsampling, and in the
* aggregate, both subsampling methods produce approximately the same
* perceptual quality. However, 4:1:1 is better able to reproduce sharp
* horizontal features. Note that 4:1:1 subsampling is not fully accelerated
* in libjpeg-turbo.
* 4:1:1 chrominance subsampling
*
* <p>The JPEG or YUV image will contain one chrominance component for every
* 4x1 block of pixels in the source image. All else being equal, a JPEG
* image with 4:1:1 subsampling is almost exactly the same size as a JPEG
* image with 4:2:0 subsampling, and in the aggregate, both subsampling
* methods produce approximately the same perceptual quality. However, 4:1:1
* is better able to reproduce sharp horizontal features.
*
* <p>NOTE: 4:1:1 subsampling is not fully accelerated in libjpeg-turbo.
*/
public static final int SAMP_411 = 5;
/**
* 4:4:1 chrominance subsampling. The JPEG or YUV image will contain one
* chrominance component for every 1x4 block of pixels in the source image.
* JPEG images compressed with 4:4:1 subsampling will be almost exactly the
* same size as those compressed with 4:2:0 subsampling, and in the
* aggregate, both subsampling methods produce approximately the same
* perceptual quality. However, 4:4:1 is better able to reproduce sharp
* vertical features. Note that 4:4:1 subsampling is not fully accelerated
* in libjpeg-turbo.
* 4:4:1 chrominance subsampling
*
* <p>The JPEG or YUV image will contain one chrominance component for every
* 1x4 block of pixels in the source image. All else being equal, a JPEG
* image with 4:4:1 subsampling is almost exactly the same size as a JPEG
* image with 4:2:0 subsampling, and in the aggregate, both subsampling
* methods produce approximately the same perceptual quality. However, 4:4:1
* is better able to reproduce sharp vertical features.
*
* <p>NOTE: 4:4:1 subsampling is not fully accelerated in libjpeg-turbo.
*/
public static final int SAMP_441 = 6;
/**
* Unknown subsampling. The JPEG image uses an unusual type of chrominance
* subsampling. Such images can be decompressed into packed-pixel images,
* but they cannot be
* Unknown subsampling
*
* <p>The JPEG image uses an unusual type of chrominance subsampling. Such
* images can be decompressed into packed-pixel images, but they cannot be
* <ul>
* <li> decompressed into planar YUV images,
* <li> losslessly transformed if {@link TJTransform#OPT_CROP} is specified,
@@ -149,89 +164,113 @@ public final class TJ {
*/
public static final int NUMPF = 12;
/**
* RGB pixel format. The red, green, and blue components in the image are
* stored in 3-sample pixels in the order R, G, B from lowest to highest
* memory address within each pixel.
* RGB pixel format
*
* <p>The red, green, and blue components in the image are stored in 3-sample
* pixels in the order R, G, B from lowest to highest memory address within
* each pixel.
*/
public static final int PF_RGB = 0;
/**
* BGR pixel format. The red, green, and blue components in the image are
* stored in 3-sample pixels in the order B, G, R from lowest to highest
* memory address within each pixel.
* BGR pixel format
*
* <p>The red, green, and blue components in the image are stored in 3-sample
* pixels in the order B, G, R from lowest to highest memory address within
* each pixel.
*/
public static final int PF_BGR = 1;
/**
* RGBX pixel format. The red, green, and blue components in the image are
* stored in 4-sample pixels in the order R, G, B from lowest to highest
* memory address within each pixel. The X component is ignored when
* compressing and undefined when decompressing.
* RGBX pixel format
*
* <p>The red, green, and blue components in the image are stored in 4-sample
* pixels in the order R, G, B from lowest to highest memory address within
* each pixel. The X component is ignored when compressing/encoding and
* undefined when decompressing/decoding.
*/
public static final int PF_RGBX = 2;
/**
* BGRX pixel format. The red, green, and blue components in the image are
* stored in 4-sample pixels in the order B, G, R from lowest to highest
* memory address within each pixel. The X component is ignored when
* compressing and undefined when decompressing.
* BGRX pixel format
*
* <p>The red, green, and blue components in the image are stored in 4-sample
* pixels in the order B, G, R from lowest to highest memory address within
* each pixel. The X component is ignored when compressing/encoding and
* undefined when decompressing/decoding.
*/
public static final int PF_BGRX = 3;
/**
* XBGR pixel format. The red, green, and blue components in the image are
* stored in 4-sample pixels in the order R, G, B from highest to lowest
* memory address within each pixel. The X component is ignored when
* compressing and undefined when decompressing.
* XBGR pixel format
*
* <p>The red, green, and blue components in the image are stored in 4-sample
* pixels in the order R, G, B from highest to lowest memory address within
* each pixel. The X component is ignored when compressing/encoding and
* undefined when decompressing/decoding.
*/
public static final int PF_XBGR = 4;
/**
* XRGB pixel format. The red, green, and blue components in the image are
* stored in 4-sample pixels in the order B, G, R from highest to lowest
* memory address within each pixel. The X component is ignored when
* compressing and undefined when decompressing.
* XRGB pixel format
*
* <p>The red, green, and blue components in the image are stored in 4-sample
* pixels in the order B, G, R from highest to lowest memory address within
* each pixel. The X component is ignored when compressing/encoding and
* undefined when decompressing/decoding.
*/
public static final int PF_XRGB = 5;
/**
* Grayscale pixel format. Each 1-sample pixel represents a luminance
* (brightness) level from 0 to the maximum sample value (255 for 8-bit
* samples, 4095 for 12-bit samples, and 65535 for 16-bit samples.)
* Grayscale pixel format
*
* <p>Each 1-sample pixel represents a luminance (brightness) level from 0 to
* the maximum sample value (255 for 8-bit samples, 4095 for 12-bit samples,
* and 65535 for 16-bit samples.)
*/
public static final int PF_GRAY = 6;
/**
* RGBA pixel format. This is the same as {@link #PF_RGBX}, except that when
* decompressing, the X component is guaranteed to be equal to the maximum
* sample value, which can be interpreted as an opaque alpha channel.
* RGBA pixel format
*
* <p>This is the same as {@link #PF_RGBX}, except that when
* decompressing/decoding, the X component is guaranteed to be equal to the
* maximum sample value, which can be interpreted as an opaque alpha channel.
*/
public static final int PF_RGBA = 7;
/**
* BGRA pixel format. This is the same as {@link #PF_BGRX}, except that when
* decompressing, the X component is guaranteed to be equal to the maximum
* sample value, which can be interpreted as an opaque alpha channel.
* BGRA pixel format
*
* <p>This is the same as {@link #PF_BGRX}, except that when
* decompressing/decoding, the X component is guaranteed to be equal to the
* maximum sample value, which can be interpreted as an opaque alpha channel.
*/
public static final int PF_BGRA = 8;
/**
* ABGR pixel format. This is the same as {@link #PF_XBGR}, except that when
* decompressing, the X component is guaranteed to be equal to the maximum
* sample value, which can be interpreted as an opaque alpha channel.
* ABGR pixel format
*
* <p>This is the same as {@link #PF_XBGR}, except that when
* decompressing/decoding, the X component is guaranteed to be equal to the
* maximum sample value, which can be interpreted as an opaque alpha channel.
*/
public static final int PF_ABGR = 9;
/**
* ARGB pixel format. This is the same as {@link #PF_XRGB}, except that when
* decompressing, the X component is guaranteed to be equal to the maximum
* sample value, which can be interpreted as an opaque alpha channel.
* ARGB pixel format
*
* <p>This is the same as {@link #PF_XRGB}, except that when
* decompressing/decoding, the X component is guaranteed to be equal to the
* maximum sample value, which can be interpreted as an opaque alpha channel.
*/
public static final int PF_ARGB = 10;
/**
* CMYK pixel format. Unlike RGB, which is an additive color model used
* primarily for display, CMYK (Cyan/Magenta/Yellow/Key) is a subtractive
* color model used primarily for printing. In the CMYK color model, the
* value of each color component typically corresponds to an amount of cyan,
* magenta, yellow, or black ink that is applied to a white background. In
* order to convert between CMYK and RGB, it is necessary to use a color
* management system (CMS.) A CMS will attempt to map colors within the
* printer's gamut to perceptually similar colors in the display's gamut and
* vice versa, but the mapping is typically not 1:1 or reversible, nor can it
* be defined with a simple formula. Thus, such a conversion is out of scope
* for a codec library. However, the TurboJPEG API allows for compressing
* packed-pixel CMYK images into YCCK JPEG images (see {@link #CS_YCCK}) and
* decompressing YCCK JPEG images into packed-pixel CMYK images.
* CMYK pixel format
*
* <p>Unlike RGB, which is an additive color model used primarily for
* display, CMYK (Cyan/Magenta/Yellow/Key) is a subtractive color model used
* primarily for printing. In the CMYK color model, the value of each color
* component typically corresponds to an amount of cyan, magenta, yellow, or
* black ink that is applied to a white background. In order to convert
* between CMYK and RGB, it is necessary to use a color management system
* (CMS.) A CMS will attempt to map colors within the printer's gamut to
* perceptually similar colors in the display's gamut and vice versa, but the
* mapping is typically not 1:1 or reversible, nor can it be defined with a
* simple formula. Thus, such a conversion is out of scope for a codec
* library. However, the TurboJPEG API allows for compressing packed-pixel
* CMYK images into YCCK JPEG images (see {@link #CS_YCCK}) and decompressing
* YCCK JPEG images into packed-pixel CMYK images.
*/
public static final int PF_CMYK = 11;
@@ -257,7 +296,7 @@ public final class TJ {
* For the given pixel format, returns the number of samples that the red
* component is offset from the start of the pixel. For instance, if an
* 8-bit-per-sample pixel of format <code>TJ.PF_BGRX</code> is stored in
* <code>char pixel[]</code>, then the red component will be
* <code>char pixel[]</code>, then the red component is
* <code>pixel[TJ.getRedOffset(TJ.PF_BGRX)]</code>.
*
* @param pixelFormat the pixel format (one of {@link #PF_RGB PF_*})
@@ -279,7 +318,7 @@ public final class TJ {
* For the given pixel format, returns the number of samples that the green
* component is offset from the start of the pixel. For instance, if an
* 8-bit-per-sample pixel of format <code>TJ.PF_BGRX</code> is stored in
* <code>char pixel[]</code>, then the green component will be
* <code>char pixel[]</code>, then the green component is
* <code>pixel[TJ.getGreenOffset(TJ.PF_BGRX)]</code>.
*
* @param pixelFormat the pixel format (one of {@link #PF_RGB PF_*})
@@ -301,7 +340,7 @@ public final class TJ {
* For the given pixel format, returns the number of samples that the blue
* component is offset from the start of the pixel. For instance, if an
* 8-bit-per-sample pixel of format <code>TJ.PF_BGRX</code> is stored in
* <code>char pixel[]</code>, then the blue component will be
* <code>char pixel[]</code>, then the blue component is
* <code>pixel[TJ.getBlueOffset(TJ.PF_BGRX)]</code>.
*
* @param pixelFormat the pixel format (one of {@link #PF_RGB PF_*})
@@ -323,7 +362,7 @@ public final class TJ {
* For the given pixel format, returns the number of samples that the alpha
* component is offset from the start of the pixel. For instance, if an
* 8-bit-per-sample pixel of format <code>TJ.PF_BGRA</code> is stored in
* <code>char pixel[]</code>, then the alpha component will be
* <code>char pixel[]</code>, then the alpha component is
* <code>pixel[TJ.getAlphaOffset(TJ.PF_BGRA)]</code>.
*
* @param pixelFormat the pixel format (one of {@link #PF_RGB PF_*})
@@ -346,57 +385,64 @@ public final class TJ {
*/
public static final int NUMCS = 5;
/**
* RGB colorspace. When compressing the JPEG image, the R, G, and B
* components in the source image are reordered into image planes, but no
* colorspace conversion or subsampling is performed. RGB JPEG images can be
* compressed from and decompressed to packed-pixel images with any of the
* extended RGB or grayscale pixel formats, but they cannot be compressed
* from or decompressed to planar YUV images.
* RGB colorspace
*
* <p>When generating the JPEG image, the R, G, and B components in the
* source image are reordered into image planes, but no colorspace conversion
* or subsampling is performed. RGB JPEG images can be generated from and
* decompressed to packed-pixel images with any of the extended RGB or
* grayscale pixel formats, but they cannot be generated from or
* decompressed to planar YUV images.
*/
public static final int CS_RGB = 0;
/**
* YCbCr colorspace. YCbCr is not an absolute colorspace but rather a
* mathematical transformation of RGB designed solely for storage and
* transmission. YCbCr images must be converted to RGB before they can
* actually be displayed. In the YCbCr colorspace, the Y (luminance)
* component represents the black &amp; white portion of the original image,
* and the Cb and Cr (chrominance) components represent the color portion of
* the original image. Originally, the analog equivalent of this
* transformation allowed the same signal to drive both black &amp; white and
* color televisions, but JPEG images use YCbCr primarily because it allows
* the color data to be optionally subsampled for the purposes of reducing
* network or disk usage. YCbCr is the most common JPEG colorspace, and
* YCbCr JPEG images can be compressed from and decompressed to packed-pixel
* images with any of the extended RGB or grayscale pixel formats. YCbCr
* JPEG images can also be compressed from and decompressed to planar YUV
* images.
* YCbCr colorspace
*
* <p>YCbCr is not an absolute colorspace but rather a mathematical
* transformation of RGB designed solely for storage and transmission. YCbCr
* images must be converted to RGB before they can be displayed. In the
* YCbCr colorspace, the Y (luminance) component represents the black &amp;
* white portion of the original image, and the Cb and Cr (chrominance)
* components represent the color portion of the original image.
* Historically, the analog equivalent of this transformation allowed the
* same signal to be displayed to both black &amp; white and color
* televisions, but JPEG images use YCbCr primarily because it allows the
* color data to be optionally subsampled in order to reduce network and disk
* usage. YCbCr is the most common JPEG colorspace, and YCbCr JPEG images
* can be generated from and decompressed to packed-pixel images with any of
* the extended RGB or grayscale pixel formats. YCbCr JPEG images can also
* be generated from and decompressed to planar YUV images.
*/
@SuppressWarnings("checkstyle:ConstantName")
public static final int CS_YCbCr = 1;
/**
* Grayscale colorspace. The JPEG image retains only the luminance data (Y
* component), and any color data from the source image is discarded.
* Grayscale JPEG images can be compressed from and decompressed to
* packed-pixel images with any of the extended RGB or grayscale pixel
* formats, or they can be compressed from and decompressed to planar YUV
* images.
* Grayscale colorspace
*
* <p>The JPEG image retains only the luminance data (Y component), and any
* color data from the source image is discarded. Grayscale JPEG images can
* be generated from and decompressed to packed-pixel images with any of the
* extended RGB or grayscale pixel formats, or they can be generated from and
* decompressed to planar YUV images.
*/
public static final int CS_GRAY = 2;
/**
* CMYK colorspace. When compressing the JPEG image, the C, M, Y, and K
* components in the source image are reordered into image planes, but no
* colorspace conversion or subsampling is performed. CMYK JPEG images can
* only be compressed from and decompressed to packed-pixel images with the
* CMYK pixel format.
* CMYK colorspace
*
* <p>When generating the JPEG image, the C, M, Y, and K components in the
* source image are reordered into image planes, but no colorspace conversion
* or subsampling is performed. CMYK JPEG images can only be generated from
* and decompressed to packed-pixel images with the CMYK pixel format.
*/
public static final int CS_CMYK = 3;
/**
* YCCK colorspace. YCCK (AKA "YCbCrK") is not an absolute colorspace but
* rather a mathematical transformation of CMYK designed solely for storage
* and transmission. It is to CMYK as YCbCr is to RGB. CMYK pixels can be
* YCCK colorspace
*
* <p>YCCK (AKA "YCbCrK") is not an absolute colorspace but rather a
* mathematical transformation of CMYK designed solely for storage and
* transmission. It is to CMYK as YCbCr is to RGB. CMYK pixels can be
* reversibly transformed into YCCK, and as with YCbCr, the chrominance
* components in the YCCK pixels can be subsampled without incurring major
* perceptual loss. YCCK JPEG images can only be compressed from and
* perceptual loss. YCCK JPEG images can only be generated from and
* decompressed to packed-pixel images with the CMYK pixel format.
*/
public static final int CS_YCCK = 4;
@@ -447,7 +493,7 @@ public final class TJ {
* from CMYK to YCCK (see {@link #CS_YCCK}) as part of the JPEG compression
* process, some of the Cb and Cr (chrominance) components can be discarded
* or averaged together to produce a smaller image with little perceptible
* loss of image clarity. (The human eye is more sensitive to small changes
* loss of image quality. (The human eye is more sensitive to small changes
* in brightness than to small changes in color.) This is called
* "chrominance subsampling".
*
@@ -500,7 +546,7 @@ public final class TJ {
* <p><b>Value</b>
* <ul>
* <li> <code>0</code> <i>[default]</i> Use smooth upsampling when
* decompressing a JPEG image that was compressed using chrominance
* decompressing a JPEG image that was generated using chrominance
* subsampling. This creates a smooth transition between neighboring
* chrominance components in order to reduce upsampling artifacts in the
* decompressed image.
@@ -532,14 +578,13 @@ public final class TJ {
* <li> The difference in accuracy between the "fast" and "accurate"
* algorithms is the most pronounced at JPEG quality levels above 90 and
* tends to be more pronounced with decompression than with compression.
* <li> The "fast" algorithm degrades and is not fully accelerated for JPEG
* quality levels above 97, so it will be slower than the "accurate"
* algorithm.
* <li> For JPEG quality levels above 97, the "fast" algorithm degrades and
* is not fully accelerated, so it is slower than the "accurate" algorithm.
* </ul>
*/
public static final int PARAM_FASTDCT = 10;
/**
* Optimized baseline entropy coding [lossy compression only]
* Huffman table optimization [lossy compression, lossless transformation]
*
* <p><b>Value</b>
* <ul>
@@ -550,37 +595,46 @@ public final class TJ {
* {@link TJTransform#OPT_OPTIMIZE}.
* </ul>
*
* <p>Optimized baseline entropy coding will improve compression slightly
* (generally 5% or less), but it will reduce compression performance
* considerably.
* <p>Huffman table optimization improves compression slightly (generally 5%
* or less), but it reduces compression performance considerably.
*/
public static final int PARAM_OPTIMIZE = 11;
/**
* Progressive entropy coding
* Progressive JPEG
*
* <p>In a progressive JPEG image, the DCT coefficients are split across
* multiple "scans" of increasing quality. Thus, a low-quality scan
* containing the lowest-frequency DCT coefficients can be transmitted first
* and refined with subsequent higher-quality scans containing
* higher-frequency DCT coefficients. When using Huffman entropy coding, the
* progressive JPEG format also provides an "end-of-bands (EOB) run" feature
* that allows large groups of zeroes, potentially spanning multiple MCU
* blocks, to be represented using only a few bytes.
*
* <p><b>Value</b>
* <ul>
* <li> <code>0</code> <i>[default for compression, lossless
* transformation]</i> The lossy JPEG image uses (decompression) or will use
* (compression, lossless transformation) baseline entropy coding.
* <li> <code>1</code> The lossy JPEG image uses (decompression) or will use
* (compression, lossless transformation) progressive entropy coding. For
* lossless transformation, this can also be specified using
* transformation]</i> The lossy JPEG image is (decompression) or will be
* (compression, lossless transformation) single-scan.
* <li> <code>1</code> The lossy JPEG image is (decompression) or will be
* (compression, lossless transformation) progressive. For lossless
* transformation, this can also be specified using
* {@link TJTransform#OPT_PROGRESSIVE}.
* </ul>
*
* <p>Progressive entropy coding will generally improve compression relative
* to baseline entropy coding, but it will reduce compression and
* decompression performance considerably. Can be combined with
* {@link #PARAM_ARITHMETIC}. Implies {@link #PARAM_OPTIMIZE} unless
* {@link #PARAM_ARITHMETIC} is also set.
* <p>Progressive JPEG images generally have better compression ratios than
* single-scan JPEG images (much better if the image has large areas of solid
* color), but progressive JPEG compression and decompression is considerably
* slower than single-scan JPEG compression and decompression. Can be
* combined with {@link #PARAM_ARITHMETIC}. Implies {@link #PARAM_OPTIMIZE}
* unless {@link #PARAM_ARITHMETIC} is also set.
*/
public static final int PARAM_PROGRESSIVE = 12;
/**
* Progressive JPEG scan limit for lossy JPEG images [decompression, lossless
* transformation]
*
* <p>Setting this parameter will cause the decompression and transform
* <p>Setting this parameter causes the decompression and transform
* operations to throw an error if the number of scans in a progressive JPEG
* image exceeds the specified limit. The primary purpose of this is to
* allow security-critical applications to guard against an exploit of the
@@ -611,9 +665,9 @@ public final class TJ {
* {@link TJTransform#OPT_ARITHMETIC}.
* </ul>
*
* <p>Arithmetic entropy coding will generally improve compression relative
* to Huffman entropy coding, but it will reduce compression and
* decompression performance considerably. Can be combined with
* <p>Arithmetic entropy coding generally improves compression relative to
* Huffman entropy coding, but it reduces compression and decompression
* performance considerably. Can be combined with
* {@link #PARAM_PROGRESSIVE}.
*/
public static final int PARAM_ARITHMETIC = 14;
@@ -628,9 +682,9 @@ public final class TJ {
* (compression) lossless/predictive.
* </ul>
*
* <p>In most cases, compressing and decompressing lossless JPEG images is
* considerably slower than compressing and decompressing lossy JPEG images,
* and lossless JPEG images are much larger than lossy JPEG images. Thus,
* <p>In most cases, lossless JPEG compression and decompression is
* considerably slower than lossy JPEG compression and decompression, and
* lossless JPEG images are much larger than lossy JPEG images. Thus,
* lossless JPEG images are typically used only for applications that require
* mathematically lossless compression. Also note that the following
* features are not available with lossless JPEG images:
@@ -642,7 +696,7 @@ public final class TJ {
* {@link #SAMP_444})
* <li> JPEG quality selection
* <li> DCT/IDCT algorithm selection
* <li> Progressive entropy coding
* <li> Progressive JPEG
* <li> Arithmetic entropy coding
* <li> Compression from/decompression to planar YUV images
* <li> Decompression scaling
@@ -809,16 +863,15 @@ public final class TJ {
* <ul>
* <li> the maximum amount of memory (in megabytes) that will be allocated
* for intermediate buffers, which are used with progressive JPEG compression
* and decompression, optimized baseline entropy coding, lossless JPEG
* compression, and lossless transformation <i>[default: <code>0</code> (no
* limit)]</i>
* and decompression, Huffman table optimization, lossless JPEG compression,
* and lossless transformation <i>[default: <code>0</code> (no limit)]</i>
* </ul>
*/
public static final int PARAM_MAXMEMORY = 23;
/**
* Image size limit [decompression, lossless transformation]
*
* <p>Setting this parameter will cause the decompression and transform
* <p>Setting this parameter causes the decompression and transform
* operations to throw an error if the number of pixels in the JPEG source
* image exceeds the specified limit. This allows security-critical
* applications to guard against excessive memory consumption.
@@ -876,8 +929,8 @@ public final class TJ {
/**
* The error was non-fatal and recoverable, but the destination image may
* still be corrupt.
* <p>
* NOTE: due to the design of the TurboJPEG Java API, only certain methods
*
* <p>NOTE: Due to the design of the TurboJPEG Java API, only certain methods
* (specifically, {@link TJDecompressor TJDecompressor.decompress*()} methods
* with a void return type) will complete and leave the destination image in
* a fully recoverable state after a non-fatal error occurs.
@@ -940,12 +993,12 @@ public final class TJ {
* @param componentID ID number of the image plane (0 = Y, 1 = U/Cb,
* 2 = V/Cr)
*
* @param width width (in pixels) of the YUV image. NOTE: this is the width
* @param width width (in pixels) of the YUV image. NOTE: This is the width
* of the whole image, not the plane width.
*
* @param stride bytes per row in the image plane.
*
* @param height height (in pixels) of the YUV image. NOTE: this is the
* @param height height (in pixels) of the YUV image. NOTE: This is the
* height of the whole image, not the plane height.
*
* @param subsamp the level of chrominance subsampling used in the YUV