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