4A. Setup Blender 2.8 to work with ACES 1.1 using OpenColorIO.

Blender 2.8 & ACES 1.1

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:

  • Download the OpenColoIO config for ACES 1.1 from this link:
  • github.com/colour-science/OpenColorIO-Configs/tree/feature/aces-1.1-config
  • Unzip and place the config in your user folder or on a server location.
  • Set a system variable for OCIO to this path to use it for all applications that supports it and don’t have an option in the preferences to set the path manually.
  • Or start Blender with the variable set only for Blender.
  • On the Mac I use Automator to create an App called “Blender_ACES”. In this app I use a shell script to set the variable and start Blender.
  • For Windows I use a simple .bat file.
  • I didn’t find an easier and way.
  • Happy Blending…
  • Oh, the color chart you can find here:
  • github.com/colour-science/colour-nuke/tree/master/colour_nuke/resources/images
OSX Automator Program
Windows shell script

Changes in the ColorManagement menu

Blender starts with the OCIO config and the ColorManagement is automatically set to the right settings.

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.