1.4. Blender & ACES 1.2

Setup Blender 2.9.2 to work with ACES 1.2 using OpenColorIO.

Blender 2.8 Cycles Rendering in ACEScg and a rather simple A over B comp in Nuke.

I couldn’t find a simple step by step setup for how to use Blender with ACES using OCIO. So here it is:

OSX Automator Program
Windows shell script

In the screen shots I am still pointing to the ACES 1.1 config and Blender 2.8. Over the last months I got some Email questions and there were some discussions on ACESCentral.com about the Shell script and Windows .bat file syntax. (These are example paths and have to be set to the path where you store your files)

Automator MACOS:
export OCIO=/Users/daniel/MEDIA/ACES/OpenColorIO-Configs-feature-aces-1.2-config/aces_1.2/config.ocio

cd /Applications/Blender/blender.app/Contents/MacOS/


PC .bat file:
Set OCIO=D:\ColorManagement\ocio\aces_1.2\config.ocio

START “Blender 2.9.2” “C:\Program Files\Blender Foundation\Blender\blender.exe”

Changes in the ColorManagement menu

Blender starts with the OCIO config and the ColorManagement is automatically set to the right settings.
The Color Management menu

Please refer to my Understanding Gamut with ACES and Blender page to see some of implications using a wide gamut working (color) space and the “View Transforms” that ACES provide.

ACES is not complicated to work with, but you need to keep track of the color spaces of each image source, the working space of the program and the viewing pipeline.

ACES/OCIO proposes to use color space tags in the file names. Here are a few examples e.g. filename_color space tag.0001.exr:

  • _aces = ACES 2065-1
  • _acescg= ACEScg
  • _out rec709=Output Rec.709
  • The full list can be found in the OCIO colorspaces list/aliases.

Tools with OCIO support can often read the tags and set the colorspace automatically. For example in Autodesk MAYA.

This is the Blender scene in ACES – means the program is started with the OCIO variable set.

Blender scene in ACES – click to enlarge – note that the HDRI is saved as ACEScg and the colorspace is set to ACEScg as well. Everything is set right and the render output will be as desired.

Now an example how it looks when things go wrong and what it means.

This is the Blender scene in default sRGB/Filmic – means the program is started without the OCIO variable set, but the Blender scene has image textures and an HDRI in ACEScg. Why you want to do that? You don’t, but it easily happens when you forget to set OCIO. But luckily the render result is just fine. Just the viewing pipeline for these image sources is not!

The same ACES-Blender scene loaded in the default Blender environment – click to enlarge – the HDRI is still saved as ACEScg but the colorspace is set to linear, because the OCIO terms are not existing. Here is a color space mismatch…or is it not?

The colors look washed out and the contrast is different in Blender. FILMIC uses the sRGB/Rec. 709 primaries and a custom tone mapping curve (simplified). The image sources are already saved as ACEScg so they look wrong. The tone mapping and gamut mapping (RRT&ODT) of the ACES pipeline are doing something different than the sRGB/FILMIC viewing pipeline.

Take these two EXR renders and compare them for example in Nuke (set to ACES). The rendered images are identical. Without the OCIO variable set, Blender “sees” them just as linear without any gamut information. No gamut conversion takes place so the render calculation are the same in this case.

A different case would be different color space image sources are used to converted to ACEScg in the ACES-Blender. Then the render results would be different.

The default Blender with sRGB/FILMIC is a wonderful tool. But not a known standard for a lot of other programs. Thats why I prefer to work with Blender and ACES/OCIO.

Limitations as of May 2020

There are certain limitations that need some workarounds that you should be aware of when using Blender & ACES. Therefore I started a new page
1.5. Blender & ACES Limitations.

A quick HDR render of the scene.