Note that this changes the behavior of tj3GetICCProfile() in the
following ways:
- It can now be called with a compression instance, thus allowing the
caller to retrieve an ICC profile (or the size thereof) extracted from
a PNG image by tj3LoadImage*().
- The ICC profile extracted from a JPEG image can now be retrieved
multiple times. If I recall, I didn't allow this in TurboJPEG 3.1
because there were already two buffer copies, one in
jpeg_read_icc_profile() and another in the JNI wrapper. That is no
longer relevant, since the TurboJPEG Java API is now a separate
project.
These changes should be backward-compatible. Applications that treat
tj3GetICCProfile() as a mailbox rather than a newsstand will still work.
The changes were necessary in order to:
- allow decompression programs to both extract the ICC profile from a
JPEG image and embed it into a PNG output image, and
- allow compression programs to retrieve the ICC profile size from a PNG
input image (which is important when computing the worst-case JPEG
destination buffer size.)
Closes#645
This is just a code readability thing. The logic effectively caused the
data precision to default to 8 if -precision was not specified, but that
was not obvious.
This commit also modifies tjcomptest so that it tests TJComp with no
-precision argument, to ensure that the data precision defaults to 8.
-copynone --> -copy none
Add '-copy all', even though it's the default.
-rgb, -bgr, -rgbx, -bgrx, -xbgr, -xrgb, -gray, -cmyk -->
-pixelformat {rgb|bgr|rgbx|bgrx|xbgr|xrgb|gray|cmyk}
(This is mainly so -gray won't interfere with -grayscale.)
Fix an ArrayIndexOutOfBoundsException that occurred when passing -dct
to the Java version without specifying the DCT algorithm (oversight from
24fbf64d31a0758c63bcc27cf5d92fc5611717d0.)
