OpenDRT : a cool alternative to ACES

Who's this for ?

My post mainly targets the VFX-CGI audience but OpenDRT work on any open-domain data (see also wide-dynamic-range, scene-linear); which includes photography and cinematography.

You should be familiar with a "scene-linear workflow":

render (.exr) -> compositing/postprod (linear) -> display output (jpg,mp4,...)

OpenDRT implementation is only available as a Nuke Gizmo and through Davinci Resolve DCTL feature (on paid licenses) which imply you are using one of these dccs.

No OCIO support, this means you will have with your traditional workflow in your rendering DCC and only be able to preview the final image in your post-prod one which is not the most ideal workflow.

With all of that, I consider my post to be aimed at individual artist doing personal projects that would like a quick solution for proper SDR-HDR export (not implying these are OpenDRT goals).

Introduction

It's always a good idea to read the official documentation, the author explain it best isn't it ? So have a look at the tool repository first:

Let's just remind the target of OpenDRT:

The tool has for goal the faithful conversion of open-domain data to a closed-domain : the display. This implies its output can look very neutral and should be graded.

Node Overview

As the tool is constantly changing, Jed's documentation is not up to date, and tneither this post will be.

The first option is to tell the tool in which gamut your input is. The input is expected to be linearly encoded.

You then have a bunch of presets that will tweak the knobs for you based on your target display encoding.

Lw : this is the nits level of the target display and shouldn't be used as a creative adjustment.

surround : the luminance level of the viewing environment.

• dark : theatrical viewing environment.

• dim: "home theater" (low light condition).

• average: desktop/office average surround.

dechroma : this one is more "subjective", allowing to control the amount of chrominance compression that should be applied on values reaching display maximum (R,G,B=1.0). If HDR imagery needs to be produced, this can be lowered (as the target domain (hdr) has more volume to express chroma)

saturation : Expand chroma on the bottom values after the compression by the dechroma. See more here .

whitepoint : (from doc) Sets the creative whitepoint. This allows you to creatively set the whitepoint of your display rendering if you want it to be different than the technical whitepoint of your display device. For example, if you set this to D55, neutral colors will be rendered as a warmer hue compared to the default D65.

display encoding : see below explanations

• The eotf should correspond to the transfer-function used by the targeted display.

• The gamut correspond once again to the gamut that the targeted display is calibrated to (reminder that sRGB use the same gamut as Rec.709).

To adjust these settings properly you have to know the targeted display + user :

The issue is that with today range of displays, this is a rather difficult one to average (until you have the full-control on the display the image is going to be viewed on).

So for now, using the presets is, I think a good practice.

Nuke Installation

1. Download the .nk file (Right click on the page > save as > save it somewhere)

2. Import the .nk file: File > Insert Comp Nodes

Or alternatively :

1. Open the .nk file and copy all of his content (ctrl+a, ctrl+c)

2. Paste in Nuke (ctrl+v)

Usage in Nuke

Things will now get a bit complicated at first. The issue is that has the OpenDRT handle the scene -> display conversion, this will collide with Nuke that try to do the same in the view-transform.

I found 4 different solutions that achieve the same result. I think the last one is recommend to use but it's good to have other example that might help to understand how everything works.

#1 Revert Display

We let the DRT handle everything (with display-encoding), then we apply the invert transform that applied by Nuke:

Writing the data is as before. You just have to be sure that the Colorspace node has the same in parameters as the colorspace one on the write node.

#2 Nuke Display-encoding disable

We disable Nuke's handling of the display-encoding. The DRT is the last step.

This means the Nuke view-transform is always off which can be incovenient when you need to preview a node upstream.

#3 OpenDRT no Display-encoding

One good solution: the OpenDRT doesn't handle the display encoding but output closed-domain data ready for the display. Nuke apply the display-encoding as usually, writing data is the regular workflow.

Be careful as OpenDRT still handle the gamut conversion from the input to the output. Write node colorspace need to be choosen with this is mind.

#4 OpenDRT with Viewer Input Process (recommended)

This is probably the best solution;

OpenDRT handle everything, we disable Nuke view-transform but we will be using its input process feature.

This will allow to always have the OpenDRT active no matter what node we are previewing (this can be inconvenient when viewing scalar data like alpha, think to disable the input-process in that case).

We don't actually need the node used as input-process to be connected to anything but here I'm making sure it's connected before the write node, so OpenDRT get baked in at export.

As OpenDRT handled the display encoding we can turn it off on the write node by checking raw data.

Conclusion

If you tried to compare the result to an ACES processed image you would have probably notice that the image-formation produce much more "excepted" result, among others, in strong colored highlights, which make OpenDRT a solid candidate at better image-formation and a peak of what could be used in the future.

Even if it's current form kind of break the purpose of a consistant color-managed system across DCCs, it is a nice solution for individuals and looks very promising.

⭐ Make sure to star Jed's repository on Github !