OpenColorIO 2 Configs for ACES


The ASWF VWG for the OpenColorIO Configs for ACES is pleased to announce that the first pre-release of the Computer Graphics (CG) Config for ACES is available!

The CG Config is intended for use in CG lookdev, lighting, and rendering applications, and also game engines. It implements a fully-featured ACES color pipeline without the many camera input transforms that make up the bulk of the OCIO v1 ACES Configs, and which will be implemented in the upcoming VFX-focused ACES Studio config.

The CG Config is completely self-contained, i.e. no external LUT files, providing a single file color pipeline with minimal clutter. It has robust support for the most common texture and working color spaces, and SDR and HDR output transforms used in high-end CG production environments. It can be used as a starting point for studio CG feature pipelines, and is an excellent choice for bundled default OpenColorIO Configs in content creation applications.

CG Config Main Features


  • sRGB
  • Rec. 1886 / Rec. 709
  • P3-D65
  • Rec. 2100 PQ
  • ST2084 P3-D65

Linear Spaces

  • ACES2065-1
  • ACEScg
  • Rec. 709 / sRGB
  • P3-D65
  • Rec. 2020

Texture Spaces

  • sRGB
  • gamma 1.8, Rec. 709
  • gamma 2.2, Rec. 709
  • gamma 2.4, Rec. 709
  • gamma 2.2, AP1

Log Spaces

  • ACEScct
  • ACEScc

Utility Spaces

  • Raw (non-color-managed data)
  • CIE XYZ D65
  • sRGB curve
  • Rec. 1886 curve

Hi Thomas,

I tried to start Blender 3.2 (Alpha) with the new config and get this error message:

OpenColorIO Error: This .ocio config ‘/Users/daniel/MEDIA/ACES/OpenColorIO-Config-ACES-0.2.0/config-aces-cg.ocio’ is version 2.1. This version of the OpenColorIO library (2.0.0) is not able to load that config version.
The minor version 1 is not supported for major version 2. Maximum minor version is 0.

Just for fun I changed the first line in the config to:
ocio_profile_version: 2.0

Now Blender 3.2 (Alpha) starts on my Mac and it seems to look and work okay. I will test it today.

Is there something that can or will break because of the differences in V 2.0 and V 2.1?



1 Like

I did some further testing and run into a display issue. Of course I have no idea where this coming from.

Blender starts by default with the Display Device sRGB.

I re-rendered an old test scene that I made a while back for the Blender&ACES guide on my website.
The image contains all the colors from the color checker and the rendered result looks like this:

Only the cyan sphere in the viewer is broken. The shader uses the acescg values from the ColorChecker2014 cyan patch 18. And this is the only ACEScg value that is out of gamut in linear-sRGB/Rec.709.

The EXR render is of course fine and that this issue only seems to appear with the sRGB display transform. When choosing the Rec.709 instead the render view looks fine and identical to the same render view with the old OCIO v1-ACES 1.2 config.

Furthermore I found out that the PNG writer from Blender is writing out a broken image too in this case, the JPG writer works fine.

I setup a new page on my website on how to use the new config in Blender and I will check where I can report this bug.

1 Like

It is because the CG config inherits from the Reference config that has the RGC (Gamut Compressor) that is only available in OCIO 2.1, changing the profile is perfectly fine and we will certainly need to generate a few more of those with different versions. If you want to report an issue, the best way is to do that on the repository: GitHub - AcademySoftwareFoundation/OpenColorIO-Config-ACES but it is also fine here! :slight_smile:

It is hard to compare your images here, something worth noting is that OCIO 2 implements ACES analytically, i.e. no LUTs so it is expected to see some differences!



1 Like

Thanks for the clarification. I updated my website as well.

In this case it seems the results are identical between OCIO v1 and v2.



here is a simple example of differences (the same as the one I provide on my website) :

This is normal and expected and it matches Jed’s ACES implementation in Nuke. So all good I would say ! :wink: I used ACEScg values for the spheres and cranked up the exposure up to 7 stops.

Agreed that having :

ocio_profile_version: 2.0

instead of :

ocio_profile_version: 2.1

