If you’re working with CMYK images, use standard TIFF. Does everything anyone could require for distribution, other than bleeding edge compression options.

The print production world doesn’t need war file formats. It rarely operates in a bandwidth restricted environment. And any new image format would take years to be sufficiently supported by all relevant software packages.

For most images most the time, conversion to CMYK should be a last minute operation that takes into account source and printer profiles. The only immediately obvious exception I can think of is graphic artwork which should be stored as vectors anyway (with embedded pixel graphics where necessary).

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.

AV1 (and thus AVIF) appears to be designed for screens (works in YUV color space).

If you want to print, PDF is probably still your best bet.

AV1 can also encode RGB color space. Such usage would probably be more prevalent in the still image use case.

Actually I munged two issues. CMYK is for print but DPI is for retina images.

They have a metadata block type defined and you can shove whatever metadata format you want into it (EXIF, etc), and it has "image properties" for the necessary bits (presumably DPI would land itself as an image property, but I can see leaving colorspace out by assuming a "sane" default of something like sRGB).

Since there are plenty of reasons you don't care about this metadata (e.g. to reduce the transfer size on images that are requested millions or billions of times by a web browser), as much as possible it should be left optional.

But all of this seems to be pretty much draftware at the moment, so we'll see how things shake out.

You are correct: the specification is a work in progress which we plan to wrap of quickly. The approach is not to over-specify the format with features/options initially, but begin with a functional sub-set of HIEF and MIAF. The target is to provide an HDR/WCG successor to JPEG. This work is being done by a working group in the Alliance for Open Media.