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

[Brian Burkhalter]

On Sat, 1 Mar 2025 17:58:44 GMT, Jeremy <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java line 182:
>> 
>>> 180:                 // file shows it can also sometimes be 0x60000. I've also observed it to be
>>> 181:                 // undefined, 0x0007, or several variations of 0x????0006. Similarly the same
>>> 182:                 // tag should be 0x0001 for TIFFs, but I also observed a case where it as 0x10000.
>> 
>> Isn't this ( 0x0001/0x0006 vs 0x1000/0x6000) just a matter of endianness in the TIFF structure? Some odd writers may also use LONG/32 bit values, even though the TiFF and Exif specs only mention SHORT/16 bit values for the compression tag. 
>> 
>> 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.
>
> 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.

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

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