@TooDee Yes, I think I agree. I know that you use Blender a lot. Blender uses AgX with a working space of Linear Rec709. Do you use that working space? I’ve modified the OCIO config I linked to above to use ACEScg working space.
@ChrisBrejon taking this into the reference color space, I was trying to get OpenDRT working inside of an ACES config, i.e. with the reference space of AP0. @jedsmith 's OCIO config uses Filmlight - E-Gamut2 - Linear as its reference space. I see that in your config you used CIE - Linear - XYZ - E.
Do you know if there is an existing config that uses AP0? I’m sort of running into a wall with getting it to match when in the ACES gamut. Any pointers would be greatly appreciated!
It can definitely be complex and confusing getting an OCIO config up and running with your own customizations (believe me I have battled with this for more hours of my life than I would like to admit).
Nothing dictates that the reference space of the OCIO config needs to match your working space. So you could very easily have an OCIO config that used an XYZ reference space while using an ACEScg working space for example.
For getting OpenDRT to work in an ACES OCIO config, it should definitely be possible. You would just need to transform to whatever shaper space the LUT is prior to the FileTransform with the LUT attached. For example you could bake out a LUT of OpenDRT using ACEScct as a shaper space (though be aware this will be lossy in the sense that you will be clipping a significant portion of camera observer colorimetry that can be rendered into a picture successfully by OpenDRT, so maybe it’s not the best choice of shaper. This is why I used Filmlight’s EGamut2 (with Daniele’s permission). The same argument could be applied to your working space discussion above, but I won’t comment on that, and maybe it’s not relevant if you are not working with camera sourced image data.
If it’s helpful, you could also check out my ociogen project. It’s a GUI utility for creating your own OCIO config from scratch, with a bunch of configuration options, built-in colorspaces, the ability to generate an OCIO v1 or OCIO v2 config, and the ability to load your own LUTs and add them as view transforms. You can set the Reference Colorspace to be whatever you want and all the matrices will be calculated based on this reference space. For example to make a config with an ACES 2065-1 reference space you would set it up like this:
Maybe a little easier than typing yaml by hand. Maybe 
EDIT: There is another option if you just want to change your working space and do not strictly require the reference space of your OCIO config to ACES AP0. To achieve this you could just set the working space as desired in your software (if supported - for example in Nuke this is set with the working space knob on the root node), or by customizing your roles - for example many softwares still use the scene_linear role as the working space.
Hope it helps.
2 Likes
@Derek
I am using Blender for tests on projects, but usually not in production for rendering. And of course for writing stuff on my blog.
I like to try out different OCIO configs and learn what it means when using different working colourspaces and image formation pipelines.
Depending on the project this is a great idea.
The visualization and coloring of assets is greatly simplified across multiple packages, as you have noted.
As long as most of your assets are around the rec709 color gamut the floating point nature of OCIO will preserve small excursions into a larger gamut, although you don’t want to have hero colors fall outside. So for instance a deep aqua sea color has a significant negative red component . If that is a hero color for the feature you’s want something bigger like P3.
That is similar to how the original OCIO animation configuration worked. It provided an intuitive working space for all of the pipelines and tools , with simple transformation to other spaces.
Just note that just as tools designed for sRGB work correctly, tools designed for ACES can have trouble. Even if you convert into and out of linear spaces, the tools aren’t going to have any intuition to respect the 709 gamut.
OCIOGen is a super useful tool! 
It’s also helpful to know that ACEScct is not a great shaper space. I was able to pinpoint that the issue I’m having is that I’m making the LUTs wrong. The fix was to use the same working space and log shaper so
CMTtestPattern > EGamut2 TlogE to EGamut2 lin > OpenDRTnode(gamut EGamut2) > GenerateLUT
instead of…
CMTtestPattern > EGamut2 TlogE to ACEScg >OpenDRTnode(gamut EGamut2) > GenerateLUT
Also I see in your config that you are not using the shared_views coupled with an EOTF. Is that possible to do? On the OpenDRT Nuke node I can set the eotf to linear, but the gamut would still need to be set to Rec709 or P3-D65 meaning I could not have one view transform shared across Rec1886 and P3 Displays. Just curious about that one.
I was seeing a slight difference between your OCIO config and mine generated from ociogen. In this image (which I think is from @TooDee ) you can see in yours it retains the color on the kids faces better.
The solution turned out to be using the 1d LUT you have in your config in place of the matrix:
- !<ColorSpace>
name: Filmlight - E-Gamut2 - T-LogE
aliases: [feg2lge]
family: Working Spaces
description: |
Filmlight E-Gamut2 - T-LogE
Same as T-Log but upper range extended from 128 to 512.
encoding: log
to_reference: !<GroupTransform>
children:
- !<FileTransform> {src: oetf_filmlight_tloge_to_linear.spi1d, interpolation: linear}
#- !<LogCameraTransform> {log_side_slope: 0.0639976040320219, log_side_offset: 0.552012656860665, lin_side_offset: 0.00570482440424738, lin_side_break: 0, direction: inverse}
- !<ColorSpaceTransform> {src: Filmlight - E-Gamut2 - Linear, dst: reference}
By the way I was super pleased to see the default look you came up with for OpenDRT. As you may recall I can be rather obsessive with the color of yellow in terms of sunlight, fire, and such.
Here’s a Goldilocks comparison:
ACES 1.0 is toooooo yellow!
ACES 2.0 is toooooooo red.
OpenDRT is juust riiiiiight!
and so is RED IPP2:
Hm, I’m not sure I understand what you are trying to do. Let me talk it through to see if I get it (please elaborate if I don’t). shared_views is an OCIO feature which allows you to define views that can be re-used for multiple display definitions in an abbreviated syntax. So I guess for example I suppose in my OCIO Config I could have defined Display Encoding and Bypass once and then re-used it using the - !<Views> [ Display Encoding, Bypass ] syntax. But to do that I would also have had to use the OCIO v2 only view_transforms architecture, because the Display Encoding spaces are different for every display. I didn’t want to do that because I wanted the config to be OCIO v1 so that it is backwards compatible with the many vfx pipelines still running OCIO v1 software. In addition to that, personally I found the view_transforms architecture with the additional display reference space to be exceptionally complex, add a significant cognitive burden, and all for not much (if any) gain.
Maybe you are trying to preserve disk space and re-use LUTs between different displays/viewing environments that use the same Picture Formation Transform? (for example, the sRGB Display - 2.2 Power Rec.709 transform and the Rec.1886 2.4 Power Rec.709 use the same Picture Formation, but different display encoding). If that is the case you could set up different colorspaces that use the same LUT, but un-do one Display Encoding, and apply another. (There is actually a feature for that in ociogen called “Mutate Views”) – Of course this would absolutely not work if the two Picture Formation Transforms are not the same, as is the case for your Rec.1886 and P3 displays example.
Hm. Both of those renderings of the “Red Xmass” image look wrong, if you are are showing OpenDRT v1.0.0 Default. It should look like this:
Are you sure you have your color management of that image set correctly? Or maybe something else is going sideways? The “Red Xmass” original source R3D is here if it helps.
I have not looked at Daniel’s OCIO config, but if it’s using ACEScct with AP1 primaries as the shaper space, the difference could be explained by everything outside of AP1 being clipped off prior to the picture formation being applied by the LUT (there is a lot of camera observer colorimetry outside of AP1 in this particular image).
Thanks for the kind words. Of course you could tweak that behavior if you wanted with the hue shift parameters - but glad we ended up somewhere pleasing to you after all that energy you spent campaigning for golden sunsets and fire back then
No, this is as far as I know “red Christmas” is coming from a RED camera clip that was introduced into the VWG for the reference gamut compress RGC function that ended up in ACES 1.3. Since then this image appears again and again in different contexts.
The RED clip is challenging…
Hey, just a thought.
You can do it the other way around. Might probably be easier.
Grab any openDRT config (mine or Jed´s) and just set the roles to ACEScg.
Maybe this is not what you´re looking for but I thought I would mention it. Sorry for the noise !
I’ll keep an eye on it, but I believe what you may be referring to is how the colors are getting crushed/clamped in my images, and I suspect that is just an unhappy result of me quickly taking a screenshot and pasting it on the web. They do not look like that on my monitor.
The point I was trying to make is that there is a difference in appearance between the 1d LUT and the matrix. Can you confirm that you see this too?
I assume by “matrix” you mean !<LogCameraTransform>? If so, thanks for flagging: you are indeed correct, there was a bug with the OCIOv2 Builtin Transform version of the T-Log and T-LogE colorspaces. I’ve pushed a fix and deployed a new version to pypi).
Meanwhile you can swap the line to these and you should get a match:
# T-LogE
- !<LogCameraTransform> {log_side_slope: 0.055459048831, log_side_offset: 0.500867797955, lin_side_offset: 0.00487980885981, lin_side_break: 0, direction: inverse}
# T-Log
- !<LogCameraTransform> {log_side_slope: 0.0639976040320219, log_side_offset: 0.552012656860665, lin_side_offset: 0.00570482440424738, lin_side_break: 0, direction: inverse}
I’ve been using your config and Jed’s as a baseline for mine, but what I’m trying to do is get multiple DRTs all available in a single config in AP0 reference space with AP1 working space. Currently I have these DRTs
ACES 1.0
ACES 2.0
RED IPP2
OpenDRT
AgX
AgX was the one that originally prompted my question about the working space for CG since it uses linear Rec.709 as its working space.
It also has a more complex construction of the display transform compared to, for example OpenDRT which is simply a ColorSpaceTransform and a FileTransform. AgX has this (this is from the Blender OCIO config for sRGB display)
- !<ColorSpaceTransform> {src: Linear CIE-XYZ E, dst: Linear FilmLight E-Gamut}
- !<AllocationTransform> {allocation: lg2, vars: [-12.47393, 12.5260688117]}
- !<FileTransform> {src: AgX_Base_sRGB.cube, interpolation: tetrahedral}
- !<ExponentTransform> {value: 2.4}
- !<ColorSpaceTransform> {src: Linear Rec.709, dst: sRGB}
Which I’ve had some difficulty translating into an AP1/AP0 config. I tried just swapping out the reference space, but I found that I also needed to change the ExponentTransform from 2.4 to 2.6 to get a match, which made me doubt that I was doing things right.
- !<ColorSpaceTransform> {src: ACES2065-1, dst: Linear FilmLight E-Gamut}
- !<AllocationTransform> {allocation: lg2, vars: [-12.47393, 12.5260688117]}
- !<FileTransform> {src: AgX_Base_sRGB.cube, interpolation: tetrahedral}
- !<ExponentTransform> {value: 2.6}
- !<ColorSpaceTransform> {src: Linear Rec.709, dst: sRGB}
What I’ve landed on doing is baking out a LUT from that config so I could put it into the simple colorspace/filetransform pattern in mine. This appears to give me a perfect match, but I’d love anyone’s insights on a better way if there is one.
Yes, I did mean to say LogCameraTransform, and the new one works great!
I’m currently having fun experimenting with looks with the OpenDRT node. I’m working on a look that can be used for stylized/painterly rendering. I really like how the OpenDRT default look handles color, so I’m not touching that. But for painterly rendering I made it more neutral (lowering the contrast) and added in highlight contrast to increase highlight exposure at 2.5 stops above mid grey. My thinking with this – coming from a painting background – is that I don’t really want the “punchy” high-contrast, high-saturation look of a lot of CG cartoons, but rather something that looks more… painterly. Still a work in progress, but a fun ride!