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
