We touched briefly on this topic in the first meeting. Here’s a short summary, and I’d like to open up the discussion prior to our meeting on Thursday:
Technically, it falls under the purview of this group to explore anything related to the ACES gamuts - including the definitions themselves. There were a few concerns brought up in our first call:
Scope. We have a big task ahead of us, and the more defined and contained we can keep it, the better
Backwards compatibility/usability with current definitions and implementations
An ideal gamut mapping algorithm should not be specific to a given set of input/output primaries (not AP0 to AP1 only)
However, the discussion of whether the current set of ACES primaries, especially the rendering primaries, are optimal for the future is an important discussion and one we feel should be tackled at the beginning - looking forward to your thoughts here as well as in the call on Thursday.
After today’s call I’m not really sure where we’ve left off. I think we all agreed this decision wasn’t suited to particular working groups focus, but I’m unsure if the rest of group will continue with the assumption that AP0/1 will be the only gamuts we consider moving forward. Or, if we need to spawn another group that focuses on this particular aspect, and the decisions of this group will feed into the decisions of the “Gamut Mapping” group.
That’s not a question directly focused to you necessarily, but the group as a whole. I’ll hold my thoughts for now to just get clarity on the direction we think are going.
Changing/adding more primaries would only add to the confusion IMHO, ACES is quite a beast already. I’m not exactly sure about what would be the benefit so I would be keen for somebody to explain the reasoning behind that. The only minor annoyance I have with AP1 is the fact that it has non-physically realizable primaries.
Anders Langlands and I ran some tests 5 or 6 years ago both together and concurrently and it turned out that BT.2020/ACEScg/AP0 performed quite well as rendering spaces:
Those are renders of the same scene using BT.709 primaries (first row), 47 spectral bins (second row), BT.2020 primaries (third row), spectral minus BT.709 primaries renders residuals (fourth row), spectral minus BT.2020 primaries renders residuals (fifth row). The last row showcases composite images assembled with three vertical stripes of respectively the BT.709 primaries, spectral and, BT.2020 primaries renders.
The RMSE with the spectral render are 0.0083 and 0.0116 for respectively the BT.2020 primaries and BT.709 primaries renders.
Now it does not mean they will always perform better, and one might be able to produce examples that will exhibit a bias toward BT.709/sRGB. The main takeaway is that RGB renders cannot match spectral renders and sharp wide gamuts tend to perform better
Changing rendering primaries should really be motivated by examples showing that it does really improve things. Something I had planned but never had spare cycles to do was to optimize a set of primaries that reduces error in the spirit of the notebook on our blog. It should be easy to do as Colour has all the tooling to do that nowadays.
could you specify what you mean by “rendering”? A) The synthesis of an image or B) the transform of a scene-referred image to a display.
I don’t want to appear pedantic, it just seems that Thomas is understanding something else (A) than I do (B).
Thanks for raising that point @hbrendel - I was referring mostly to A) Synthesis of an image a.k.a AP1 in this case.
Not that the transform to display and its associated primaries is less important - it’s just not the focus of this group (in my opinion, open to discourse on this point). I believe that falls more into the realm of the RRT/Output Display working group that will spin up at some point soon.