On Mon, 3 Mar 2025 18:52:45 GMT, Brian Burkhalter <b...@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
