[solardev]

Many formats have stuff like that (like cover art in MP3 ID3 tags), but usually they're used for, well, ancillary purposes.

It's dangerous to use this to change the actual primary output of the file (the image), especially in a way that users and editors can't easily detect.

[sspiff]

I would say at least in the context of extra data to extend the bit depth for HDR, that data could be considered ancillary?

We've been rendering images in SDR forever, and most people don't have HDR capable hardware or software yet, so I don't know how you could consider it as broken to render the image without the HDR data?

[Too]

This assumes the image is presented in isolation.

I’ve seen countless of issues where you place a PNG logo on top of a css background:#123456 and expect the colors to match, so the logo blends in seamlessly to the whole page.

On your machine it does and everything looks beautiful. On the customer machine with Internet explorer they don’t, so the logo has an ugly square around it.

[sspiff]

The difference in experience for seeing a black or white background instead of a transparant one on the one hand, and missing HDR on the other is pretty big.

95%+ of humans won't even notice HDR being missing. Everyone with eyes will notice a black or white square.

[Too]

Nobody said anything about black or white. Try googling for png color problems and you’ll find thousands of questions, in all kinds of tools and browsers. The css color and the png color need to match exactly. Just a slight difference will look off if placed next to each other. The risk of css and png rendering two same hex-codes differently increase when putting semi-supported hdr extensions in the mix.

For this particular use case, yes, transparency is more suitable than trying to match.