Gamut Definitions - to change or not to change?

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.

Thanks for putting this together Carol.

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.

Thanks!

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:

COLOURSPACE ΔE Σ ΔE DOMAIN
Beta RGB 1.9045858 1.4431297 0.0257699 6.9092576
Don RGB 4 1.9484113 1.4834547 0.0242045 7.1389891
Russell RGB 2.0149923 1.4006557 0.0281064 6.4196410
Ekta Space PS 5 2.0154045 1.5804223 0.0227101 7.7085287
ACEScc 2.0199682 1.4342916 0.0287857 6.9753205
ACEScg 2.0199682 1.4342916 0.0287857 6.9753205
S-Gamut3 2.0474552 1.3776112 0.0226381 6.9639093
S-Gamut 2.0474552 1.3776112 0.0226381 6.9639093
Rec. 2020 2.0597671 1.4719141 0.0286072 7.2516402
ALEXA Wide Gamut RGB 2.0753945 1.4486502 0.0280578 7.1418264
Best RGB 2.0985331 1.5226285 0.0251649 7.5406871
ECI RGB v2 2.1073061 1.5283936 0.0341573 6.8745775
S-Gamut3.Cine 2.1199043 1.4931442 0.0241217 7.4103163
Adobe Wide Gamut RGB 2.2825407 1.5597158 0.0273120 8.4799754
Adobe RGB 1998 2.2875350 1.5747149 0.0331206 8.3838293
NTSC RGB 2.3135852 1.6618353 0.0408547 7.3833346
ProPhoto RGB 2.3668399 1.4961257 0.0345989 8.1531742
Max RGB 2.3920886 1.4694990 0.0350022 8.1448930
DCI-P3 2.4311089 1.8539547 0.0271378 9.6422661
ACES2065-1 2.5029641 1.4335802 0.0304227 7.7247164
ACESproxy 2.5029641 1.4335802 0.0304227 7.7247164
Xtreme RGB 2.9321813 1.6954522 0.0475488 9.7040707
ColorMatch RGB 3.0453732 1.9165876 0.0411851 9.5412947
CIE RGB 3.1310100 2.1718898 0.0197052 10.9417153
Pal/Secam RGB 3.1328869 2.0835301 0.0351991 10.6110667
Apple RGB 3.1662918 2.0104546 0.0398379 10.3283734
Rec. 709 3.2694661 2.1875167 0.0351322 11.0359728
sRGB 3.2694661 2.1875167 0.0351322 11.0359728
SMPTE-C RGB 3.5790208 2.3471398 0.0389569 11.7252912
  • Note that only the primaries of the above RGB colourspaces are being accounted for in the computations, thus ACEScg and ACEScc are effectively the same, so are BT.709 and sRGB, etc…

And here is a more recent answer on Graphics Stack Exchange where I reproduced our findings within Mitsuba.

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.

Cheers,

Thomas

Hello Carol,

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).

Harald

I wanted to raise that point! :slight_smile:

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.

Apologies for the conflating terms!