I like this proposal quite a bit.
- It seems to eliminate any and all web compatibility concerns.
- The belt-and-suspenders approach ensures that the encoder that set this metadata knew what it was doing, and if image content “drifts” away from the metadata, the metadata is ignored.
- It allows for pixel-perfect precision (unlike the original Content-DPR proposal).
- The overhead is relatively tiny (very-small images like image placeholders are an important use case).
- It doesn’t invent anything new, or do anything that goes against either the letter or spirit of the EXIF spec.
The only downside I can think of is:
- It’s a little secret-decoder-ring-ish. You have to set two dials just so, in a way that is not intuitive from looking at the EXIF alone.
One tweak – I think it might make sense to require all four of
Let’s say we have an 800×800 image with
PixelXDimension=400. So, density-corrected intrinsic size = 400x400. So far, so good.
Then, let’s say someone crops it to 800×600, and does not update the metadata. Density-corrected intrinsic size = 400×300, I’m okay with this.
But, let’s say they instead cropped it to 600×800, without updating the metadata. Now the
XResolution are out-of-sync with the actual image dimensions, so the metadata is ignored and the density-corrected intrinsic size becomes 600×800. The differing results when cropping horizontally or vertically seem weird.
I think this all would be somewhat less befuddling if any image editor that changed the dimensions of the image, but did not change the metadata in concert, triggered the metadata to be ignored. The cost is a few dozen extra bytes in every resource … but perhaps worth it.