On Sat, 1 Mar 2025 17:46:10 GMT, Harald Kuhr <d...@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
