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

[Michal Karm]

Thanks for taking the time to explain it.

Inline...

On 5/20/22 19:50, Philip Race wrote:
> 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 ..
> 

thx, I digested the content and I think I get it.

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

That is exactly the case. I would like a meaningful exception to be thrown
so as one knows that the data are being interpreted incorrectly though.

Something along these lines (tests included):

https://github.com/openjdk/jdk/pull/8846

Why in TIFF reader and not in JPEG decompressor: Both GIMP and ImageMagic can
create RGBA JPEG compressed TIFF without any warning for you, while producing
RGBA JPEG with these common tools is something I didn't encounter.


Cheers
Karm

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


Michal Karm Babacek

-- 
Sent from my Hosaka Ono-Sendai Cyberspace 7