Custom ACES Part 4: Updating For Resolve 17

January 10, 2021

Watch colorist Joey D'Anna update his custom ACES workflow to better use the new HDR tool in Resolve 17, and use DaVinci Wide Gamut colorspace


Series
Day 10: 24 Insights in 24 Days New Year Marathon

Updating My Custom ACES Workflow

I’m a huge fan of both using a fixed node structure and building my own custom ACES pipeline in the Resolve node tree. I think the flexibility of custom ACES, along with the speed and utility of a fixed node tree makes for a compelling workflow.

Now that Resolve 17 is out in public beta – with all-new, color space aware grading tools and improved color management across the board – I didn’t want to just sit around and leave my workflow unchanged, but I also didn’t want to throw it all away and start fresh.

So in this Insight, I’m going to go through my thought process in updating my fixed custom ACES tree to better work with the new HDR grading tool – and I’m also going to show an ACES-alternative version that uses the new DaVinci Wide Gamut colorspace.

Grading In DaVinci Wide Gamut

One of the most interesting updates in Resolve 17 is the introduction of the DaVinci Wide Gamut colorspace. In gamut, it is very similar to ACES – so the same idea of transforming to, then grading in, a wide gamut space and subsequently transforming into the display space also works very well with DaVinci Wide Gamut, and Resolve color-managed projects. But I wanted to take it to another level and see if I could apply the same techniques of building the color management pipeline in the node tree – and sure enough, it works great!

So if you haven’t watched my series on fixed node trees and custom ACES – it may help to have a look at those first, but in this Insight I’ll cover:

  • Modernizing my custom ACES node tree
  • Manual HDR tool color space settings
  • HDR tool order of operations
  • Converting the custom ACES tree to use DaVinci Wide Gamut instead of ACEScct

As always – leave any comments or questions below!

-Joey


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

Additional Downloads

Sorry... downloads are available for Premium Members only.

Become a Premium Member

Comments

Homepage Forums Custom ACES Part 4: Updating For Resolve 17

