Working Around The ACES ‘Look’ With OpenDRT

September 9, 2021

ACES is an extremely popular color management pipeline but its RRT can impose a ‘look’. In this Insight learn about OpenDRT & how to implement it.


Using The OpenDRT DCTL As An Alternative To The ACES RRT

ACES is an amazingly powerful color management system, but the creative ‘look’ in its RRT (Reference Rendering Transform) may not be the right fit for all projects.

So how can we as colorists take advantage of ACES’ excellent workflow, including the IDTs (Input Device Transforms) and ultra-wide-gamut working color space, while avoiding the RRT?  Enter the open-source OpenDRT (Display Rendering Transform) project, created by color scientist Jed Smith.

I stumbled upon OpenDRT in a thread on ACES Central about LMTs and dealing with the Helmholtz-Kohlrausch effect (The thread is definitely worth a read – cool stuff, and deserving of a future Insight).

The project has been around for a while, so I was a bit surprised that I hadn’t come across it before.  As it turns out, OpenDRT is a very capable display transform that has a really nice feel while grading.  It feels very neutral and logical, and I find that I can place colors where I want them without fighting some of the tones I sometimes get with the stock ACES RRT.  And since it was new to me, I figure it might be new to a lot of you as well!

OpenDRT Project Design Goals

    • Simple – Simplicity of design
    • Robust – Handle extremes without breaking
    • Neutral – No strong look, no creative intent, faithful to input image colorimetry
    • Chromaticity Preserving – Faithfully represent the chromaticity values of the input image
    • Information Preserving – Preserve as much data as possible from the input image
    • Invertible – Can operate in the forward and inverse directions within the limitations of display-referred imagery
  • Look Not Included – Intended to be used in conjunction with a look transform upstream

A Modern, All-Purpose Scene-Linear Display Transform

Technically, OpenDRT can be used as a display transform for rendering almost any wide gamut scene-linear images to either SDR or HDR displays, not just ACES.  But with its simple, robust and neutral nature, its a very useful replacement for the ACES RRT.

In this Insight, I’ll go over how to implement the OpenDRT DCTL in a node-based ACES setup inside Resolve.  Then I’ll compare OpenDRT to the ACES RRT on a wide range of ACES EXR frames to illustrate the types of footage where it might serve as a better starting point for grading.

Work-In-Progress! An Open-Source Warning

As indicated by the commit history on GitHub, OpenDRT is still a work in progress.  Jed is still working to refine how the transform works, and is updating OpenDRT frequently.

Therefore, I offer this warning:  Don’t use OpenDRT on projects you’ll need to remain stable and consistent for any length of time.  There’s no guarantee that a project graded using OpenDRT would look the same after installing a new version of the DCTL down the road.

Download

Here’s the OpenDRT GitHub link:

https://github.com/jedypod/open-display-transform

Installation

Installing DCTL files is as simple as installing a LUT.  In fact, they go in the same folder!  Once you’ve downloaded the archive, copy the DCTL files into your LUT folder and restart Resolve.  The new DCTLs will be available in Resolve’s DCTL OFX plugin.

Here’s a link to the installation instructions if you have any issues:

https://github.com/jedypod/open-display-transform/blob/main/docs/doc_installation.md

Test EXR frames

In this Insight I use a few of the great ACES EXR frames that Jed Smith has compiled for testing OpenDRT.  Each of these clips is a single frame to make for smaller downloads, but otherwise are still 2K 16-bit ACES AP0 linear EXRs.  Here’s the link to the description and download repository:

https://github.com/jedypod/open-display-transform/blob/main/docs/support_footage.md

Comments & Questions

Looking forward to hearing if you think OpenDRT is an option for some of your grading projects!  Leave any comments or questions below..

-Peder

Update 10/7/21

Jed Smith, creator of OpenDRT, spotted that I had a input gamut mismatch on the last two shots I demoed in the Insight video.

I had assumed they were encoded as ACES AP0 Linear, but they are in fact Arri Wide Gamut Linear.  The fix is as simple as changing the Input Gamut setting on the OpenDRT node to match, so if you’re following along make sure to set the correct gamut for those shots.  It makes a big difference.

You can read Jed’s note below in the comments section.

