Brylka – TooDee – PanicPost

2.6.1. Apply 3D-LUTs in flame and nuke

And why is this only a tool for preview purposes.

Normal look 3D-LUTs are not compatible with the concept of ACES. A 3D-LUT is mostly used to convert scene referred log image data to a display referred output colorspace via tone- and gamut-mapping. In the ACES pipeline this is the job for the RRT & ODT. So it doesn’t make sense to apply 3D-LUTs in the middle of the process as ACES is supposed to stay scene referred or indirect display referred (a term that I borrowed from Filmlight) up to the output stage. ACES supports a different tool for looks called LMT (Look Modification Transforms).

Still it can be useful to use a shot, sequence or show LUT to preview how an image might look later on in the grading process. For client review preview outputs it can be also handy to apply a 3D-LUT to not confuse them with different looking images coming from editorial, comp and grading. I emphasize on the usage of 3D-LUTs for previewing only so much as a 3D-LUT cannot be inverted without any loss of quality.

In this article I want to focus on how to apply a 3D-LUT in nuke and flame when working in ACES. I am using an ARRI ALEXA Mini LF demo clip that can be downloaded here. I started by loading the MXF clip into Resolve and exported a portion of it as source resolution ACES AP-0 EXR files. This are my source files to be used in nuke and flame.

Ungraded Clip F003C008 exported with a baked in ACES Rec.709 ODT.

(1.) and (2.) are two distinct looks based on two different view transforms. Usually I would get a 3D-LUT (1.) created in standard Resolve from set or the director/DP.

apply a 3D-LUT in NukE (ACES)

First I start in Nuke. Nuke is set to the OCIO config ACES 1.1. with the working colorspace ACEScg, but I use the viewer Rec.709 (ACES). By default the viewer would be set to sRGB (ACES). The Nuke node setup is simple to apply the 3D-LUT in both cases.

Nuke is automatically converting the image data in the read nodes from ACES (AP-0) to ACEScg (AP-1), the working colorspace. And write and viewer nodes converting always from ACEScg (AP-1) to ACES (AP-0) before the RRT&ODT is applied for viewing or writing out to a file in the destination colorspace.

Nuke node graph: Two ways to bake in the 3D-LUT in the image pipeline.

(1.) – The 3D-LUT created with a standard Resolve setup (manual color management). These are the processing steps:

  • ACES to ACEScg conversion in the read node
  • OCIOColorSpace transform from ACEScg to ARRI V3LogC EI800 – wide gamut
  • OCIOFileTransform applies the 3D-LUT file – the working colorspace must be raw or ACEScg, because the step before already converted the image data to an expected log format.
  • The result is now display referred but the nuke viewer expects scene linear data to process. Therefore I compensate for the view transform and apply an inverted ODT Rec.709.
  • So the last step is a OCIOColorSpace transform from Output-Rec709 back to ACEScg.

(2.) – The 3D-LUT created with a Resolve ACES 1.1 setup. These are the processing steps:

  • ACES to ACEScg conversion in the read node
  • OCIOFileTransform applies the 3D-LUT file – the working colorspace must be now set to ACEScct.
  • The result is indirect-display-referred. Therefore no compensation for the view transform is needed.
possible clipping in dynamic range and gamut

Although the result has again a seemingly good dynamic range, the gamut compression could not be fully inverted. The dynamic range is also limited to a maximum that the ODT Rec.709 allows with a value of approx. 16.292 instead of the the aprox 55.0 that LogC supports. That’s why a 3D-LUT is only good for preview purposes.

A list of maximum scene linear values that are supported by different log encoded formats can be found here.

To show the loss of dynamic range I use another image that I created for another article.

Nuke generated ramps from 0-64 in the topmost stipe and each stripe below is reduced by 1-stop or half the amount. The moment is was written out as a LogC dpx file the values about 55.000 got truncated.
ACES (Rec709) View Transform of the ramps in stripes from 0-64 with a red color indicator showing that the LogC dpx file could not handle values higher than 55.000

That is a good example showing why ACES image data needs to be saved as EXR files. Let’s see what happens when I pass this file now through the ARRI ALEXA default LogC to Rec.709 3D-LUT.

The same image with the default ARRI ALEXA 3D-LUT LogC to Rec.709 applied. The green indicates the clipping occurs now at a value of 16.292
ACES Rec.709 view transform (RED) vs. a 3D-LUT applied midstream in the ACES pipeline before the RRT & ODT is applied.
Nuke steps: ACEScg–>LogC–>apply 3D-LUT–>Rec.709–>ACEScg

A second example I made with my ACES ColorBars. The brightest red, green and blue patches have color values that are far out of gamut from Rec.709. That’s why these values cannot be retrieved after a 3D-LUT was applied.

If you want to know why I created the ACES ColorBars in the first place. Please follow the link.

My ColorBars for ACES – Left: ACES to Rec.709 – Right: 3D-LUT LogC to Rec.709 applied before the RRT&ODT.
The problems are even more visible on the ACES ColorBars that I created.

The color management of flame is even more open and flexible than the one of Nuke. But this means you need more manual steps to end up with the same result. But the main steps are the same of course. I start with the same ungraded open EXR image sequence as I did in Nuke. In the Media Hub I chose the method Auto-Convert by rules to import the image sequence. The images are converted to ACEScg, and the viewer is again ACES Rec.709.

I wrote another article on the different methods that flame offers when ingesting data. Please find it here.

Ungraded Clip F003C008 exported with a baked in ACES Rec.709 ODT.

The difference in flame in comparison to nuke is that I need to begin the steps with a color primary transform from the working colorspace ACEScg to ACES and back again to ACEScg from ACES at the end.