Viewing 13 reply threads

    • Evan A
      Guest

      Hi insight J! I have v17b6 on a MBP to play with I’m starting to re-build my node tree for v17. I’m trying to anticipate workflow. What are your thoughts on using the regular Color Wheels vs. the HDR wheels. I’m mostly asking about a SDR project. Do you think there is merit in using Reg CW first as a “base” then HDR CW after? Or just HDR CW?


    • Joey D’Anna
      Guest

      Yea that’s how ive been having the best results – but its important to mention I’m doing it as a way of speeding up the workflow by not having to adjust the HDR zones by normalizing the image before the HDR tool.

      You can get the same results by defining the zones yourself – but doing that shot by shot can be a big hassle


    • Gabriel M
      Guest

      Hi! Been playing around the DRXs you’ve provided, I have a question: Is there any difference between change the color space and gamma via node vs via Zones Panel? Or is it just another way of doing it? I see some cases added on the node instead of the zones panel.


    • Joey D’Anna
      Guest

      Hey Gabriel! I haven’t seen much benefit in change the node colorspace in this workflow. It doesn’t really seem to do much except maybe make the controls feel a bit faster.

      This could change as R17’s beta matures, but as it stands now unless you are in a color managed project, the only way to manually set the HDR tools default ranges is with the 3 dot menu in the tool – i dont think it takes the ndoe colorspace/gamma into account.


    • Stephen A
      Guest

      Hi, great insight and series. I’ve been investigating custom-ACES on a new project, and I’m getting strange artefacts using ACES Transform: mostly blue and green speckles in the deep source shadows. Any ideas what this might be? A big thank-you in advance!

      Project settings:
      . Resolve 16.2.7 (and tested with 17.b6)
      . Colour management off (DaVinci YRGB)
      . Timeline Colour Space: Rec 709 / 2.4

      Source footage:
      . Panasonic GH5 set to HLG (4k DCI, 400 Mb/s)

      IDT: ACES Transform:
      . ACES v1.1
      . Input: Rec. 2020 HLG (1000 nits)
      . Output: ACEScct

      Interestingly, if I enable a FilmConvert node upstream of the IDT, the artefacts disappear, even with all the controls of FilmConvert set to 0. The scopes don’t change much (aside from all the artefacts disappearing).

      Also, if I node cache upstream (say the NR) node, I get a different set of artefacts — including some stripes on black letterboxing around the video.

      Here’s a screenshot of the typical artefacts (no upstream nodes enabled):

      https://uploads.disquscdn.com/images/0b39c53e26de2ee9a6421139af7b7c54120d9cb5b7d686d5a91172c4dad38946.png


    • Joey D’Anna
      Guest

      Hey Stephan! Do you happen to be using a new mac pro? I’ve seen similar artifacts on mine and I think it is a bug in Resolve regarding the Vega GPUs. The exact same projects and media on my z840 doesn’t artifact at all. I haven’t tested R17 on my mac pro yet so im not sure if its fixed or not.

      I’ve found adding a very slight hard clip in curves on the shadows before the IDT fixes it. Since everything in that section of the tree is in a log space, that minor clipping doesn’t really effect anything. The odd thing is it doesnt seem to show up on most projects – i havent quite narrowed down what triggers it, so i havent been able to provide a very clear/reproducible bug report to BMD – but im working on it!


    • Stephen A
      Guest

      Hi Joey. Thanks for the reply!

      I can reproduce this on two Macs:
      . Primary: Mac Pro 5,1 / 10.14.6 / AMD RX580.
      . Secondary: MacBookPro 13,3 (2016) / 10.16.7 / AMD RX460

      I also thought of GPU issues, but if so it is more widespread than one system/combination. I can also reproduce this in Resolve16’s ACEScct colour managed project, so it clearly runs deep in the ACES implementation.

      I too have been playing with raising the blacks ever so slightly with a curve. Not the best to have to work around what seems to be a processing glitch.


    • Joey D’Anna
      Guest

      Interesting -ive tested it and seen it on my mac pro but NOT on my mac mini with an eGPU so i assumed it was a vega thing. Thanks for the info – this is really helpful as i am trying to create a reproducible formula before i submit it to BMD as a bug.


    • Stephen A
      Guest

      Cool, thanks for chasing it down! For an extra data point, same issue on:
      . MacBookPro 13,3 (2016) / 10.16.7 / AMD RX460 + eGPU AMD RX580


    • Jamie Dickinson
      Guest

      This is a great series of Insight, thank you!
      What are your thoughts on the DaVinci tone mapping and the Saturation Preserving tone mapping? It seemed that the DaVinci tone mapping was a kind of Y only tone mapping so I tried using the Saturation Preserving tone mapping and adjusting the roll off. Do you think this will get good results when adjusting exposure?


    • douglas d
      Guest

      Hello and thanks for this amazing insight!
      I’m wondering what’s the purpose of the “apply forward OOTF” box in the CST. Should it be ticked on? Why and when?
      Also does transforming camera gamuts and color spaces to Davinci Wide Gamut instead of using Aces also makes cameras match like Aces?
      many thanks! ^^


    • Joey D’Anna
      Guest

      thanks!

      The forward/reverse OOTF are new options in Resolve 17. They are for tone mapping from a display referred to a scene referred space or back – for example transforming Rec709 into LogC (reverse) or LogC into Rec709 (forward).

      For a log -> log transform like I use to transform into LogC before the IDT – it isn’t needed. The tone mapping for output is handled by the ACES transform at the end.

      This node based workflow would absolutely work with DaVinci Wide Gamut as well – and in that case, instead of using ACES transform nodes, you could use color space transforms, with apply forward OOTF enabled on the output transform at the end.


    • charles w rodriguez
      Guest

      Hey Joey,
      I’ve been returning to older MixingLight tutorials on using ACES to refresh my understanding of how to use ACES in a DIY pipeline, especially in light of the new DR17. Very little mention is ever made in any of these tutorials about the Color Settings for Timeline Working Space, I assume because the Color Setting is over-ridden when a CRT or ACES Transform node is used. Yet, the HDR+ tool has to be told what color space and gamma is being currently used. In your earlier post, you left the ColorSetting for Timeline Working Space to REC709/Gamma 2.4. Therefore you needed to manually select the color space and gamma for the HDR+ nodes when in the ACES transformed nodes. Now, I ask why you didn’t set the Settings Working Color Space to ACES. Wouldn’t that set the HDR+ node to the right Working Color Space by default?


    • Joey D’Anna
      Guest

      Hey Charles! yes you are right – you can definitely set the timeline work space to ACEScct to default the HDR panel to that space. In general I haven’t because I saved my node tree template with the ACEScct nodes manually set that way, and the LogC nodes manually set to logC.

      But you could just as easily set it to the timeline space, and then override any nodes in the tree to a different space as needed.

Viewing 13 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...