Neat Video and Optical Flow Issue

[Bassman]

Hello,

I noticed a bug or glitch with Neat Video when applying optical flow to a clip. Without Neat Video the slow motion is as expected. When Neat Video is applied the clip stutters, even after rendering.

This happened on a super slow-mo clip (around 10 speed) and got delivered. Not happy :( Anybody else notice this? I will try to update NV to 4.8 and see if it goes away.

[BernH]

Hello,

I noticed a bug or glitch with Neat Video when applying optical flow to a clip. Without Neat Video the slow motion is as expected. When Neat Video is applied the clip stutters, even after rendering.

This happened on a super slow-mo clip (around 10 speed) and got delivered. Not happy :( Anybody else notice this? I will try to update NV to 4.8 and see if it goes away.

NV should be applied as the first effect in the stack and even placed above layouter. I have seen it cause some odd results such as reduced luma when not placed in the #1 position with other effects higher in the stack, but it might also cause other issues.

Personally, I haven't seen your exact issue, but, I always do a Shift-Q render on my neat video processed footage before doing any other things to it, since neat and other NR plugins are so CPU/GPU intensive. If NV is the last plugin I use, as in an overall NR, assuming I have equal noise in an entire section, I normally Shift-Q the section so that any effects that are in there are baked in before applying NV. I do this to try to avoid the luma issues I mentioned and/or to make it simpler to place NV in the #1 position (1 clip to move it on), and hopefully speed up the NV processing.

[Bassman]

Thanks for your reply. NV is the top filter in the stack. I will try shift-Q rendering before adding NV but that would signal to me that something is not working correctly between NV and Edius.

[Bassman]

I shift-Q rendered the underlying clip then added NV and the motion is normal. So something is not right with Neat Video and the use of optical flow. I have also noticed issues with NV and the use of Stabilizer. I guess they are fighting for the top spot of the stack?

[BernH]

I shift-Q rendered the underlying clip then added NV and the motion is normal. So something is not right with Neat Video and the use of optical flow. I have also noticed issues with NV and the use of Stabilizer. I guess they are fighting for the top spot of the stack?

Quite probably. Now that you mention it, I think I saw an issue with the stabilizer at one time too.

After noticing these unpredictable results, I personally try to make NV the only plugin applied by do a Shift-Q render, or at the very least make sure that there are only very basic effects in use with it, such as a bit of colour correction. It's a pretty good quality noise reduction, but can be quirky when used in conjunction with other effects.

[Bassman]

It is a blessing and a curse. I like the ability to clean up footage but it is a pain that GV chooses to not really implement this plugin correctly. When one has a lot of separate clips it is not ideal to have to go to each clip and make sure the NV filter is the top most filter. If you miss one, your color is off for that clip. Or you have the motion inconsistency. Playback is not realtime so it is more effort to search for problems.

It looks like this "issue" will be around forever as it has not changed in how many years. Vlad (NV creator) says his hands are tied.

So if you plan on any slomo or stabilization it is wise to shift-Q the clip first if you want to use Neat video.

[Tobe]

About slo-mo in Edius. I have been working with some 2K drone footage sent to me and have been first doing a Shift-Q render to HQ and then applying Edius slo-mo and Optical/Highest quality as the choice...It sure looks good to me...am I missing something and need to go to Neat Video (which I don't have)? Or am I not seeing artifacts that should make me nervous?As a test I have been trying 10-20% speed, and sometimes I have to re-render for smooth playback, but I can easily live with this workflow.

[Bassman]

I am not sure what you are asking. Neat Video is for noise reduction and is not quite working well with clips where optical flow is applied. Optical flow on its own is great.

[Tobe]

Ah ha...my mistake.

[BernH]

It is a blessing and a curse. I like the ability to clean up footage but it is a pain that GV chooses to not really implement this plugin correctly. When one has a lot of separate clips it is not ideal to have to go to each clip and make sure the NV filter is the top most filter. If you miss one, your color is off for that clip. Or you have the motion inconsistency. Playback is not realtime so it is more effort to search for problems.

It looks like this "issue" will be around forever as it has not changed in how many years. Vlad (NV creator) says his hands are tied.

So if you plan on any slomo or stabilization it is wise to shift-Q the clip first if you want to use Neat video.

I feel your pain. Much of my work with Edius is event videography, where ideal lighting for video is almost never achievable, so noise reduction is a must on a lot of my work.

It's rather frustrating to have to do so much fiddling with the placement of NV in order to get it to work well. I often put full length captures or files on the timeline and apply NV, then Shift-Q each track before multicam if the two cameras have different noise levels, or if they are about the same I apply it to a Shift-Q final "mixdown" Of course, having to do it to each camera before hand adds a lot of render time and drive space requirement, only to have a good chunk of the renders on used, making a lot of the render time wasted.

A decent native noise reduction that doesn't care about being in the #1 position would be very welcome.

[Bassman]

I do not need the noise reduction to be native, just properly implemented. I guess it can not be properly implemented because it is not native?

[BernH]

I do not need the noise reduction to be native, just properly implemented. I guess it can not be properly implemented because it is not native?

I'm not one of the GV engineers, but I suspect the implementation based on the plugin SDK is a factor to play in some of these oddities, and why Vlad says his hands are tied with the implementation. That's why I said a decent native noise reduction would be welcome.

I may be wrong, but I think I also remember reading somewhere that the plugin API also only allows for 8bit processing, so, if that is true, a native noise reduction could potentially operate in and preserve 10bit.

[Bassman]

Thanks for replying. As you can see, nobody from the GV team is involved with these type of threads. Because there is no solution to a problem that is not being worked on. This side of being committed to Edius as my main NLE is frustrating. It is a great program that is kind of frozen right now.