Working Around The ACES ‘Look’ With OpenDRT

Hi Peder,

Great insight!

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

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.

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?

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

https://uploads.disquscdn.com/

https://uploads.disquscdn.com/

https://uploads.disquscdn.com/

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.

thanX! big time.

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?

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.

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.

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

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/

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!

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

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

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.

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.

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.