8-bit sRGB texture colors under CAM DRT

I’ve been test driving a texture painting workflow from Substance Painter to Maya under the CAM DRT with OCIO outputting to Rec709 SDR. One test is to see if I can get desired colors from the color picker, in particular fully saturated material colors for CG animation.

With ACES 1.2 I would have the color picking role set to linear Rec709 for colors of materials, only using ACEScg possibly for light colors. With that I was able to pick the colors I wanted.

I found however that under the CAM DRT I was not able to hit those saturated colors - specifically with yellows, greens, cyans. Not wanting to go all the way to ACEScg, I tried instead setting the color picking role to linear P3-D65. This wide color gamut seems to work well and I am able to hit those saturated colors.

I can of course save these textures out as EXRs in ACEScg, but if they are saved as 8bit textures in sRGB those saturated colors get lost. I therefore tried encoding them to P3-D65 with an sRGB gamma. This was almost identical to the EXR with one difference I noticed being that yellow in the EXR appeared a bit more red. Perhaps I’ve made a mistake in the transform? Here’s what I have for the OCIOv1 config:

  - !<ColorSpace>
    name: Texture P3-D65
    family: Utility
    equalitygroup: P3-D65
    bitdepth: 32f
    description: |
      The sRGB - P3-D65 color space
    isdata: false
    allocation: lg2
    allocationvars: [-8, 5, 0.00390625]
    from_reference: !<GroupTransform>
        - !<MatrixTransform> {matrix: [0.952552, 0, 9.36786e-05, 0, 0.343966, 0.728166, -0.0721325, 0, 0, 0, 1.00883, 0, 0, 0, 0, 1]}
        - !<MatrixTransform> {matrix: [2.46741, -0.946261, -0.400774, 0, -0.832211, 1.77089, 0.0217199, 0, 0.0389067, -0.0814114, 1.03521, 0, 0, 0, 0, 1]}
        - !<FileTransform> {src: linear_to_sRGB.spi1d, interpolation: linear}

Am I on the right track with this workflow? Any changes or adjustments you could suggest?

One concern I have with working in P3 is the headache this presents for Unreal which assumes Rec709/sRGB. So I guess a question I have is: is it possible/ should it be possible to get fully saturated colors into 8bit sRGB textures under CAM DRT Rec709? It’s unclear to me whether I’m tweaking things from the wrong end.

I recall being able to set/tag texture color spaces and change the rendering space of the engine. Not sure if that’s helpful…

Yes I know you can. It’s just a lot of work. For example all mega scans assets are in sRGB.

Yea I totally get that…
I would imagine in practice on a real game development project, if the desire is to go with such a workflow, tools would be developed to automate most of this process on ingesting assets into the engine which is then given to the artists.

I’m more worried about this. I understand that we have gamut compression and color appearance but for CG it’s going to be more tricky to convert client colors into a sensible material color for rendering as it will always look more dull by default? If we just pick a color for the material we have the ability to crank it more. But what about product label images for example? Would be interesting to test such things.

Where there is a will there’s a way. My question is: is this the will of the VWG?

That is, is it the recommended best practice to no longer use Utility - sRGB - texture for 8bit texture maps in ACES 2.0?

Here’s an image. This is a contact sheet made in Nuke of color swatches output from Substance Painter. First row is PNGs in sRGB, second row is PNGs in P3 (i.e. P3 gamut with sRGB EOTF), third row is EXRs in ACEScg. All viewed under the CAM DRT v35 Rec 709.

Here’s the same with those textures applied to spheres, again under the CAM DRT Rec709 Output Transform:

While yellow and green appear to have lower saturation in sRGB, red and blue appear darker. At any rate the colors appear different when saved out in sRGB for an 8bit image, so color fidelity is getting lost in the shuffle.

To be fair, when I look at the same under ACES 1.2 Rec 709 I see a similar loss in saturation. So perhaps what I’m noticing is psychological in that it has always been happening to an extent. Here’s that image in ACES 1.2 Rec 709:

Here’s the sphere render in ACES 1.2 Rec 709:

Just thought it would be good to get some other folks eyes on this so I’m not chasing my own tail.

@Shebbe What I do for that is convert it in Nuke, with an inverse sRGB output transform on the Read node, and a utility - sRGB - texture on the Write node. You can do the equivalent in Substance and Mari too. The CAM DRT is supposed to be invertible, so that approach should work in ACES 2.0 as well.

Unreal assumes nothing of the sort until you get to the LUT computation step where it creates a LUT that does the following steps :

  1. Gamut expand Rec709/sRGB to ACEScg (expansion factor is configurable; it can also do a simple 3x3 transform if the expansion factor is zero).
  2. Apply the color grading operations in your post-process volume in ACEScg space.
  3. Apply the appropriate ACES ODT for your display. IIRC, they don’t bake the EOTF in the LUT as they want to apply other post-processes down the chain.

Modify step 1 and you’re green to go. If you want to keep gamut expansion, you’ll have to reimplement it too as there is a custom 3x3 matrix that assumes linear sRGB input.

Hope that helps,

Edit: come to think of it, there might be some other places in the middle of the pipeline with hardcoded sRGB constants but these should be easy to find.

That’s encouraging to hear! What I was referring to is the sRGB checkbox on textures in UE5.0:

It looks like in UE 5.1+ there are added options in the texture Source Color settings

  • Encoding Override - Source encoding of the texture, exposing more options other than just sRGB.
  • Color Space - Source color space of the texture.

So, If I’m understanding this correctly, to convert the texture from P3 to the working space, rather from sRGB I would just need to do this:


Another approach would be to modify the Material Expression for linear to sRGB to work with P3. Although the math here is a bit over my head I’m afraid:

You can define the working space in the project settings, the DRT is now aware of it. Since 5.2 the Sky & Atmosphere is also colour managed. They are slowly but steadily making sure that everything is!

1 Like

The sRGB checkbox in the texture settings is for specifying whether your textures have the sRGB transfer function applied to them or not. Usually, Albedo and other color maps have it while normal maps and other non-color maps are linear data.