Blackmagic Forum

Trying to wrap my head around the way this aspect of serial nodes works. Let’s say you have a shot. In one node youve desaturated it and pushed the overall color toward red. In the next (serial) node you jack the saturation way up and push overall color toward blue. Never mind that you would probabiy never do this in real life; what I want to know is, are you basically just pushing the color and values of those pixels around just like if you had done all the above operations in the same node (effectively negating the red/desat with the blue/super sat? Or is it as if youd exported it after the first node, then brought it back in as a new file and added the second node’s operations to that new file/raw footage? In other words are extreme counter moves like that likely to add noise artifacts etc. or does the program ultimately know it’s working off the same piece of raw footage from the media pool and only add/subtract etc. the values it need to to get to the final result?

I understand there are certain instances where it IS destructive, like if you crushed blacks or clipped highlights in one node and then work on them in the next node, you are now working off those clipped values just like if the raw footage had them. At least I think that’s right.

From one node to the other, so internally, the processing of the RGB values is in 32-bit float so there is plenty of room for maneuvring without any noticeable rounding. If you were to export after the first node in 10-bit integer and then import and process what was in the second node the rounding would be much larger.

Exporting float 32 is possible if you, for instance, use something like OpenEXR.

Future codecs should allow floating point arithmetic, it is especially useful for encoding linear from the camera and would make log-encoding no longer a necessity.

anothercleverusername wrote:I understand there are certain instances where it IS destructive, like if you crushed blacks or clipped highlights in one node and then work on them in the next node, you are now working off those clipped values just like if the raw footage had them. At least I think that’s right.

That is true. There are good reasons to use Parallel Nodes, Key Mixer Nodes, and/or Layer Mixer nodes to avoid this problem, since that way you're dealing with corrections made from an earlier image source (or the same source) without a destructive correction.

anothercleverusername wrote:I understand there are certain instances where it IS destructive, like if you crushed blacks or clipped highlights in one node and then work on them in the next node, you are now working off those clipped values just like if the raw footage had them. At least I think that’s right.

I think it's especially true if you're using a LUT or some type of conversion on a node that in itself clips data. You don't want to apply a LUT that looks clippy and keep on working in additional nodes after that. The other way around is good though: grading through a LUT, where the LUT is at the end and you adjust the data you feed into it. That way you can control what the LUT has to work with.

On the other hand, if you just raise gain in a node and send the signal way out of bounds, you can recover it in the next node without issue. There is no clipping per se between nodes in Resolve, internally since it's that 32-bit floating point that Cary mentioned above.

Of course, this is very easy to test/verify just by using a two node setup.

Ok thanks. I’m new to all this..”propee” grading in general, Resolve, and the node based workflow. I would never have thought of grading into a LUT (not that I’m messing with them yet), putting it at the end of the chain and adding nodes before it as necessary.

anothercleverusername wrote:I would never have thought of grading into a LUT (not that I’m messing with them yet), putting it at the end of the chain and adding nodes before it as necessary.

It's not necessary. I don't use LUTs all that often since I often find them a bit heavy handed (especially "look LUTs").

But grading before them, shaping the signal going in, is just one way to control that nothing gets clipped through it — because LUTs are transformations that CAN clip the signal in the chain. You can also reduce the opacity of the node containing the LUT (reduce the output key) if you want to "fade" it.

Lot's of options.

Here is an example of good recovery between nodes.

This is the original:


Now we take it down in a node with a saturation of only 3.12:


Now we use four nodes with each of a saturation set to 100:

Very cool. I have not messed with LUTS much at all. I have only shot log once or twice and didnt edit the footage, and when I do edit (not my main thing) its (so far) exclusively on lower tier HD cams in a baked in or neutral/wide dr profile. I realize you could put a LUT on those too, as a creative decision, but assume it’s not the norm.

I tried the built in Davinci (Lite) LUTS on my footage even though it’s wide dr, and they did look pretty cool, did some really cool things with skin tones that I don’t know how to emulate without the LUT. Looks like there’s no way to tweak the LUT in Davinci? Using LUTbuddy (or something similar, only tried it once) in old Final Cut the LUTS had sliders to control various parameters. in Resolve it seems like they’re simply on or off, or like you said, on with mixed opacity, no tweaks. Would be nice to see how the LUT was created/what it’s doing to the footage, e.g. saturating this color while supressing this luminance range, etc.

anothercleverusername wrote:Looks like there’s no way to tweak the LUT in Davinci? Using LUTbuddy (or something similar, only tried it once) in old Final Cut the LUTS had sliders to control various parameters. in Resolve it seems like they’re simply on or off, or like you said, on with mixed opacity, no tweaks.

There's at least three things you can do:

1) use the Key Output control to vary the intensity of the LUT to control how much it affects the image

2) use a Node before and a Node after the LUT to control the input and output signal (and I'll give credit to Patrick Inhofer of MixingLight.com for this approach)

3) don't use a LUT at all, but instead recreate the look of the LUT manually with the controls already in Resolve. You'd be surprised how often this can work.

One key is to understand the Order of Operations with Nodes, particularly in how an extreme setting (like a key or a clip) can radically affect everything that follows. And of course, if you adjust something upstream, that will affect the Key and Clip settings to the point where they may no longer work.

Marc Wielage wrote:There's at least three things you can do:

1) use the Key Output control to vary the intensity of the LUT to control how much it affects the image

2) use a Node before and a Node after the LUT to control the input and output signal (and I'll give credit to Patrick Inhofer of MixingLight.com for this approach)

3) don't use a LUT at all, but instead recreate the look of the LUT manually with the controls already in Resolve. You'd be surprised how often this can work.

One key is to understand the Order of Operations with Nodes, particularly in how an extreme setting (like a key or a clip) can radically affect everything that follows. And of course, if you adjust something upstream, that will affect the Key and Clip settings to the point where they may no longer work.

bringing this up again. I'm trying to make a clip, done color correcting, but when I apply the LUT metode 1 don't work, what happens is that the whole picture gets faded out, not just the LUT. So at key output 0.000 the clip is totally grey.
I've tried to apply LUT to another clip just for testing but it's the same.

Why is this happening?

LUTs can be destructive.