Understanding How Pat Designs His Fixed Node Trees In DaVinci Resolve

Inside Pat’s Color Grading Head – The Evolution of His Fixed Node Tree

January 3, 2020

Learn the benefits of a 'fixed node tree' in DaVinci Resolve. Get a look inside one colorist's node tree - and how it evolved over time.


Series
Day 3: 24 Insights In 24 Days – 2020 New Year Marathon!

How Pat’s Fixed Node Tree Has Evolved Over Time

We’ve talked quite a bit about using fixed node trees in DaVinci Resolve. The ultimate goal is to increase your productivity while color grading and keep you more focused on your reference display (and less focused on Resolve’s user interface). If this concept is new to you then here are a few Insights you should look at first:

Over time, my node tree has evolved quite a bit.

I started simply with a skeleton of a tree. As the jobs rolled on, I started rebuilding it – added in new areas of the node tree where I kept finding it necessary to ‘Add Node’ while working with a previous version of the tree. With each new version, I’d reorder some of the nodes, as I became more self-aware of how I prefer to group and order my operations.

In this Insight, you’ll learn how I initially approached building my node tree – and where it is today. The basic structure is still there – but there’s much more granularity in my trees (reducing the time I spend fiddling with buttons and knobs in the user interface).

I also offer a quick demo on the benefits of a fixed node tree as I turn on, modify, and then disable a Noise Reduction node across multiple shots with a single command.

Enjoy and leave comments below!

-pi

Member Content

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

Need more information about our memberships? Click to learn more.

Membership options
Member Login

Are you using our app? For the best experience, please login using the app's launch screen


Comments

Homepage Forums Inside Pat’s Color Grading Head – The Evolution of His Fixed Node Tree

