IIRC (been a while), the reason was ICCv2/v4 still requires a gamma function. And PQ is not a gamma function. Maybe they can cover HLG, but if we want to represent any given HDR content, we needed something more than ICCv2/v4.
That doesn't sound quite right to me. ICCv2's 'curveType' gives the option of a full lookup table instead of a simple gamma function. Maybe it has to do with ICCv2 saying that the reference viewing condition has an illumination level of 500 lx for the perceptual intent? (But how does that apply to non-reflective media?)
I don't doubt that there's lots of problems in the chain from RGB samples to display output, but I'm finding this whole thing horribly confusing. Wikipedia tries to distinguish 'HDR' transfer functions like PQ [0] from 'SDR' transfer functions in terms of their absolute luminance, but the ICC specs are just filled with relative values all the way down.
(Not to mention how much these things get fiddled with in practice. Once, I had the idea of writing a JPEG decoder, so I looked into how exactly to convert between sRGB and Rec. 601 YCbCr coordinates. I thought, "I know, I'll just use the standard-defined XYZ conversions to bridge between them!" But psych, the ICC sRGB profile has its own black point scaling that the standards don't tell you about. I'm still not sure what the correct answer is for "these sRGB coordinates represent the exact same color as these Rec. 601 YCbCr coordinates".)
Agreed that it gets confusing. That's a piece of why I'm unable to give you a solid answer. This isn't my area of expertise.
Here is what I can tell you confidently:
The original plan was to provide an ICC profile that approximates PQ as best as we could. But it wasn't enough. So the proposal was to force the profile name to be a special string. When a PNG decoder saw that name, it would ignore the ICC profile and do actual PQ.
Possibly more context (I just found this) from Apple. I'm not sure of date: https://www.color.org/hdr/02-Luke_Wallis.pdf
Slide 29:
"HDR parametric transfer functions not in ICC spec
Parametric 3D tone mapping functions not in ICC spec
- Neither can be approximated by 1-D or 3-D LUTs"
I'm not sure why they cannot be approximated by LUT. Maybe because of the inversion problem?
LegionMammal978|8 months ago
I don't doubt that there's lots of problems in the chain from RGB samples to display output, but I'm finding this whole thing horribly confusing. Wikipedia tries to distinguish 'HDR' transfer functions like PQ [0] from 'SDR' transfer functions in terms of their absolute luminance, but the ICC specs are just filled with relative values all the way down.
(Not to mention how much these things get fiddled with in practice. Once, I had the idea of writing a JPEG decoder, so I looked into how exactly to convert between sRGB and Rec. 601 YCbCr coordinates. I thought, "I know, I'll just use the standard-defined XYZ conversions to bridge between them!" But psych, the ICC sRGB profile has its own black point scaling that the standards don't tell you about. I'm still not sure what the correct answer is for "these sRGB coordinates represent the exact same color as these Rec. 601 YCbCr coordinates".)
[0] https://en.wikipedia.org/wiki/Perceptual_quantizer
ProgramMax|8 months ago
Here is what I can tell you confidently: The original plan was to provide an ICC profile that approximates PQ as best as we could. But it wasn't enough. So the proposal was to force the profile name to be a special string. When a PNG decoder saw that name, it would ignore the ICC profile and do actual PQ.
Here is that original proposal: https://w3c.github.io/png-hdr-pq/
Possibly more context (I just found this) from Apple. I'm not sure of date: https://www.color.org/hdr/02-Luke_Wallis.pdf Slide 29: "HDR parametric transfer functions not in ICC spec Parametric 3D tone mapping functions not in ICC spec - Neither can be approximated by 1-D or 3-D LUTs"
I'm not sure why they cannot be approximated by LUT. Maybe because of the inversion problem?