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

[Michal Karm]

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