Natural image resolution, CSS. web compat, and pHYs

[svgeesus]

The fact that Web browsers either don't use pHYs or, if they do, apply it as a scaling factor not an absolute resolution should be noted in the definition of that chunk. A note could also be added to the documentation of eXIf

For a good summary (in the context of CSS Images 3) see here

[svgeesus]

HTML prepare an image for presentation refers only to EXIF

• PixelXDimension
• PixelYDimension
• XResolution
• YResolution
• ResolutionUnit

and has no mention of PNG pHYs at all - it is not used. Spec should mention this, with links.

[svgeesus]

So this is a bit less settled than I thought:

• HTML has added this, but only using EXIF for now
  • "The change to the HTML spec defines how resolution is expressed in EXIF, and it would take more work to define it in other image metadata formats such as XMP."
  • Currently tested in WPT but solely with EXIF-containing JPEG images
• Currently open CSS issues:
  • [css-images] Images on the web csswg-drafts#5173 (comment)
  • [css-images] image-set() resolution should be applied on-top of, not instead-of the natural image resolution. csswg-drafts#6241
• Pending edits on CSS Images 4, and also lack of clarity on whether parts of this should be in the HTML LS or split off into some other spec

This means that we would be adding some caveat to the description of pHYs like:

Note that the HTML specification defines image density in terms of EXIF, solely, ignoring pHYs; and CSS currently applies intrinsic sizing as a multiplier on the image density, but that might change

which seems unlikely to age well.

Having poked around some, my inclination is to defer this issue until the referenced specifications settle down, before adding anything to the PNG spec.

[ProgramMax]

Agreed. Let's update the tags and all that, pushing it to a later spec.

[annevk]

Do we have tests for this chunk? And how often does it occur in the wild? If it's already fairly present, it might not be possible to change implementations.

I'm not sure what kind of abstraction we want for a theoretical "Web images" specification, but ideally it could pass a byte sequence to some algorithm in the PNG specification and get a bitmap and metadata back.

[svgeesus]

Do we have tests for this chunk?

The old PNGsuite has four images that contain this chunk.

For the physical pixel dimensions, the result of each decoding should be a square picture. The first (cdf) image is an example of flat (horizontal) pixels, where the pHYS chunk (x is 1 per unit, y = 4 per unit) must take care of the correction. The second is just the other way round. The last example uses the unit specifier, for 1000 pixels per meter. This should result in a picture of 3.2 cm square.

cdf - physical pixel dimensions, 8x32 flat pixels
cdh - physical pixel dimensions, 32x8 high pixels
cds - physical pixel dimensions, 8x8 square pixels
cdu - physical pixel dimensions, with unit-specifier

I have WPT-style tests with these images, which shows browsers ignore this chunk (which they are allowed to do, per HTML, CSS and PNG specs, currently).

My original intent with this issue was to add a note to the PNG spec saying that browsers have historically ignored 'pHYs' and it does not affect display of the image.

[svgeesus]

[annevk]

In that comment they display differently in Safari, but perhaps that's GitHub doing something to them?

[svgeesus]

In firefox and in chrome they display as 32x8, 8x8, 32x32 and 8x32 ie their actual pixel widths and heights from 'IHDR'. The 'pHYs' makes no difference at all.

[svgeesus]

And how often does it occur in the wild?

I don't have data, except to observe that any chunk that goes beyond the bare minimum to display an image tends to get dropped by image optimizers, whose use is widespread to get the smallest images.

If it's already fairly present, it might not be possible to change implementations.

I agree that Web compat should be the main concern here, and the specifications should reflect that. 'pHYs' has been in the PNG spec since the first, 1996, edition

[ProgramMax]

Several comments back, I mentioned I would mark this for a future edition. Then I marked it for the current edition.

I'm going to correct that.