On Wed, 26 Feb 2025 09:23:47 GMT, Jeremy <d...@openjdk.org> wrote: >> This adds support for parsing thumbnails in an APP1 Exif marker. >> >> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In >> that previous work the only additional meta info he parsed was the image >> creation time; this PR similarly includes the same property. (I can't speak >> to why he included that property, but it looks like he has a lot of >> experience with ImageIO so I trust his judgment.) >> >> ~~The test addresses the original images attached to the ticket plus a few >> extra images I found on my computer that include unusual properties. >> (Possibly those images are malformed, but if they exist in the wild and >> other platforms support them then I'd prefer to support them too.)~~ >> >> The images used in this test are contributed by Brian and me. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1976464426
