TemporalDegrainV2

[Groucho2004]

Originally Posted by tormento

So there should be a bottleneck somewhere...

What do you mean by "should"? The main bottleneck you have in your statements is this:
degrainTR=4

[tormento]

Originally Posted by Groucho2004

What do you mean by "should"? The main bottleneck you have in your statements is this:
degrainTR=4

I have no knowledge of programming and I can only read a bit of scripting. Can you explain me why SMDegrain is way faster even with TR=9?

[Groucho2004]

Originally Posted by tormento

Can you explain me why SMDegrain is way faster even with TR=9?

It's a completely different script that uses different parameters passed to the various plugins would be my guess.

[ErazorTT]

Originally Posted by tormento

Can you explain me why SMDegrain is way faster even with TR=9?

I would suggest to also have a look at the resulting output. What kind of source do you have that you need a temporal radius that big? Even in very heavy scenes like in 300 there is basically no grain or noise left when using degrainTR=3 with postSigma=3.

And in the case of SMDegrain, does it actually change something to go with TR above 6? Isn’t 6 the maximum it computes?

Very generally speaking, if a script does not remove almost all noise you want removed with a temporal radius of 3, I very much doubt it will help much to increase further. With ever increasing number of frames in radius the marginal gain decreases very quickly while the marginal costs* at best remain constant.

Thus also for performance measurements I would really suggest to use the scripts on a realistic source with sensible settings. Setting you would actually use for the final encoding.

EDIT: (*) costs, plural! That is because as costs there is not only the performance impact, with increasing radius there are also the chances of artifacts and the ugliness of artefacts increasing.

This is actually the very reason why I tried to develop an successor script for TemporalDegrain in the first place: Increasing TR above 3 starts to be detrimental, thus I included the post FFT step to combat the remaining noise with another tool. The combination of two different attacks yields better results with less costs than just increasing the numbers of one attack. This is usually generally true, in wars, hacks, medicine or in this instance of combating noise.

[tormento]

Originally Posted by ErazorTT

What kind of source do you have that you need a temporal radius that big?

Pure benchmark example. I use 9 really rarely on old movies.

Originally Posted by ErazorTT

And in the case of SMDegrain, does it actually change something to go with TR above 6? Isn’t 6 the maximum it computes?

Usually nothing changes a lot above 4. On some material it changes a lot.

Generally speaking: why FFT3DGPU had no effect on performance?

[ErazorTT]

I have no idea!

[Groucho2004]

Originally Posted by tormento

why FFT3DGPU had no effect on performance?

fft3dgpu is faster for me:

CPU: i5 2500K @ 4GHz, GPU: GTX750

Full script (1080p clip, 100 frames):

PHP Code:

LoadCPlugin("E:\Apps\VideoTools\AVSPlugins\CPlugs\ffms2_64.dll")
FFVideoSource("TestDenoise.mkv")
TemporalDegrain2(degrainTR = 1, postFFT = x) 


postFFT = 0

FPS (min | max | average):      1.057 | 39.67 | 3.381
Process memory usage (max):     755 MiB
Thread count:                   20
CPU usage (average):            44.7%

postFFT = 1

FPS (min | max | average):      0.645 | 6.377 | 2.194
Process memory usage (max):     1134 MiB
Thread count:                   20
CPU usage (average):            38.7%

postFFT = 2

FPS (min | max | average):      0.668 | 12.75 | 2.626
Process memory usage (max):     1263 MiB
Thread count:                   24
CPU usage (average):            38.4%

[tormento]

Originally Posted by Groucho2004

fft3dgpu is faster for me

We were talking about limitFFT switch, not postFFT.

Anyway... 0.5fps...

You know better than me the different order of magnitude betweet FFT3DFilter and FFT3DGPU:

FFT3DFilter() no MT

AVSMeter 2.8.7 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames:                 1568
Length (hh:mm:ss.ms):     00:01:05.399
Frame width:                      1920
Frame height:                      800
Framerate:                      23.976 (24000/1001)
Colorspace:                       YV12

Frames processed:               1568 (0 - 1567)
FPS (min | max | average):      2.409 | 30.74 | 17.92
Process memory usage (max):     269 MiB
Thread count:                   20
CPU usage (average):            9.6%

Time (elapsed):                 00:01:27.509

FFT3DGPU() no MT

AVSMeter 2.8.7 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames:                 1568
Length (hh:mm:ss.ms):     00:01:05.399
Frame width:                      1920
Frame height:                      800
Framerate:                      23.976 (24000/1001)
Colorspace:                       YV12

Frames processed:               1568 (0 - 1567)
FPS (min | max | average):      2.796 | 124.9 | 36.15
Process memory usage (max):     242 MiB
Thread count:                   35
CPU usage (average):            5.4%

Time (elapsed):                 00:00:43.377

[Groucho2004]

Originally Posted by tormento

We were talking about limitFFT switch, not postFFT.

Same thing, fft3dfilter vs. fft3dgpu.

By the way, the limitfft parameter comment in the avsi makes no sense:

limitFFT= default( limitFFT, 1 ) # wether to use the limit clip. Do never ever disable this, thats part of the very core of the functionality

