Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
j7nj7n opened this issue Apr 26, 2024 · 2 comments
Open

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

j7nj7n opened this issue Apr 26, 2024 · 2 comments
Labels
jpegli Related to jpegli, also cjpegli and djpegli unrelated to 1.0 Things that need not be done before the 1.0 version milestone

Comments

@j7nj7n
Copy link

j7nj7n commented Apr 26, 2024

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.

@mo271 mo271 added unrelated to 1.0 Things that need not be done before the 1.0 version milestone jpegli Related to jpegli, also cjpegli and djpegli labels Apr 26, 2024
@jonsneyers
Copy link
Member

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:

  • the (recommended/intended) physical dimensions of the image
  • representing pixels with a non-square aspect ratio

This thread: whatwg/html#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
Copy link
Author

j7nj7n commented Apr 29, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
jpegli Related to jpegli, also cjpegli and djpegli unrelated to 1.0 Things that need not be done before the 1.0 version milestone
Projects
None yet
Development

No branches or pull requests

3 participants