RFR: 8160327: Support for thumbnails present in APP1 marker for JPEG [v7]

[Brian Burkhalter]

On Mon, 3 Mar 2025 18:52:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Yes, it probably is endianness, or endianness-related. My first design question is: should we care? Currently this PR infers whether we're looking for a JPEG or TIFF thumbnail based on other fields. If we strictly rely on the compression tag (250) instead: is that better/desirable? (That is: we could just throw an IOException in the rare case this field is missing/broken.)
>
>> Compression 7 "New JPEG" is not as per the Exif spec, but it can probably safely be treated the same way as "Old JPEG" compression 6 for Exif thumbnails.
> 
> Probably the `Compression` tag should not be relied upon. While the Exif specification strangely states that for compressed thumbnails its value should be 6, there is no harm in its being 7.

> Currently this PR infers whether we're looking for a JPEG or TIFF thumbnail based on other fields.

Specifically the `JPEGInterchangeFormat` and `JPEGInterchangeFormatLength` fields. In the Exif 3.0 specification these have support level _mandatory_ for compressed thumbnails and _disallowed_ for uncompressed thumbnails.

> If we strictly rely on the compression tag (250) instead: is that better/desirable?

I don't think so.

> (That is: we could just throw an IOException in the rare case this field is missing/broken.)

This will indeed happen if `JPEGInterchangeFormat` does not point to a valid JPEG stream (SOI marker).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1978025262