Member Content

Sorry... the rest of this content is for members only. You'll need to login or sign up to continue (we hope you do!).

Membership options
Member Login

Comments

Homepage Forums Working Around The ACES ‘Look’ With OpenDRT

Viewing 18 reply threads

    • Jose Santos
      Guest

      Hi Peder,

      Great insight!

      Couldn’t use the openDRT DCTL with Project level ACES by setting the ODT in the project settings to AcesCCT?


    • Peder Morgenthaler
      Guest

      Thanks Jose!

      I’d have to test it, but since the RRT is applied before the OT in project level ACES, I think you would just be baking the results of the RRT into an ACES CCT image.


    • Jamie Dickinson
      Guest

      Very interesting. How does this whole thing compare to the project level DaVinci Color Managed vs ACESct, it seems like a very similar result to what you have there. I know some clients insist on an ACES pipeline but if not you could just use DCM and you’re in the same place as with your DCTL?


    • Peder Morgenthaler
      Guest

      Great question. I went ahead and tested it, and the results are interesting enough to share here:

      https://uploads.disquscdn.com/images/4e6b96958ccbd8677a6ce5af044d1ff1ecae14bf2b21fe60822cd6557df527ab.jpg

      https://uploads.disquscdn.com/images/083245beaa563f32bd6bf07ff164485dba32aa3e8279213030d04a451735d981.jpg

      https://uploads.disquscdn.com/images/de8036d88b694c38dec21e6322c5a77947de2263032758432867701c760b6540.jpg

      Based on this, it feels like RCM splits the difference between ACES RRT & OpenDRT, both in terms of contrast and color. Notably, RCM exhibits the same highly-saturated highlights in the bulb filaments as ACES. Each DRT has its own character, and you might choose any of them for different jobs. For this image, I think I personally prefer the OpenDRT version as a starting point.

      I don’t have any experience on Baselight, but Cullen Kelly said OpenDRT feels a lot like the TCAM DRT, which is interesting.


    • andi winter
      Guest

      thanX! big time.


    • Maciej C
      Guest

      First of all great tutorial. But I have some issue that I don’t know why is happening. I’ve got quite recent version of open DRT (from yesterday), and I found out that it gives me big saturation and hue shift (towards red) prior to any color correction applied. I’m using Joey D’Anna custom ACES node tree. So to be precise, my first node is CST from Slog 3 to ARRI LOG C, no tone or gamut mapping. Then, the tree is identical, with ACES transform from Log C, and lastly from ACES cct to REC. 709. But when I change the last node for DCTL and open DRT (input gamut: ACES, curve: ACEScct, and preset rec 709) there is this saturation boost and hue shift towards red. What could be the issue here?


    • Scott Stacy
      Guest

      Nice test. Much appreciated. I really like RCM – especially, when using BMD cameras. I have often drifted away from ACES, but I think in the case study noted above, I like the skintones better with ACES OpenDRT than RCM.


    • Peder Morgenthaler
      Guest

      I ran into the same issue last week!

      It looks like there’s a difference in how OpenDRT interprets the ACES AP1 color gamut for input gammas other than Linear. I’ve had success limiting the OpenDRT input gamut to the one I originally converted into ACES. In this case, try setting the OpenDRT input gamut to Alexa Wide Gamut or Sony SGamut3 while keeping the input gamma ACEScct . Its a bit of a hack, but yields a more predictable result.

      Edit: This is the wrong approach. See my AP1 -> AP0 conversion solution below.


    • Maciej C
      Guest

      Thanks Peder. I hope the issue will be addressed because I was really pleased with the results you presented in the tutorial.


    • Peder Morgenthaler
      Guest

      After a bit more exploring, and reading Jed’s documentation a bit more closely, I found the issue.

      OpenDRT is expecting an input in ACES AP0 colorspace. The Resolve ACES Transform plugin doesn’t have a “colorspace” option, but changes it depending on the Output Transform you select. When set to CSC – ACEScct, it uses ACES AP1 as the colorspace (which it should.). To get OpenDRT to work here, put a CST node right before the OpenDRT node to convert AP1 to AP0:

      https://uploads.disquscdn.com/images/1413193431ef0057134e67d1d687eaca24225b3b8d2d4c9eb74ece4b035243d7.png

      With that applied, OpenDRT is working properly and looks exactly like I would expect. To make it cleaner, you could combine the CST and OpenDRT nodes into a Compound Node.

      Thanks for motivating me to find a fix!


    • Maciej C
      Guest

      Thanks again Peder. That’s a great work you did! Now it works great.


    • Diego B
      Guest

      Great tutorial!
      I think it’d be really usefull the ability to export the OpenDRT settings as a lut for onset monitoring.


    • charles w rodriguez
      Guest

      I’ve been really playing with this DCTL. It’s a pretty good, all around, ODT for a variety of timeline standards. It’s missing the tonal adjustments of a Resolve CST, but, tht can be compensated with the Tone and saturation remapping plugin.


    • Jed Smith
      Guest

      Thanks for the review of my project. It’s very interesting to hear colorist feedback. I haven’t gotten much comments of this type on the acescentral forums. I guess we’re a bunch of nerds over there, and maybe there’s not enough artists 🙂

      The last two images you showed in your demo have the wrong input gamut. They are from the Stuttgart VM Lab test image set, which are encoded in Arri Wide Gamut Linear. This is noted in the folder name in my dropbox, but it’s probably not obvious. Sorry about that.

      A simple fix for this would be to set the input gamut on the OpenDRT node to Arri Wide Gamut.

      For the record OpenDRT also supports non-linear “gamma” if you change the “input curve” to something other than linear. For example if you are working with ACEScct input footage, you could just set the input curve to ACEScct and it should work properly.

      Be cautious of the “Tone mapping method” in the Resolve Colorspace Transform node. It does more than convert the gamut…

      I am working towards a more feature and rendering stable 0.1 release. Right now as you said the project is pretty experimental.


    • Peder Morgenthaler
      Guest

      Hey Jed! I’m glad you’re finding the feedback here useful. Thanks for your great work on the OpenDRT project so far! I think it’s resonating with a lot of us colorists looking for different transform options. Some of the pieces I’ve graded recently have really benefitted.

      Thanks for letting me know about the setting mismatches for those shots. I missed the encoding on the folder names, but it makes total sense in hindsight. I’ll add some notes to the Insight text to let people know. Also, thanks for the heads up about the tone mapping method in the CST node. I’ve been suspecting that was the case for a while, so its good to get confirmation.

      I think we’ll all be looking forward to seeing where you land for the 0.1 release. There are so many interesting color science decisions that go into a rendering transform like this, and I’ve been enjoying the watching the process unfold over on ACESCentral.


    • Tim C
      Guest

      Hi Jed
      I’m finding OpenDRT a pleasingly neutral start in ACES projects – thank-you for sharing your work! In the projects where I am not using any form of colour management (e.g. Resolve plain YRGB projects) would there be any benefit in using OpenDRT for raw footage – or simply let Resolve do its own auto input transform from camera metadata? If so, what would be the best way to set this up? Thanks again.


    • Pat Inhofer
      Guest

      One way I think about this: At the start of a project, pull a few ‘hero shots’ and a few of the most problematic shots (the client usually has a good idea of both when they walk in the room). Then do a quick pass using RCM and a pass using OpenDRT and see which version gets to results your client likes in the quickest way possible.

      In my experience, a process that works great for 80% of my jobs also makes my job harder on 20% of my jobs. And it’s tough to know which of my workflows will work best without actually testing those workflows on each particular job. So pull a few representative shots on both ends of the spectrum and then decide how to proceed. My quotes always factor in a little bit of time for this type of decision-making.

      HTH.


    • Tim C
      Guest

      Thanks Pat. Good advice!


    • Zachary H
      Guest

      Any chance this website could have a switch we could use to turn everything dark. The white background is always so bright in my color suite. I’ve tried dark mode and the Apple Dark appearance setting to no avail. Noir helps but the outer borders are still glaringly white. Even a middle gray would be better. Just a thought! 😉

Viewing 18 reply threads
  • You must be logged in to reply to this topic.

Hundreds of Free Tutorials

Get full access to our entire library of 900+ color tutorials for an entire week!


Start Your Free Trial
Loading...