> Yes, also store the DPI.

I don't think that's a good idea. Most images, like photos and screenshots, don't have physical dimensions. Some image tools like to put in bogus default DPI values that are guaranteed to be wrong, and it can be a bit of pain.

How else would you reproduce images at exactly the right size? Without DPI, the format would be useless for many scientific purposes.

But I get your worries. As a compromise, DPI could be optional.

Reproducing images at the "right" size is a very niche requirement. Most images don't even have a right size, including all photographs unless they either use an ortographic projection (they won't) or the object is completely flat and parallel to the focus plane (with recilinear projection, which most normal camera lenses come close to). Having this as a standard attribute in a generic image format makes no sense.

You are complaining about a format - with the stated goal to be very simple - not supporting some scientific usecase. What...? Use a different format then. That's not what this is trying to be. In fact, it's the exact opposite of what it's trying to be.

Yes, optional is fine.

If you want any interop you'd better standardize some keys, allowing for extensions. Store those in key,len,data records and you have iff/ riff formats ... used by .avi and .wav formats.

This is something I've never understood. DPI only makes sense if you need to accurately represent some physical dimensions in an image. Most of the time, you do not. You would just map it onto screen pixels somehow, most probably dictated by the UI layout around it.

Color profiles however, yes, those are indeed important.