Page 1 of 2

  • Jordan M
    Guest

    NICE!


  • Scott Stacy
    Guest

    Nice arrangement. Over the years, I’ve collected around 6-7 different node trees from various folks, but this one has some nice touches – like the white and black point and others. Thanks for sharing.


  • Marc Wielage
    Guest

    Yes, terrific as always, Patrick. Three comments: 1) it’s really tough to use Fixed Node Trees on smaller panels because you don’t have a button that jumps to a specific Node #. The Advanced Panel has that, and that’s a big sales point for me. 2) You learn quickly that you need a TRIM node towards the end for client-dictated changes; there are colorists (like Walter Volpatto of EFilm) who actually have 3 Trims: one for the DP, one for the Director, and one for the Producer. And 3) I would suggest using the Gamut Mapping plug-in to limit chroma excursions for Rec709 projects: knock the Saturation Maximum down, and it does a gentle job of limiting that’s not as noticeable as the Sat curves. But great thoughts: I want to create a new Fixed Node Tree for 2020 (the year, not the color space), and this has given me some new ideas. Always great to see how other people work.


  • Marty
    Guest

    Nice insight. It’s always interesting seeing others fixed node graphs.

    Have you run into the issue of NR slowing down with large node graphs? I’ve found that the more (disabled or not) nodes I have in a graph the slower NR will render. I might have 12 disabled nodes and playback with NR isn’t real time. Then if I delete instead of disabling those nodes, all of sudden playback jumps a few fps faster. Sometimes it’s the difference between real-time and not realtime.
    I usually do NR as the first node so I can node cache if I need to and work quickly on top of that. Maybe the NR node position matters???

    Just wondering if you’ve noticed this issue.


  • Pat Inhofer
    Guest

    Marc – Yes! Gamut Mapping. Thanks. I’m making that change right now. You’re correct, using the Sat v Sat Curve as a legalizer can introduce artifacts and I tend to not turn it on, as a result.

    Trim nodes for client notes is also a great idea. I’ll have to figure out where to include that. I tend to just Version out so that if I need to revert I switch versions. The client trim node is a good workflow tip.

    RE: Prev. / Next Node buttons – Those buttons became mappable via keyboard shortcuts a few years ago. So if you’re mouse-based that’s one of the first shortcuts I’d add to my Custom Keyboard mapping. It’s a great shortcut to add to a StreamDeck or other gaming pad.


  • Pat Inhofer
    Guest

    Definitely, there’s something to your observation. I was playing with that earlier this week. On my next job I plan on keeping the NR node blank until I’m ready to enable it – then add it in, ripple to all shots, and turn on the render cache (for real-time playback).

    Robbie mentioned to me last night that he has some tips on performance killers in large node trees. I’ve asked him to turn that into an Insight!


  • Robbie Carman
    Guest

    yea, I def. experienced bad performance on large trees, it recently caused me to trim my tree quite a bit to get down to really just the stuff I’m using on a day to day basis.

    I know of 4 things that dramatically kill performance in large trees (a disabled NR node is not one of them btw @pat) I think now that Joey, and Pat have broken down their node tree I’m going to do the same in a follow up Insight.


  • Robbie Carman
    Guest

    Direct node selection is possible via Streamdeck. It works great and just as fast/easy as on the Advanced panel (I have both setups).

    Def. need trims but I have them both pre-transform and post transform.

    Interesting on the gamut mapping, I’ll have to compare that setup vs what I do know at the end of my tree with a softclip node.


  • R Neil Haugen
    Guest

    Two things … first, interesting your LUT node is shifted to the backend. Second, it is also interesting to watch your working setup change over time. That “desk” is very different from even a year ago.


  • andi winter
    Guest

    which gamut mapping plug-in do you refer to? knock sat max down? how does this method work exactly?


  • Pat Inhofer
    Guest

    The pushing of the ‘LUT’ node back is an experiment for me. So far, so good.

    RE: Desk – I think the main difference from last year is the Wacom. I really enjoy it. HT to Robbie for getting me back on it.


  • Jan K
    Guest

    I was just updating my tree template with ideas from this insight. A few options to consider:

    On the LUT node at the beginning (borrowing some ideas from the Standard Candle Benchmark), it’s useful to use versions for alternate setups of a function. On the LUT node version 1 can be the LUT for the input color space, while version 2 can be the color space transform. That makes it easy to see which one does better one a given shot.

    Along those lines, labeling it ‘Input CSX’ and then having a matching ‘Output CSX’ behind the final NR node allows the same tree to be pivoted between scene and display referred by simply enabling/disabling nodes based on project needs.

    Lastly, I like keep a pre-configured key segment. In my case it’s a ‘Pre Key’ node that reads from the input LUT node. This can be contrast/NR pre-treatment for a difficult key as needed. It then splits into Key 1 and Key 2 that combine into a key mixer. That mixer then feeds the key input on ‘Fix 3’. It’s easy enough to move the input of the ‘Pre Key’ if you want to key pre-LUT. And the output of the key mixer can quickly be moved between Fix 1/2/3 as needed. I find I way too often build my key section manually. So this is a good improvement.

    One useful trick to keep your trees smaller – come up with a core tree. Then create a few segments (like the key segment) and save them as separate power grades. It’s easy enough to pull them in as needed and hook them up. Of course that messes with node numbering for the add-ons making rippling harder, so there is a fine line. As along as the core tree has everything that may need rippling, that keeps at least that part consistently numbered.


  • Jean-Francois R
    Guest

    I also have an ever-evolving fixed node tree. Right now, it goes like this:

    – Noise Reduction
    – Printer Lights
    – Log adjustments
    – LUT/CST
    – Qualifiers (2 in parallel)
    – Global controls (all in parallel: curves, temperature, LGG, secondary, LAB)
    – Client trims
    – Windows (2 window nodes in parallel, each with an outside node)
    – OFX node (could be anything really, sometimes I add additional ones)
    – Vignette
    – Limiter/Legaliser

    Order of operations:
    First, I apply the fixed node tree that already contains the correct LUT or CST. Then I jump to the pre-LUT nodes: first Printer lights, then Log controls. This gets me in the right ballpark. Typically, I won’t go back to these nodes after the initial setup.

    Next are the global adjusments: custom gamma curve, temperature, LGG.

    After that, it’s secondaries (vs. curves), qualifiers, windows, OFX, etc. as required. I don’t mind adding additional nodes if I need more OFX plugins for instance.

    QUAL:
    Typically for skintones or sky. The qualifiers are after the LUT, so that the HSL key can be extracted from the normalized image. But I keep them before my other adjustments so that these adjustments won’t affect the key either. I hate having to go back to a key because some other adjustment broke the selection.

    Noise Reduction:
    I used to put the NR node as the first node, in order to take advantage of caching, but I recognize that it’s workaround. I’m now experimenting with putting the NR node right after the LUT. Because I don’t usually go back to my pre-LUT nodes, this still lets me take advantage of caching.

    Client Trims:
    I keep a few client trim nodes. If I get comments from multiple people then each will get their own node (I add nodes as required). I will also add trim nodes with each further revision. That lets me easily toggle the latest changes on/off. If a revision needs to go into another location of the node tree, then I’ll add a trim node where required.


  • Pat Inhofer
    Guest

    Jan,

    More good ideas in here. I’m going to think more on having a core tree and then adding extensions with Power Grades. It’s a good idea.


  • Pat Inhofer
    Guest

    Jean-Francois – Great stuff! Really well thought out. Yeah. I may add that NR node earlier in my tree. On 4K timelines it really slows things down when it’s constantly re-caching. I’m still iff’y on Log controls. The band between tonal ranges always feels so narrow to me. But in these color managed workflows, they are useful.

    Thanks for sharing your workflow!

Page 1 of 2

Log in to reply.

1,000+ Tutorials to Explore

Get full access to our entire library of over 1,100+ color tutorials for an entire week!


Start Your Test Drive!
Loading...