ACES, rgb primaries and ocio in image editing software?

Discussions - Using ACES VFX
1

New to this forum and ACES - thanks for all the information.

I come from the display referred world. Mainly photo, 3d rendering (sRGB, Adobe RGB, ProPhoto) and a bit video (REC.709).
Seeing the advantages of 32bit scene referred and a defined standard like ACES I like to switch :wink:

After reading a lot and trying ACES, it seems I still have brain blockers.

Topic is:
"How to interpret rgb primaries and what does image editing software do with this?"

As I understand it, ACES 2065-1, ACEScg, sRGB(linear) are linear but have different rgb primaries. What I am struggling with, is to understand the color transformation from one into the other.

Situation:
I make a reference render in Iray.
Iray is set to REC.709 preset but with transfer curve 2.2 in the tone mapper. As a result I get an sRGB 8bit image (I know about the difference between 2.2 curve and sRGB piecewise but ignore that here).

!_F2_REC.709_tm-on_G2.2
!_F2_REC.709_tm-on_G2.2700×700 27.7 KB

So far, so good.

Then I set Iray to ACEScg and output a linear exr ACEScg file.

First part of confusion:
What I think, that happens under the hood regarding the colors in the scene.

Because ACEScg uses a different gamut than sRGB the colors are different even though their picker values are the same:

011
011460×755 106 KB

Picked color is the same for sRGB output and ACEScg output

How I understand what happens regarding sRGB vs. ACEScg color:

010
010699×700 42.2 KB

Rendering to exr ACEScg uses the same picked color but the green is now visually different.

I now like to match the scene linear exr to the display referred sRGB image in Affinity Photo.
To do that, I disable 32 bit color management in Affinity Photo and only use the build in ocio features.

Second part of confusion:
The GUI says “input color space” and “output color space”.
But reading the aces ocio config tells me there is more going on.

I use this in “input color space” and think it transforms my ACEScg into ACES

  - !<ColorSpace>
    name: ACES - ACEScg
    family: ACES
    equalitygroup: ""
    bitdepth: 32f
    description: |
      The ACEScg color space
      
      ACES Transform ID : ACEScsc.Academy.ACEScg_to_ACES
    isdata: false
    allocation: lg2
    allocationvars: [-8, 5, 0.00390625]
    to_reference: !<MatrixTransform> {matrix: [0.695452, 0.140679, 0.163869, 0, 0.0447946, 0.859671, 0.0955343, 0, -0.00552588, 0.00402521, 1.0015, 0, 0, 0, 0, 1]}

I use this in “output color space” and think it transforms ACES into sRGB.

  - !<ColorSpace>
    name: out_srgb
    family: Utility/Aliases
    equalitygroup: ""
    bitdepth: 32f
    description: |
      ACES 1.0 Output - sRGB Output Transform
      
      ACES Transform ID : urn:ampas:aces:transformId:v1.5:ODT.Academy.RGBmonitor_100nits_dim.a1.0.3
    isdata: false
    allocation: uniform
    allocationvars: [0, 1]
    to_reference: !<ColorSpaceTransform> {src: Output - sRGB, dst: ACES - ACES2065-1}
    from_reference: !<ColorSpaceTransform> {src: ACES - ACES2065-1, dst: Output - sRGB}

012
0121000×644 47.9 KB

I thought, this way I could match the ACEScg exr to the sRGB file. But the result is not even close. So, I assume my understanding of how color transform works in ocio and ACES is wrong or I don’t understand how Affinity Photo works. Hope somebody here can help me.

2

Someone can probably do a much better job explaining everything in detail but in a tiny nutshell


Whether a color picker works the way you want it to work depends on if the software properly supports this with OCIO for which the colorpicking role can be defined to target a particular color space.

The ACES output transforms are designed to tone map a much larger range of values to display with a highlight roll-off where the display referred rendering will only apply a gamma curve to the linear data where only the range between 0-1 remains not clipped. For the context of 3d rendering it allows a much more natural range of light intensities compared to “oldskool” methods because you aren’t compensating as much for the limited display.

There is of course much more to that to know. What I found a really good source to read up on was Chris Brejon’s website.

edit
As for your render the colors are off because they weren’t converted to ACEScg but as you explaind in your plot used as ‘equivalent’ relatively speaking making them more saturated in larger color spaces. If you want sRGB materials/colors in ACES you’ll need to convert your textures(albedo) to the rendering space, ACEScg, or be able to tag them as Utility - sRGB Texture if the rendering app supports it. As for your colored shaders without albedo image files you’ll need to manually convert the intended sRGB value to ACEScg first. There’s a handy site for this acescolorspace - convert rgb.

3

@shebbe
thanks for the explanations.

I think my brain blocker is slowly dissolving.

Coming from an ICC-Color-Management world I am used to gamut mapping from one gamut into another. In that world there are rendering intents.
Depending on which intent is chosen, the math tries to map colors from outside the target color space into the target color space in a way that the appearence remains similar.
Reading more about the ACES transforms I think it works differently there. As far as I understand it now, “display gamut mapping” as I know it from the ICC world is not available in ACES 1.3 but being worked on for ACES 2.0.
I did a few tests with adjusting the colors via HSL etc. and then use a OCIO transform on top which gave much better results.

In general my mindset was:
sRGB display referred is the reference “look” I am familiar with and ACES is the linear way to get that “look”. But slowly it gets clear, that ACES is a different set of colors, brushes and canvases to get any look - sRGB being only one of them. I know, that is written on the frontpage but it took time for my brain to really get this :slightly_smiling_face:

1 Like