Blender Support for ACES (Academy Color Encoding System)

[troy_s]

@g3ntile

There’s no ACES support in Blender, and never will be.
Never. Ever.

For the 15th time, no.

ACES is ACES. There’s nothing to “support”. Go install the official repository for OpenColorIO and done.

@nanoSpawn

At the end of the day, ACES is just another OCIO config, asking for “ACES support” completely neglecting OCIO is wrong, with a proper OCIO support Blender would support ACES and whatever you’d throw at it, being future proof.

Read this quote above. Someone who is sane and understands what has been communicated many, many times. Read their whole post.

@Pauan

That’s not the case. All you have to do is set the standard OCIO environment variable , and it will work with all programs that support OCIO (including Blender ).

While this is technically correct for swapping out OpenColorIO configurations, it is also not the entire picture. There are some nodes and expected roles that require tweaking to support alternative primaries. The luminance coefficients and the XYZ role come to mind, but there may be others that I can’t remember. Those changes by the way are the sorts of bare minimum things that anyone who seeks to use alternative configurations should feel comfortable adjusting. If they are not, that’s a terrific indicator that they are not ready for the additional complications associated with changing the configuration.

@Pauan

The point of using ACES is consistency: if I create an asset in Blender and texture paint it, I am guaranteed to get the same result in the game engine.

This is outright false, as I’ve tried to explain.

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.

Academy == True
Colour == False, because colour is a sensation metric.
Encoding == False.
System == False.

Had they stuck to the origins of the design, it would have been:

Academy == True
Colour == Not quite true
Encoding == True
System == True

But they shifted gears, and the entire architecture and design is impossible to manage colour, which is a sensation, because it does not properly manage stimulus.

@Pauan

And if I create an asset for one game engine and then port it to a different game engine, it will look the same.

Bzzt. Totally wrong, and is part of the con job misconception peddled by folks who know nothing about colourimetry or advanced colourimetry, and instead lean on the myths and rubbish peddled by YouTube clickbait.

NanoSpawn is of the sorts of minds we need to cultivate here. We would all do well to interrogate the concepts as they have.