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.
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?
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.
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!
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 :
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.
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.
I used ACEScg values for the spheres and cranked up the exposure up to 7 stops.