So my DPI use case was actually for saving screenshots but the CMYK usecase was for taking RGB or RAW photos and converting them to CMYK color space for future use in CMYK documents, having touched up the colors to match the constraints of the color space.
Presumably the AVIF format supports extensive metadata. Supporting DPI merely requires a single numeric piece of metadata to be stored. The only part which may not exist is a defined standard name or location for this, and read/write support in the major image and publishing apps.
This is all entirely in the hands of Adobe.
My point still holds for CMYK though — bandwidth optimisation is rarely a concern for intermediary files. In fact, it's common to see compressed files rejected for being "low quality" based on file size and with no regard for the actual image fidelity. In this industry, formats like TIFF are sufficient.
If one was to propose a replacement for TIFF, it would need to support a lot more than just CMYK. Off the top of my head, it would need full alpha, embeddable profiles, 16 bit support, arbitrary channels, spot colours and vector clipping paths.
(As for CMYK conversion: even if you are touching up photographic colours for CMYK, this should be performed within the RGB space and soft proofing. The final conversion to CMYK should occur at print-time unless there's an excellent reason otherwise, e.g. if you are applying CMYK-inspired graphic art effects.)
Representing DPI in the real world actually requires at least two if not more floating point numbers.
The print/prepress industry has a long history of devices with asymmetric resolution, or higher resolution in monochrome versus color (similar to 4:2:0 pixel format used in digital video).
Considering professional print/prepress machines last 20 or more years in-service you have to handle just about everything.
All true, but irrelevant for images. All the number does is indicate the intended physical dimensions of the image.
For example, an image with pixel dimensions of 1800 by 1200 and a “DPI” metadata value of 300 will print with a physical dimension of 6.00 by 4.00 inches.
You misunderstand: the file format itself needs to have at least horizontal and vertical DPI values to be generally useful.
Many film scanners for instance are say 2400 dpi vertically and then some other DPI value horizontal depending on the film or picture format. Anamorphic lenses are used to scale a wide-aspect image onto a 4:3 sensor.
Some scanners and printers even have different DPI for different color components.
But it’s a big deal to have that field be named. Like you say, literally anything can be put in the unnamed metadata fields, giving them no weight. PNG even has arbitrary metadata fields and that hasn’t translated to anything remotely resembling proper dpi support there.
Correct, which is why I said realistically this is all in the hands of Adobe. They could support DPI on PNG tomorrow if they wanted to, and their metadata label would become a de-facto standard overnight.