could help. I know very little softwares with OCIOv2.1 implemented. I had to manually edit the config and restart Nuke to get it working.




I checked the new OCIO V2 config in the lastest Nuke version and the sRGB view transform looks fine there. It looks like this is only happening in Blender 3.x for the moment.

I also posted the issue at with a simple .blend file that makes it easy the replicate the issue. ⚓ T96590 OpenColorIO-Config-ACES 0.2.0 breaks in sRGB view transform

And with further testing I realized that the issue is not present on my M1-Max MBP, but on an 2020 27" iMac.

After some back and forth, I uploaded two screen captures in the thread of the link shown above. Maybe someone has any idea where this bug could come from. It’s just twisted.

Hey Thomas,

Thank you for this - some of the pre-built configs finally seeing light of day (I know I’m late to the party here).

Anyway can you clarify a bit (for us non tech savy morons) the “completely self-contained” part here.

Does this not drop in a long side ACES 1.3 or ACES 1.2 lut files, as I believe most of us are used to?
Are they (luts) not needed at all even, in any application using this config? Which version of ACES is this equivalent to then (if built separately)?

This might all be very obvious to someone but at least I even get confused by the “…ACES-0.2.0” name part of this release against the commonly seen ACES 1.2…3…and or OCIO v1/v2 …and where this fits in in particular.
I suspect you’re actively working on ways to simplify all this magic and one thing will probably replace the other in the future. But I have to admit if someone asked me “what version of XYZ are you using”, I doubt I could answer that confidently.

Any info greatly appreciated - thanks!

Hello, here is my thought on this, if this could help you :

Developing a “product” is complicated, this step includes keeping track of the version released, especially if in our case, the final product is made of other ones. Right here we have three products ! ACES, OCIO and the ocio config in itself.


ACES alone, is a “collections” of requirements, standards, transformations, etc. Each update to one of these parts produces a new version like the well-known versions 1.3, 1.2, … that is published and tell “to have ACES be considered as X version, you have to update, modify this”.

As you may have noticed, the few years have only seen an increment in the “minor” number of the version. This is because, since ACES 1.0, the change didn’t affect enough the “product”(ACES). I can’t really tell you what does make ACES, “ACES” (it’s being discussed right now) but what I know is that ACES 1.0 defined mostly the “look” of the RRT and, this “look” has only received very minor updates/fix. (anyone corrects me here)


But ACES alone is just “a bunch of rules”, that you have to translate to your digital software. This is where OCIO came into play. See it as a language that your software can convert to its own language. Or if I may, see it like a “plugin” extending your software, so all of them implementing OCIO can understand the same language.

OCIO being an individual “product” have different versions. You might have heard about OCIO 2.0 (which was just called OCIO before) and all its subsequent releases like OCIO 2.1, …

Each of these versions includes new features, changes how you speak the “language”, fix bugs, … the usual stuff. OCIO 2.0 included a bunch of new big features (that’s why it got incremented from 1.0 to 2.0), one of them being builtins transforms. These transforms are mostly the transforms defined in the ACES standard for color transformations.

Previously (and still now), to create a color transformation (ex: from colorspace A to colorspace B), you had to specify “the mathematical formula” in the .ocio config to perform the operation you want. This transformations could be supplied as external files like LUTs, this explains why the ACES most spread configs have some luts files alongside them.

But as I mentioned in the previous paragraph, OCIO 2.0 removed the need for these LUTs because they are now part of OCIO as builtins transforms. This means that the ACES OCIO config can now be expressed as simple single .ocio file.

the .ocio config

And our last product is the “config” itself which is here for ACES but could be for anything else. You still want to keep track of it, for example, a transform had an incorrect name and you fix it. This is specific to this config only so you will need versioning for the config itself.
This should explains the 0.2.0 you see, that is for this specific “self-contained” config, which then use OCIO 2.0 (because of the builtins transforms). And those builtins transforms + the config refers to the standards defined in the ACES specification for ACES version 1.3 (correct me here).

Which well a lot of versions to digest for the end non-technical user. But it is still a pain for developers when you have to keep track of “which version of each product needs which version of X other product and what is the current version we are using.”

