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

[Jeremy]

On Sat, 1 Mar 2025 17:46:10 GMT, Harald Kuhr <duke at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8160327: trying to placate PR script
>>   
>>   The github script still classifies two of the sample jpgs as executable files, which it classifies as errors.
>
> 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.)

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

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