search

w3c / ColorWeb-CG

repo for the Color on the Web Community Group
51 stars 21 forks source link

HDR-in-PNG: nongoal for legacy/SDR decoders to have correct color behavior? #67

Closed 13thsymphony closed 2 years ago

13thsymphony commented 3 years ago

Other image formats like JPEG XL advertise "full" backwards compatibility, where a legacy non HDR-aware decoder will still get an accurate and well-mastered image.

https://github.com/w3c/ColorWeb-CG/blob/master/hdr-in-png-requirements.md#basic-requirements Mentions "does not break current implementations" and it might be worth to explicitly state that correct color behavior for legacy implementations is a nongoal.

ProgramMax commented 3 years ago

Do you know how JPEG XL achieves this?

Having not looked into it, I would guess 1.) something like an ICC profile could explain how to map values, and 2.) color space labels would imply that mapping.

Are these sufficient? I think I'm missing something because I would have imagined that is still covered well enough. For example, an older decoder won't know the new chunks but will know the old chunks. A PNG file could include those old chunks to get an approximation of the correct colors.

13thsymphony commented 3 years ago

Hmm, I might be getting my streams crossed re: JPEG XL backwards compatibility, sorry. It offers the ability to losslessly transcode between JPEG but only if you're encoding SDR data. In general there are techniques you can do to encode the "base" SDR image and auxiliary extended range data to "recover" the full HDR colors, but that's not at play here.

My understanding is that v2 and v4 ICC profiles are not good at being able to properly represent the extended luminance range of typical HDR content nor a transfer function like ST.2084. In theory you might be able to build some kind of "tone map to SDR" ICC profile that does a decent job at compressing colors, but I've never seen one in practice. I am expecting that any such usage of older chunks (iccp, gama, etc) would result in very noticeable color shifts for most users - it's going to be good enough that users will recognize what the object is supposed to be but not color accurate by any definition.

ProgramMax commented 2 years ago

I agree that attempting to represent HDR content with old chunks will result in noticeable error. I think that is unavoidable at this point. Current HDR content working with current decoders are facing the same issue and are doing the best they can. Anything we add will only show up in new decoders that already support the new chunks.

We could potentially attempt to spell out how a new decoder should represent HDR content on SDR displays. But I think we shouldn't. Currently, different OSes handle this situation differently. It would be a bit of an overreach for us to specify it.

As a result, I think there is no action here. We can probably close this issue.