On Sat, 1 Mar 2025 17:58:44 GMT, Jeremy <d...@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
