Applying look LUTs in ACEScg with multiple log spaces

[carlo.giesa]

Hi there!

I’m very new to ACES and OCIO, so please forgive me if I might come up with an obvious question. But searching through internet didn’t give me the answer that I am looking for, so I’m trying to present my issue here as clear and simple as possible.

We are switching to full OCIO color workflow based on ACES 1.3 to have correct color management in multiple DCCs.

Our first step is to convert our incoming plates into ACEScg. On a regular basis, we receive materiel that comes in different log spaces, e.g. ARRI LogC4 and Davinci Intermediate WideGamut, that has been shot with different cameras.

We have a little Nuke template that makes sure that every incoming material is converted correctly into ACEScg.

Now, we receive LUT files from the client that transform the look of the delivered plates into what it is supposed to look like in the edit. For all shots, those LUTs leave the colorspace in ARRI LogC4 (also for those drone shots that are coming from a different colorspace). We then, convert it back to ACEScg. So, in the end, I end up with a look definition in OCIO that looks like this (for the ARRI LogC4 case):

  - !<Look>
    name: shot_grade
    process_space: ACEScg
    description: Shot Grade
    transform: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: scene_linear, dst: ARRI LogC4}
        - !<FileTransform> {src: shot_grade.cube, interpolation: linear}
        - !<ColorSpaceTransform> {src: ARRI LogC4, dst: scene_linear}

The shot_grade.cube file is available inside a luts folder for each shot and gets looked up automatically by OCIO using context variables. This works as expected for our ARRI LogC4 footage.

Now, we need to find a way to make this work with the footage coming in another log space as well.

The only way we found to have a dynamic workflow that does not need any further development is to bake the color conversions ACEScg → ARRI LogC4 and ACEScg → Davinci Intermediate WideGamut into LUTs and use the same dynamic file lookup mechanism as for the shot LUTs.

But we have 2 issues with that:

1. To have a correct result, we need to generate pretty heavy LUTs. We use the CMSTestPattern in Nuke and we need to go up to a cube size of 80 which ends up with a LUT of about 13MB. This does seem to take a little moment to “load” when switching to our ‘shot_grade’ look in Nuke, RV or other DCCs.

2. This does not work with overexposed footage. We get pretty strong clamping and end up with a completely wrong look.

Some ideas popped up:

• Might there be a way to convert the client LUTs so that they simply work in ACEScg? But I guess, the working in a non-log colorspace makes problems in high exposure situations as well.
• Use context variables to drive the first color space transform dynamically. That would be an option but needs additional development to set this environment variable correctly. We would like to avoid this.
• One solution seems to be to use as working space the original log space when applying our LUT. But this does not really help us since we can reproduce this only in Nuke (couldn’t find any ‘working space’ option on a file transform in OCIO) and we end up again with a color space that needs to be set somehow.

Is there anything basic that I’m missing here? I’m pretty sure that a lot of VFX houses have to deal with such situations. How do they do this?

Any help and input would be more than welcome!

Thanks a lot for you attention!

Greets,
Carlo

[chuckyboilo (Charles Boileau)]

Hi @carlo.giesa,

Yes that is a conundrum that we deal with on a regular basis.

So there are 2 ways you ca approach this:

• Normally, DI facilities will normalize everything into one color space. IE drone → to LIN AWG4. You can then assume that the show LUT is the drone LUT and maybe use a CDL to better match it. This is the ideal situation.
• We ingest LUTs at my facility. We recently added a secondary LUT position in our OCIO. That LUT could be used as is our in a concatenation (in an LMT scenario for example). You could add the dron LUT to a specific folder for that purpose.

Makes sense?

Thanks!

[carlo.giesa]

Hi Charles!

Thanks a lot for your message. In the meantime, after digging a couple of hours more in internet, we could came up with following solution:

To bake the colorspace transformation into a LUT that does not need heavy LUT files and that works nicely with overexposed footage, we need to convert everything into log space. In Nuke, this looks like this:

1. ACEScct → ACEScg (kinda counter-intuitive, but makes sense if you want all values being between 0 and 1, even for very high exposed pixels)
2. ACEScg → original plate colorspace
3. ACEScg → ACEScct

And in the ocio config, we need to apply this LUT the following way:

(first three lines are specific to this color space transform using our created LUT with the nodes above)

I’m really not a color specialist. So maybe there might be something wrong about this approach. But we checked this visually with a lot of different plates and it looks pretty much the same than using the color space transform directly.

And now, we have a setup that can handle plates with different color spaces converted into ACEScg, and apply client LUTs that work only in the original plate color space using LUTs. No need for fancy tools, just search paths, context variables and LUTs copied to the right spot.

Hope this makes all sense and might help others going through the same difficulties.

Greets,
Carlo

[piotrus3333 (Marcin Piotrowski)]

ACEScct is not really 0-1. only certain range fits 0-1.
ACES docs suggest for example one of camera specific logs when for some reason you need to bake ACES gamut compression to a lut.