Colour Grading Issue: Node Causing Glitches

I'm having a weird glitch with a project I'm working on. It seems that my Primaries Node is causing these glitches to pop up on various clips. If I turn the node off the glitches go away, and if I dial back the settings I have on that node the glitches go away, but I can't figure out why this node is causing glitches at all.

I've attached some pictures for context:

With the node on:

#1-WithPrimariesNode.jpg (957.35 KiB) Viewed 1460 times

With the node turned off (and exposure brought up so you can see the image still):

#2-WithoutPrimariesNode.jpg (755.41 KiB) Viewed 1460 times

Node Tree and Primary Node settings:

#3-NodeTree&PrimariesNode.jpg (494.93 KiB) Viewed 1460 times

Are you sure it's only that node?
Some steps to check.

1. Remove node and create a new one manually dialing the settings.

2. Use different settings. If that helps it might be a cache bug for that frame? Try clearing it.

3. Try adding a bunch of other nodes with some parameters tweaked. If it also appears there it could be that you are running out of GPU memory giving you visual artifacts?

Otherwise I also have no idea. Good luck.

Here are the glitches zoomed in for reference.

GlitchExample2.jpg (175.75 KiB) Viewed 1389 times

GlitchExample1.jpg (211.81 KiB) Viewed 1389 times

Uhmmm.. why are you on a beta version?

Shebbe is right, remove as much of the node tree as possible to isolate exactly the node that causes that replacement(?).

And just to confirm, you're not doing anything weird with the frame rate, right? it sort of looks like a optical flow gone wrong.

What is the source material you're using? This looks like a decoding problem, not a color problem per se. My guess is that the color correction is stressing out the system and it's struggling to handle the codec. Assuming it's Long-GOP H.264, my advice would be to transcode it first to DNxHR or ProRes 422HQ, then use the transcodes for final color and see if this helps make the workflow smoother. NR is another potential source for system slowdowns: I'm not a fan of using NR as the very first node, because the reality is the correction itself can increase or decrease the noise in the signal. My ploy is to use NR about in the middle of the node tree, so that gets cached after an initial correction, but then you can add trims and windows and keys and secondaries to that without causing the system to re-cache the image.

I've long preached: keep the grades as simple as you can, particularly in the initial nodes, so that you don't wind up in the position of "breaking" the image early on and then trying to fix it in a later node. Of course, even if you did do that, it shouldn't cause the image to shatter in the way you're showing in your screen grab.

Uhmmm.. why are you on a beta version?

Shebbe is right, remove as much of the node tree as possible to isolate exactly the node that causes that replacement(?).

And just to confirm, you're not doing anything weird with the frame rate, right? it sort of looks like a optical flow gone wrong.

Ummm...because I'm a small man and therefore not an alpha?

Jokes aside, you were right about the optical flow. I had my Retime Process set to "Optical Flow" as I had slowed some of the clips down, and Motion Estimation set to "Enhanced Better".

Once I changed the Motion Estimation to "Enhanced Faster" it seems to have cleared up most of the glitches.

Thanks for setting me on the right course!