Yes, exactly - since Inch stands for DPI, it would make sense that Pixel would stand for dppx. I believe there is no current use for Pixel as an EXIF Resolution Unit.
Yes. I tend to like the second one because it doesn’t have float rounding issues; However the first one might introduce fewer backward compatibility issues (maybe non at all). A study of current existence of EXIF in web-exposed image is probably a good next step
Continuing my research, I’m thinking that adding an XMP attribute might work better than EXIF… EXIF is less extensible and is more photography-oriented, also the mentioned EXIF attributes are used by image viewers.
ImageWidth/ImageHeight: usually refer to the original size of the image when it was taken, before it was scaled by any program. Many photos on the web have different ImageWidth/ImageHeight values from their actual pixel dimensions.
XResolution/YResolution/ResolutionUnit: used almost exclusively for DPI, as a printing directive,. The default is 72dpi. The different resolution units are defined in the EXIF standard.
PixelXDimension/PixelYDimension: intended for a different use, padding of compressed image data.
Use ImageWidth / ImageHeight EXIF to override intrinsic dimensions
These attributes are quite common in the wild, and are often different from the image pixel dimensions. That’s because they don’t change when a program changes the image. See explanation.
Using them to compute intrinsic dimension as an override of the pixel data dimensions would make a lot of sense, but is also likely to modify the presentation of a small amount of existing images on the web.
Use ImageResolution EXIF with Pixel as ResolutionUnit
This maybe makes the most sense spec-wise, and would not break any existing web site, but would require a revision to the Exif standard, as the different values for ResolutionUnit are defined in that spec.
Use ImageResolution EXIF with Inch as ResolutionUnit, and treat 72dpi as 1dppx
This would not require any spec change, as Inch is already a defined ImageResolution value. However, it would change intrinsic size for some images currently on the web, where the dpi is defined with a value other than 72. That is not uncommon in the web today.
Use ImageResolution or ImageWidth/Height EXIF, with CSS image-resolution
Either (1) or (3) can work without “breaking the web”, by allowing it as a non-default value for image-resolution CSS attribute.
Add a new EXIF attribute
Maybe PreferredPixelDensity or DisplayWidth/DisplayHeight. Will require changing the EXIF spec, but would not introduce any backwards compatibility issues.
This can be done without too much standardization overhead, as it can be done in an XMP namespace. However, it would require user agents to incur the overhead of parsing inline XMP in image data, which they currently ignore.
Created a crawler that goes to many websites (starting the crawl from here, downloads the images, and parses their EXIF. The source code for it is here.
Ran the crawler on my computer, capped at 3000. The results are here.
Out of 3000 images sampled, 189 have any EXIF info (6.3%).
Out of those 189 images, 55 (29%) are displayed with their natural width & height.
Out of those 55 images, 10 (18%) have a resolution other than 72dpi, and 16 (29%) have EXIF width/height different from their pixel width/height.
So the effect on current images in the wild of using existing EXIF properties, (considering that the sample is representing of the wild) would be on less than 0.3% of images in the case of resolution, and on less than 0.5% in the case of ImageWidth/ImageHeight.
A more rigorous check, of 5000 images from 1190 site URLs, also testing whether an image explicitly sets width/height and manual examination of automatically-found affected sites, found around 5 images out of 5000 to be effected. That’s ~0.1% of images, but ~0.4% of sites. Note that “affected” in all of these case would mean that the image would shrink by a ratio 1.2-4.
Thanks @noamr! 0.4% of sites seems pretty high to change image density by default. 1190 sites is a small data set, though, so the percentage is a bit uncertain.
So if I understand your analysis correctly, the 5 images found are using EXIF ImageWidth / ImageHeight / XResolution / YResolution, and those would change the rendered dimensions of the image if they were honored by default. Correct?
Yea, it’s a bit high. It’s a pretty random dataset built from the list of most used sites. Creating a bigger sample set (or a better crawler ) would take some effort.
The 0.4% is for sites with images that have XResolution / YResolution and rely on intrinsic size for layout.
The percentage for ImageWidth & ImageHeight is higher - a lot of photos mark those properties when taken, and then don’t modify them when e.g. the image is cropped or scaled. It’s like “original image dimensions”