Thanks for that proposal link. The email thread starting at [0] seems to explain some of the challenges. My understanding:
- In ICC-land, all luminances are relative to the display's (or reflective medium's) black and white points. So for an HDR-capable display, all content, HDR or SDR, would be naturally displayed at the full 10k nits or whatever the actual number is. This is obviously not how things work in practice: OSes and/or displays really want a signal as to whether the full HDR luminance is actually desired. (This reminds me of an earlier HN thread where people complained about HDR video forcing up the brightness on Apple devices.)
- PQ (but not HLG) specifies everything in terms of absolute luminance, but this gets confusing when people want to adjust their display brightness and have everything work relatively in practice.
- Due to lack of support for "overrange" behavior [1], 1D LUTs + matrices are insufficient for representing PQ at all, so you need a 3D LUT just to approximate it. This needs ICCv4, since ICCv2 only supports 3D LUTs for non-display profiles.
- But 3D LUTs are big and fat, and can only give a few bits of accuracy across some parts of the full HDR range. (It seems like there's no form of delta compression?) Most people really hate this. iccMAX can allegedly use 3D parametric formulas, but literally no one implements it since it has a million bells and whistles.
- More importantly, GPUs especially hate big fat LUTs, and everyone uses GPU rendering. In the worst case, some implementations will do everything they can to ignore LUTs in ICC profiles, and instead try to guesstimate some simple-gamma or linear-gamma approximation, which won't end well.
So it does seem to be a combination of "the HDR stack is a mess and needs its own special signaling" and practical concerns about avoiding overly huge profiles.
- In ICC-land, all luminances are relative to the display's (or reflective medium's) black and white points. So for an HDR-capable display, all content, HDR or SDR, would be naturally displayed at the full 10k nits or whatever the actual number is. This is obviously not how things work in practice: OSes and/or displays really want a signal as to whether the full HDR luminance is actually desired. (This reminds me of an earlier HN thread where people complained about HDR video forcing up the brightness on Apple devices.)
- PQ (but not HLG) specifies everything in terms of absolute luminance, but this gets confusing when people want to adjust their display brightness and have everything work relatively in practice.
- Due to lack of support for "overrange" behavior [1], 1D LUTs + matrices are insufficient for representing PQ at all, so you need a 3D LUT just to approximate it. This needs ICCv4, since ICCv2 only supports 3D LUTs for non-display profiles.
- But 3D LUTs are big and fat, and can only give a few bits of accuracy across some parts of the full HDR range. (It seems like there's no form of delta compression?) Most people really hate this. iccMAX can allegedly use 3D parametric formulas, but literally no one implements it since it has a million bells and whistles.
- More importantly, GPUs especially hate big fat LUTs, and everyone uses GPU rendering. In the worst case, some implementations will do everything they can to ignore LUTs in ICC profiles, and instead try to guesstimate some simple-gamma or linear-gamma approximation, which won't end well.
So it does seem to be a combination of "the HDR stack is a mess and needs its own special signaling" and practical concerns about avoiding overly huge profiles.
[0] https://lists.w3.org/Archives/Public/public-colorweb/2017May...
[1] https://lists.w3.org/Archives/Public/public-colorweb/2017May...