Improving / Simplifying / Enforcing robustness of Colorspace Management

[Eary]

Just discovered this thread, some questions…

@brecht

I would add P3 to the list of displays color spaces you listed, since it’s pretty common. I’d expect a modern professional monitor to have a wider gamut like P3 rather than Rec.709.

I think Filmic Blender on GitHub already has P3? If you want it can’t you just merge it from Filmic Blender?

@brecht

We plan to add the ACES RRT transform relatively soon, since it’s standard and can be more easily made to work for multiple displays.

Given how negatively @troy_s has been talking about ACES (like in this thread:Blender Support for ACES (Academy Color Encoding System) - #138 by troy_s) I was under the impression that ACES will not be supported?

@troy_s

For the folks who are patient and willing to learn, ACES is a stimulus based mapping, and as a result, it provides no such thing as colour management. It cannot, because it botches the stimulus management side, which all sensation management is based on top of.

Specifically, for every stimulus mixture that cannot be represented at the display, it will distort in a device dependent manner. That means that what you will see on an sRGB display will be broken in a unique way compared to a DCI-P3 display, and extremely broken differently with an HDR display.

The system is broken. It does not work. So even if one wants to accept the aesthetic nightmare fuel, it also doesn’t work as a management system.

(Though this particular quote was said about 2 months after this thread)
And here is the result produced by ACES 1.2:

See the red becomes orange and blue becomes purple, which is what Troy has been talking about it being broken.
Or are the official devs having different ideas? I am curious.