I hope this made things clearer and is also not a too simplified version. Anyway if someone sees something incorrect let me know so I can update it.


Hey @Matthias,

The goal is to have the config self-contained, the Reference and CG configs will be, the Studio one, most likely too.

No LUT needed because the transforms are analytically implemented in OCIO directly, or the required building blocks at least.

We are currently targeting ACES 1.3.

If you look at the current naming of the config as generated by the latest code, (and this has not been released yet), it is looking like that:


name: cg-config-v0.1.0_aces-v1.3_ocio-v2.2.0dev
description: |
Academy Color Encoding System - CG Config [COLORSPACES v0.1.0] [ACES v1.3] [OCIO v2.2.0dev]

This minimalistic "OpenColorIO" config is geared toward computer graphics artists requiring a lean config that does not include camera colorspaces and the less common displays and looks.

Generated with "OpenColorIO-Config-ACES" v0.1.1-15-geb59486 on the 2022/06/05 at 11:20.


name: reference-config-v0.1.0_aces-v1.3_ocio-v2.2.0dev
description: |
Academy Color Encoding System - Reference Config [COLORSPACES v0.1.0] [ACES v1.3] [OCIO v2.2.0dev]

This "OpenColorIO" config is a strict and quasi-analytical implementation of "aces-dev" and is designed as a reference to validate the implementation of the "ampas/aces-dev" "GitHub" "CTL" transforms in OpenColorIO. It is not a replacement for the previous "ACES" configs nor the "ACES Studio Config".

Generated with "OpenColorIO-Config-ACES" v0.1.1-15-geb59486 on the 2022/06/05 at 11:20.




That was very clear and helpful, I’m sure it will help other ‘new comers’ getting their heads around all of this too - Thanks Liam!

Very interesting, I was always under the impression that this little .config file alone would not be enough for programs like Nuke or Maya to “get their colors down right”, sidecar files would always be needed. :stuck_out_tongue:
…I need to get this into our pipeline and see what happens.

Also, thanks for confirming the version, exactly what I was looking for.

Thanks again!

@Thomas_Mansencal - One last question.
The “reference” config file which is also included in this release, am I correct in assuming that that file functions the same as the “cg” one …meaning is self-contained too - except more complete with all available LUTs included, or does it require special sauce applied to operate in such fashion?

Thanks again,

Hi @Thomas_Mansencal,
Is the sRGB display pure 2.2 gamma or piecewise?

I believe it is piecewise sRGB, yes? Are there plans to include a pure 2.2 sRGB display or to replace it for the piecewise? I know there’s been a lot of discussion on that here on the forums. Curious to hear your take.

It works the same way indeed it is however geared for devs as it is missing quite a bit of transforms to be useful for production. This should be addressed with the Studio config.

The latter, i.e. Piece-Wise because it conforms to the ACES sRGB Output Transform definition. I think we might have discussed about adding a Gamma 2.2 Display at the OCIO ACES Config level but I don’t remember what was the take on it from the Working Group. Something certain is that at the minimum the Config will honour the ACES transforms and stay close to metal without replacement. It does not mean that we cannot add a new display that said! Feel free to open an issue on the repo.



Is there an estimate when the Studio config will be released?
I really like the clarity of these new ones and would like to have one config file for all software I use to link to.
At the moment (Redshift, Aftereffects, Resolve, Mocha) all use their own config (which I don’t know which it is) or I manually link them to the “old” ones. Which seems to slow down things sometimes a bit.

This CG-Version worked great in all of them. But I am especially missing the cct transform for certain compositing tasks.



Tentatively, a first version for Siggraph!

Land in sight :slight_smile:


Hi, I have a little update to report for the OCIO config that I tried in Blender:

I did a little test today with the “OpenColorIO-Config-ACES 0.2.0” config in Blender 3.3 alpha.
The problem is still the same on my iMac, but not on the M1-MBP.

I tried today another config that is coming with Maya 2023 I believe (the folder is actually called “Maya2022-default”), also in Blender 3.3 alpha.
This config does does not twist the view transform and the result looks just fine on both the iMac and the M1-MBP.

I had a look in both configs but I understand too little to spot the difference in the configs that could introduce the error/bug that I encountered.