As a Shake user, I learned to love the explicit image processing organization that node-based compositing afforded. Never mind trying to figure out which precomp corresponded to what part of the composite; one look at a well-organized node tree and you can see exactly what’s going on.
Furthermore, once you get the hang of using nodes, you can begin to work out your order of corrections in advance in a classic programmer’s tactic; flowchart your way through a complicated series of operations in order to think them through, except in this case, the flowchart is also the result!
I’ve been discussing node based operations with my friend and colleague Robbie Carman, who’s another DaVinci Resolve beta user, and in the process thought that it might be interesting to share some of my favorite operational aspects of Resolve’s method of node-based correction organization.
#0—A Quick Orientation
Similarly to the node-based Color FX room of Apple Color, node-based corrections in Resolve aren’t for the actual compositing of multiple images with one another. They’re for organizing and combining the different corrections you want to make to your image. Before I dive in, here’s a quick overview of how Resolve uses nodes.
Every clip has a corresponding set of corrections within a “Clip” tab. This tab is Resolve’s node view, where each correction is represented as a rectangular node, with a single input and a single output, which can be seen as little yellow dots to the left and right of each node.
The flow of image data goes like this: The left-hand bar is the source image on Disk. Connection lines (with small directional arrows) feed image data to the first node in the tree, represented by a thumbnail showing what that node is up to (literally; the correction performed by each node is represented by its tiny thumbnail if your eyes are sharp enough). Connection lines also connect each node you use to one another, feeding image data down the line until the last node is connected to the right-hand bar, which represents the final output.
#1—Organizing My Image Processing
In a very real way, a serial cascade of image processing nodes like that shown above is like a stack of filters in After Effects, Final Cut Pro, or Avid. The output of the top filter feeds the next one in the stack, and so on until you reach the bottom.
You can think of nodes as a similar series of image processing operations. More poetically, you can think of nodes as individual waterfalls along a stream of image processing. Each waterfall alters the flow of data, which in turn feeds the next part of the stream, until you reach the end.
The key thing to remember is that, depending on what type of image processing operations you’re doing, your order of operations matters, a lot. One of the most frustrating things about working in Color is the occasional instance where I discover my order of operations isn’t quite right, usually after I’ve done several corrections. For example, let’s say a primary correction (the first node seen below) blows out the highlights in the sky.
I don’t really care until my client complains, but then I can’t retrieve it using a secondary correction (the second node in the tree above) because the image data is already clipped. As a result, my secondary HSL Qualifier only succeeds only in creating a bizarre darkened area in the sky:
When using Apple Color, my solution in these cases has been to save the Primary correction to the bin, reset the Primary In room, open the Primary Out room, and apply the correction that I saved there, effectively swapping the PI and PO rooms. At that point I can use a secondary of some kind to lower the highlights before I boost the rest of the shot, and so I get to preserve maximum image detail.
In Resolve, this is an even easier operation. All I do is either add a node with which to perform a secondary sky isolation operation before my primary correction (or, if I’d already tried a later secondary correction with no success, swap the two node’s positions in the tree).
This allows me to isolate and duck the levels of the sky before boosting the overall levels of the shot in the next node. The result is smoother, more natural, and preserves all the image data that’s available, which is always a bonus.
This gives me exactly what I need in terms of image processing organization. Now, I grant you there are several other ways of dealing with this particular scenario, but the point is that, using nodes, I control the order of operations, not the application.
Here’s the other nice thing—you can use as many nodes as you like to organize your grades. I like to keep significant operations within separate nodes, so I know where I need to go when I want to make an alteration. That means I might have one node doing a basic corrective grade, a second node adding a bit more warmth and contrast for stylistic effect (as I’ve done in node 3 of the previous example), and then a third node where I add a perhaps questionable alteration that was requested by the client, that I think they might backpedal on later. I could have done the entire series of operations within a single node, but by keeping these three operations separate, I’ve got more options regarding which aspects of the grade I want to continue tweaking, and which I can turn off entirely without affecting the rest of the grade.
#2—Serial and Parallel Organization
So that’s fun with serial node organization. However, Resolve also has Parallel node organization. This is another way of putting nodes together, so that instead of having a single long tree branch, you can stack up simultaneous corrections whereever it makes sense. For example, if you’re planning on using three secondary operations to affect an image at once, you could apply them as a serial operation, like so:
Or you could apply them as a parallel operation, with three stacked nodes feeding a Parallel node.
Resolve overlays the corrections to produce the result you’d expect, and the tree organizationally makes a lot more sense. However—and this is a big deal—the parallel node structure ensures that each secondary correction node samples the same version of the image. This is important, because I like…
#3—Choosing What My Key Source Is
This one’s easy. Remember I mentioned that the leftmost bar in the Clip tab represents the original state of the image? Well, if you’re adding a secondary operation via a parallel node structure, you can choose whether you want to pull your key off of the original state of the media, or from a particular node of the tree, simply by connecting that node’s input to the source you want to sample.
For example, suppose my look for the primary correction performed by node 1 results in a high-contrast, low saturation image.
If I wanted to add a second node and use HSL qualification to boost the color of the dress, I could do the simple thing and add another serial node:
Unfortunately, the image is so desaturated and stylized that it’s really difficult to pull a decent key. Here’s an example of my first sampling click:
Even though node 1 is doing what you want it to, the result is that the image is in a crummy state to have to pull a key off of.
However, there’s a better solution, which is to use the parallel node structure described previously, connecting the input of node 2 that’s pulling the key to the media source bar, instead of the previous node:
Now, using the original state of the media, it’s easy to pull a great key. Here’s an example of my first sampling click using this new node structure:
Now that we can get a better key, it’s easy to manipulate the color of the dress however we like, and then feed it back into the image.
So there you have it, complete control of image sampling, all through the power of selective node connectivity. I love me some nodes.
Photography by Kaylynn Raschke. Special thanks to Gal Friday and Sasha Nialla for modelling. Images excerpted from my new book, Color Correction Handbook: Professional Techniques for Video and Cinema.