Metadata access when decoding images

[padenot]

This specification proposes to demux and decode image files. In addition to be able to display the file, it needs to be able to surface frequently used information about those images. A few query in a search engine shows that this is something overwhelmingly popular (for example on stack overflow, but also searching github for wasm/js based decoders).

What immediately comes to mind is to know the dimension of an image before having decoded it (to prepare layout). But generally lots of info are parsed by the implementation, and then not surfaced to script, which is unfortunate, because it means that developers need to ship a bunch of code (probably compiled to WASM or something like that), to do something that the browser already does (and probably better/faster).

Other things I'm thinking of (not exhaustive):

• pixel bit depth / decoded image format (to prepare textures/canvas while/before the image is decoded)
• orientation / more EXIF metadata or other metadata (depending on the format), this is simply necessary to allow layering
• color space (≠ color space conversion)

[dalecurtis]

Agreed on resolution, orientation, color space, and bit depth.

I'm not sure I follow how the decoded image format would be helpful to know upfront. It may also be difficult to know in the ReadableStream case.

In terms of implementation, we've intentionally been conservative in what we've exposed so far, so we can add these as we come to agreement on them. At present no developers have asked for any metadata though. We removed orientation metadata since no one was asking for it and we couldn't agree on how to specify it to the web. Do we just use the exif code? Do we convert exif to a rotation and mirror pair (documenting which is done first)? Do we use a new enum?

[chcunningham]

Triage note: marking 'extension', as new metadata would be surfaced via added attributes.