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
- Rec. 1886 / Rec. 709
- Rec. 2100 PQ
- ST2084 P3-D65
- Rec. 709 / sRGB
- Rec. 2020
- gamma 1.8, Rec. 709
- gamma 2.2, Rec. 709
- gamma 2.4, Rec. 709
- gamma 2.2, AP1
- Raw (non-color-managed data)
- CIE XYZ D65
- sRGB curve
- Rec. 1886 curve
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:
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?
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.
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!
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!
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 ! I used ACEScg values for the spheres and cranked up the exposure up to 7 stops.
Agreed that having :
instead of :
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 developer.blender.org 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.