JDK-8274735, JPEG compression in a TIFF container, openjdk/jdk/pull/7849

[Philip Race]

Identifying the intended color space of a JPEG is so much guesswork ..

and we've not had support for ARGB since JDK 10 which was the last release
to contain the Sun/Oracle "closed" support for that (from Kodak!) and 
OpenJDK NEVER had it.

See
https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/imageio/metadata/doc-files/jpeg_metadata.html

Optional ColorSpace support: Handling of PhotoYCC (YCC), PhotoYCCA 
(YCCA), RGBA and YCbCrA color spaces by the standard plugin, as 
described below, is dependent on capabilities of the libraries used to 
interpret the JPEG data. Thus all consequential behaviors are optional. 
If the support is not available when decoding, the color space will be 
treated as unrecognized and the appropriate default color space for the 
specified number of component channels may be used

So if you have ARGB you are in the lap of the Gods ..

I think before the latest change there was no default 4 component space, 
so you got an exception,
now there's something we default to assuming we are seeing ..

-phil

On 5/20/22 7:07 AM, Brett Okken wrote:
> JPEG support for RGB with transparency/alpha channel is pretty spotty.
> https://stackoverflow.com/a/57626892/676877
>
> On Fri, May 20, 2022 at 8:12 AM Michal Karm <michal.babacek at gmail.com> 
> wrote:
>
>     I stepped the flow in a debugger and I narrowed
>     down the reproducer to a more focused, simpler
>     description and test data:
>
>     https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md
>
>     TL;DR:
>
>     JPEG compressed RGB image in TIFF with transparency makes
>     the TIFF decoder to push 4 components data to the JPEG reader.
>
>     The JPEG reader wrongly guesses that the data is CMYK now (based
>     on the number
>     of components).
>
>     If the image is GRAYSCALE though, it ends up in Unsupported Image Type
>     because JPEG reader doesn't try to guess it's CMYK.
>
>
>     Solution...I don't know.
>
>     Would it make sense if I transform the data to the number of
>     components the JPEG reader expects?
>     All the necessary information is there in the TIFF metadata,
>     e.g. it knows the space is RGB and not CMYK, it knows that there
>     is a transparency saved with the tile.
>
>     THX for hints
>
>     Karm
>
>
>     On 5/17/22 21:52, Philip Race wrote:
>     > This could be a bug in the TIFF plugin.
>     > Hard to say without debugging it.
>     >
>     > -phil.
>     >
>     >
>     > On 5/17/22 7:04 AM, Michal Karm wrote:
>     >> Hello,
>     >>
>     >> There used to be an Unsupported Image Type exception thrown
>     >> when one wanted to decode a TIFF container with JPEG compressed
>     image.
>     >>
>     >> That behavior has changed, there is no exception now, although the
>     >> resulting image is incorrect.
>     >>
>     >> I outlined the details in this doc [1], including a small
>     reproducer.
>     >>
>     >> The test image is not anything from a fuzzer, it's just me
>     >> clicking Export As in GIMP.
>     >>
>     >> Thanks for feedback
>     >>
>     >> Cheers
>     >> Karm
>     >>
>     >>
>     >> [1]
>     >>
>     https://urldefense.com/v3/__https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md__;!!ACWV5N9M2RV99hQ!Kw41ShsuTSfpVPMZFrXmdQ7ZETNdkLTk9Xd1NDWELvCXV0fyIqg4sXi5Z1aYfjMoG-5fS0gki8dnN8bQjSYM0g$
>
>     >>
>     >>
>     >> Karm Michal Babacek
>     >>
>     >
>
>
>     Michal Karm Babacek
>
>     -- 
>     Sent from my Hosaka Ono-Sendai Cyberspace 7
>