Diamond shaped glitches with noise reduction

I sometimes get diamond shaped glitches in frames when I use noise reduction. I attached a photo to illustrate the problem. Anyone seen anything similar?

Screenshot 2021-07-11 174640.png (593.9 KiB) Viewed 1664 times

What's your GPU and the timeline resolution?

Just a random thought but artifacts of squares and similar can be produced by negative or NaN values polluting downstream operations. What is your processing before the noise reduction, including color management/transforms? Footage might need some ”sanitizing” before it hits the NR.

What's your GPU and the timeline resolution?

RTX 2080 Ti and my timeline resolution is 4K.

Just a random thought but artifacts of squares and similar can be produced by negative or NaN values polluting downstream operations. What is your processing before the noise reduction, including color management/transforms? Footage might need some ”sanitizing” before it hits the NR.

Footage is pretty standard, in this case H264 from my DJI Mini 2. Thus it should be 8-bit integral values, I doubt conversion to float from that would cause this. The processing is nothing but Resolve Color Management. The denoiser is the first node.

Do you see this in DR or in a rendered file? If the latter, which codec?

My advice is to convert H.264 source 8-bit material to something easier for Resolve to handle, like DNxHR or ProRes. The problem with using it for rendering is the computer has to work twice as hard: first to decode the files, then to apply the color correction and noise reduction. If it just has to do the latter, it's a lot less stressful for the system.

Worst case, you could consider going to a Proxy workflow within Resolve, which can work. Another possibility would be to simply slow down the render, maybe to 10fps or even 5fps, which will lighten the load for the CPU and GPU.

Do you see this in DR or in a rendered file? If the latter, which codec?

I haven't seen this in rendered files, only when working in the Color tab.

My advice is to convert H.264 source 8-bit material to something easier for Resolve to handle, like DNxHR or ProRes. The problem with using it for rendering is the computer has to work twice as hard: first to decode the files, then to apply the color correction and noise reduction. If it just has to do the latter, it's a lot less stressful for the system.

Worst case, you could consider going to a Proxy workflow within Resolve, which can work. Another possibility would be to simply slow down the render, maybe to 10fps or even 5fps, which will lighten the load for the CPU and GPU.

While this might indeed solve my issue, that these glitches are present is most definitely a bug in software and not just a natural result of an overtaxed system.

I haven't seen this in rendered files, only when working in the Color tab.

That suggests it's just a display issue. The GUI in Resolve isn't meant for critical evaluation anyway, so it's probably fine to just ignore it.

I haven't seen this in rendered files, only when working in the Color tab.

That suggests it's just a display issue. The GUI in Resolve isn't meant for critical evaluation anyway, so it's probably fine to just ignore it.

GUI in resolve shows the same image that is sent to IO device. If it shows in color but not in rendered files it is rather something triggered in view mode, something either performance mode related or proxy etc.

Check your GPU cooling.

GUI in resolve shows the same image that is sent to IO device.

That doesn't make sense to me. The GUI in Resolve has to go through the Display Driver. The whole point of using a dedicated I/O device is to remove that from the signal path.

Can you expand a bit?

GUI in resolve shows the same image that is sent to IO device.

That doesn't make sense to me. The GUI in Resolve has to go through the Display Driver. The whole point of using a dedicated I/O device is to remove that from the signal path.

Can you expand a bit?

Resolve does not calculate image twice, once for gui viewer, once for io device. Same image is produced in engine and sent to both. Or are you implying display driver adds diamond artifacts into a perfectly fine image? Maybe it does, dunno.

A simple test to try for OP: pan/zoom the image around in viewer. If artifacts change it might be it. If artifacts stay the same, it most probably is processing related. Additional thing to test: add a blur after denoise. Does it expand/change these artifact areas? If yes, it is definitely processing related.

GUI in resolve shows the same image that is sent to IO device.

That doesn't make sense to me. The GUI in Resolve has to go through the Display Driver. The whole point of using a dedicated I/O device is to remove that from the signal path.

Can you expand a bit?

Resolve does not calculate image twice, once for gui viewer, once for io device. Same image is produced in engine and sent to both. Or are you implying display driver adds diamond artifacts into a perfectly fine image? Maybe it does, dunno.

A simple test to try for OP: pan/zoom the image around in viewer. If artifacts change it might be it. If artifacts stay the same, it most probably is processing related. Additional thing to test: add a blur after denoise. Does it expand/change these artifact areas? If yes, it is definitely processing related.

I don't remember zooming having any effect. Jogging/seeking the clip does, however. Sometimes, it feels like the cache gets messed up or something.

While this might indeed solve my issue, that these glitches are present is most definitely a bug in software and not just a natural result of an overtaxed system.

Whether it's a bug or not, what I say is still true. Overtaxed hardware will produce glitches, even with Premiere or After Effects. We just threw lots and lots of hardware at Resolve and it's extremely rare we ever encounter a slowdown or glitch. But we're careful about what formats we use, what workflow we employ, and how we render.

While this might indeed solve my issue, that these glitches are present is most definitely a bug in software and not just a natural result of an overtaxed system.

Whether it's a bug or not, what I say is still true. Overtaxed hardware will produce glitches, even with Premiere or After Effects. We just threw lots and lots of hardware at Resolve and it's extremely rare we ever encounter a slowdown or glitch. But we're careful about what formats we use, what workflow we employ, and how we render.

My typical workflow is to record in a space efficient codec (V90 SD cards are expensive) and then generate DNxHR proxies in Resolve. My experience is that, indeed, this results in a much better experience with fewer glitches. However, in this case, I did not have the hard drive space for this. But in general, I agree with you, life will be easier if you choose better formats, no doubt.

However, I still maintain that this is a bug that can be fixed by BMD (unless it's a driver problem, of course). First of all my system wasn't very taxed. Second, if it was overtaxed I would expect the application to tell me it's out of resources rather than subtly glitching.

are you implying display driver adds diamond artifacts into a perfectly fine image?

Yes, that. I've seen some odd artifacts with player scaling that aren't in the actual image. I thought this might be similar, since it only appears in the GUI and not in the export. An artifact added by the GPU driver somehow.