Move FFT3D outside MT routine in a preanalyzed MDegrain

[tormento]

I'm using the following:

LoadPlugin("D:\eseguibili\media\dgdecnv\x64 binaries\DGDecodeNV.dll")
DGSource("whatever.dgi")

MT("""
src = last
preNR = src.FFT3DFilter( sigma=16 )
preNR_super = preNR.MSuper(pel=2, sharp=1)
src_super = src.MSuper(pel=2, sharp=1, levels=1)
backward_vec3 = MAnalyse(preNR_super, isb = true, delta = 3, blksize=16, overlap=8)
backward_vec2 = MAnalyse(preNR_super, isb = true, delta = 2, blksize=16, overlap=8)
backward_vec1 = MAnalyse(preNR_super, isb = true, delta = 1, blksize=16, overlap=8)
forward_vec1 = MAnalyse(preNR_super, isb = false, delta = 1, blksize=16, overlap=8)
forward_vec2 = MAnalyse(preNR_super, isb = false, delta = 2, blksize=16, overlap=8)
forward_vec3 = MAnalyse(preNR_super, isb = false, delta = 3, blksize=16, overlap=8)
src.MDegrain3(src_super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=600)
""",threads=4, overlap=8, splitvertical=false)

to clean some grain infested clips.

I have tried to use FFT3DGPU to increase performance but it is not possible to use it AFAIK inside a MT routine without artifacts.

I have tried different line swapping and moving but I can't create a working script with FFT3DGPU or FFT3DFilter outside MT. Any idea?

Thanks ;)

[Didée]

LoadPlugin("D:\eseguibili\media\dgdecnv\x64 binaries\DGDecodeNV.dll")
DGSource("whatever.dgi")

interleave( last, last.FFT3DFilter( sigma=16 ) )

MT("""
src = last.selecteven()
preNR = last.selectodd()
preNR_super = preNR.MSuper(pel=2, sharp=1)
src_super = src.MSuper(pel=2, sharp=1, levels=1)
backward_vec3 = MAnalyse(preNR_super, isb = true, delta = 3, blksize=16, overlap=8)
backward_vec2 = MAnalyse(preNR_super, isb = true, delta = 2, blksize=16, overlap=8)
backward_vec1 = MAnalyse(preNR_super, isb = true, delta = 1, blksize=16, overlap=8)
forward_vec1 = MAnalyse(preNR_super, isb = false, delta = 1, blksize=16, overlap=8)
forward_vec2 = MAnalyse(preNR_super, isb = false, delta = 2, blksize=16, overlap=8)
forward_vec3 = MAnalyse(preNR_super, isb = false, delta = 3, blksize=16, overlap=8)
src.MDegrain3(src_super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=600)
""",threads=4, overlap=8, splitvertical=false)

You probably need better tweaking for FFT's setup (temporal filtering), as well as MDegrain (thSAD seems way to high, given the fact that it's referring to a pre-cleaned(!!) analyse clip).

[tormento]

You probably need better tweaking for FFT's setup (temporal filtering), as well as MDegrain (thSAD seems way to high, given the fact that it's referring to a pre-cleaned(!!) analyse clip).
Thanks for your bit of wisdom. As far as I understood from the standard MVTools docs, the precleaned clip was used for the motion vectors only and the real degrain work was done by MDegrain.

Perhaps my idea of understanding is a bit overestimated.

Any idea for better results? As you may perceive by reading my few threads, I am looking for the holy grail of degraining... The culprits are BD such as The hurt locker, 300 and so.

[Didée]

As far as I understood from the standard MVTools docs, the precleaned clip was used for the motion vectors only and the real degrain work was done by MDegrain.
That's correct. But you also need to keep in mind that the SAD values are not re-calculated by MDegrain. It just used the SAD values that are stored in the vector stream. And since the motion search has been done on a clip that's virtually free of noise/grain (at least it should, theoretically, due to the prefiltering), the resulting SAD values are rather low, and MDegrain should use a rather low value for thSAD, not a high value.

Any idea for better results? As you may perceive by reading my few threads, I am looking for the holy grail of degraining
Historically, most people that have searched the holy grail have been deceased in the meantime. And no one has heard of any success. ;)

There's no particular idea for better results ... the story is quite simple: on very noisy sources, the noise (or some of its side-effects) are disturbing the motion search. Hence, you need to set up the prefiltering so that the disturbing aspects are eliminated. The question isn't ultimately how light or how heavy the prefilter should be. The question is how specifically the prefilter can elimiate the specific characteristic that is disturbing the motion search.

As a general rule of thumb, temporal filtering is more important than spatial filtering. A grainy no-motion area should be really calm and steady after the prefilter. If motionless spots still show fluctuations, then MAnalyse might consider those fluctuations as motion. Which is exactly what the whole process tries to avoid in the first place. A spatial filter is quite unlikely to remove inter-frame flicker. That's the domain of temporal filters. (A pity that you can't separate spatial and temporal "strength" in FFT3DFilter. With tnlmeans that is possible, but quite a bit slower.)

[tormento]

You gave me a nice and witty reply, as always, thanks.

But now, Didée, how should I modify that script? How a good filter should be used to clean the area to be vectorized?

[elguaxo]

interleave( last, last.FFT3DFilter( sigma=16 ) )

MT("""
src = last.selecteven()
preNR = last.selectodd()



Nice trick! :D

[dansrfe]

Brilliant. I love the effects of adding a weak fft3dfilter line for the preNR and the last.selecteven();last.selectodd() trick. Excellent explanation as usual Didée.

[tormento]

Mmm... I tried to use the interleaved script, both with FFT3DFilter (even with ncpu set) and FFT3DGPU, and it's ways slower than my original one. I must suppose my only way to go "multithreaded" is to split the movie in different parts and run different MEGUI workers on them.

[Didée]

That's quite possible. You asked how to get FFT3D outside the MT statement, I showed a solution. But I didn't claim that it would be any faster. :)

Vanilla FFT3DFilter works quite well with both MT() and SetMTMode(). If looking at just Avisynth, having FFT3D inside MT is likely to be faster than having it outside. And FFT3DGPU can indeed become a bottleneck ... when the remaining (multithreaded) script is fast enough, FFT3DGPU sometimes is just too slow.

[tormento]

Yep, you are correct, as always =P Ever tried to split a video in various ranges and parallelize encoding? Any caveat?

[Nephilis]

.....