This is the code:

filter = (limitFFT==1) ? \
o.FFT3DFilter(plane=degrainPlane, sigma=limitSigma, sigma2=s2, sigma3=s3, sigma4=s4, bt=3, bw=limitBlksz, bh=limitBlksz, ncpu=fftThreads) : \
o.FFT3DGPU(plane=degrainPlane, sigma=limitSigma, sigma2=s2 , sigma3=s3, sigma4=s4, bt=3, bw=limitBlksz, bh=limitBlksz)

This means that "limitfft = 1" uses fft3dfilter and any other value uses fft3dgpu. There is no disable option.

[ErazorTT]

Originally Posted by Groucho2004

This means that "limitfft = 1" uses fft3dfilter and any other value uses fft3dgpu. There is no disable option.

Yeah right.. updated it together with putting pinterf's new hosting addres for FFT3dGPU.

[tormento]

FFT3DGPU() no MT

AVSMeter 2.8.7 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames:                 1568
Length (hh:mm:ss.ms):     00:01:05.399
Frame width:                      1920
Frame height:                      800
Framerate:                      23.976 (24000/1001)
Colorspace:                       YV12

Frames processed:               1568 (0 - 1567)
FPS (min | max | average):      2.787 | 120.3 | 36.53
Process memory usage (max):     242 MiB
Thread count:                   35
CPU usage (average):            4.4%

Time (elapsed):                 00:00:42.929

[ChaosKing]

Originally Posted by ChaosKing

TemporalDegrain2(degrainTR=4, postFFT=3, fftthreads=8) # 9.2fps
Prefetch(8)

TemporalDegrain2(degrainTR=3, postFFT=3, fftthreads=8) # 12.5fps
TemporalDegrain2(degrainTR=2, postFFT=3, fftthreads=8) # 17.3fps

TemporalDegrain2(degrainTR=3, postFFT=3) # 10.1fps
TemporalDegrain2(degrainTR=2, postFFT=3) # 14.0fps

Wolfberry has ported TemporalDegrain2 to VapourSynth. Here are now some numbers with the VS version:

TemporalDegrain2(degrainTR=3, postFFT=3) # 22.3 fps
TemporalDegrain2(degrainTR=2, postFFT=3) # 27.4 fps

A solid +10fps


Edit: can't test tr=4 for now + it would be only with float sample type
Edit2:
clip=mvf.Depth(clip,32)
clip=hnw.TemporalDegrain2(clip, degrainTR=4, postFFT=3) # 6.6fps and 7gb ram
clip=hnw.TemporalDegrain2(clip, degrainTR=4, postFFT=03) # 9fps

[tormento]

Originally Posted by ChaosKing

A solid +10fps

Too much for a simple conversion. Perhaps there's a issue somewhere like what happen for z.lib (or was it color conversion? can't remember).

[ChaosKing]

Originally Posted by tormento

Too much for a simple conversion. Perhaps there's a issue somewhere like what happen for z.lib (or was it color conversion? can't remember).

Same source, same format YV12. But my CPU is at max util, whats the difference. VS just scales better with more cores.

[pinterf]

Originally Posted by ChaosKing

Same source, same format YV12. But my CPU is at max util, whats the difference. VS just scales better with more cores.

The search method and parameters were not the same in VS and AVS versions, I reported it.

After having the same parameters, I still don't like how it works under Avisynth+ MT at degrainTR2 or 3 settings. Reorganized the AVS code to use similar methods like the VS port, such as creating standalone bv1,2,3 and fv1,2,3 vector clips and use them in MDegrain1,2,3 instead of creating one mvmulti clip, and use different MCompensate structures and Interleaving them. Probably it became better but still laggy, seems that if there were short deadlocks or ineffective cache usage, but I really don't know what happens.

[tormento]

Is there any optimization but degrainPlane=0 to denoise a b/w movie?

[ErazorTT]

well I havn't put much work into bw movies, so no there is no optimization for that.

[ErazorTT]

Originally Posted by pinterf

Reorganized the AVS code to use similar methods like the VS port, such as creating standalone bv1,2,3 and fv1,2,3 vector clips and use them in MDegrain1,2,3 instead of creating one mvmulti clip, and use different MCompensate structures and Interleaving them.

I tested that and for me it makes just no difference. But look for yourself: TemporalDegrain-v2.1.4a.7z
This script is to be used just for TR up to 4. I was too lazy to write the MCompensate part for up to 6...

[pinterf]

Since then I experimented a bit. The clip dependencies are very special in this script. During my tests I made a parameter for MDegrain to tell it whether the forward or the backward vectors should requested first and in what order (e.g Backward3 B2 B1 Forward1 F2 F3 sequence vs. F3 F2 F1 B1 B2 B3), thus changing which frame is waiting for which other earlier frame. I was able to double the fps but it was not consistent and clearly, this hack is not a solution. Avisynth kind of multithreading and GetFrame logic makes a huge difference for this specific script and makes it inferior compared to Vapoursynth which is able to start requesting the necessary frames parallel instead of requesting them in a serialized, blocking way.

[tormento]

Originally Posted by pinterf

Since then I experimented a bit.

Did you try with Neo fork?