search

libjxl / libjxl

JPEG XL image format reference implementation
BSD 3-Clause "New" or "Revised" License
2.59k stars 252 forks source link

cjpegli: Pass on the DPI resolution into a JFIF marker #3533

Open j7nj7n opened 4 months ago

j7nj7n commented 4 months ago

Describe the solution you'd like If the input PNG image contains a physical resolution tag in 'pHYs', it should be written to the output in a JFIF marker after conversion of pixels per meter into pixels per inch. JFIF implies YCbCr colors, so I accept that it may not be present in XYB encoding, and it adds only 18 bytes of overhead.

Describe alternatives you've considered Use a 3rd party image optimizer afterwards.

jonsneyers commented 4 months ago

Besides what cjpegli should do with this, maybe it is also worth asking the question what cjxl should do.

Physical resolution tags are in my opinion a bit of a mess. PNG has a specific chunk for it, but the information can also be represented using Exif or XMP metadata. Many applications will just ignore the information. Some will use it to scale the image appropriately to obtain those specific physical dimensions. Most just ignore it, i.e. treat it as capture metadata (e.g. put there by a scanner so you know how large the physical image was) like the camera model or GPS coordinates, and not as render-impacting metadata (how the image is supposed to be displayed).

The pHYs tag in PNG can effectively be used for two things that are conceptually quite unrelated imo:

This thread: https://github.com/whatwg/html/pull/5574 and some of the threads that are linked in it / linking to it is also relevant in this discussion.

In jxl we have an optional codestream header field to describe intrinsic dimensions (which could be used to represent non-square pixel images) although I think most applications are currently ignoring that field and they should probably be fixed to not ignore it. We don't have a jxl codestream header field to indicate physical dimensions, but we could represent that information in Exif or XMP metadata.

j7nj7n commented 4 months ago

The use of this metadata is to maintain the size when the image is inserted into a document for printing. Let's say, I have a picture of a compact disc. It will automatically fit the circular template of 12 cm without manual adjustment if the resolution is correct. When I scan a document it may have variable margins. Instead of scaling it to fit, I can set to 100% and centered, and it is the correct size.

When coming from PNG, the value should be rounded so that 599.99... becomes 600.

No application that I know of uses these numbers to scale an image for display. Rectangular pixels are not common in still images. Scaling would lose a great deal of quality too if you went between 96, 72, 83 dpi. Often when people downsample for the monitor, the dpi value stays unchanged, so you have a tiny image at 600 dpi.

My Photoshop takes dpi from 0xFFED (it has decimals) then 0xFFE1/Exif then 0xFFE0/JFIF. XMP is passed along without function; it think most of it is treated as "editing history". The simplest programs read JFIF as it came first. Maybe a simple Exif could be constructed for JPEG-XL if none exist in the input image, and maybe plugins will read after 5 years.