TemporalDegrainV2

[ErazorTT]

@tormento
Oh I see. Yeah, that was a pretty stupid f*ck up on my side.. :rolleyes:
Please checkout new version 2.1.2 from first post!

Oh and btw using degrainTR=4 AND postSigma=3 is a very severe overkill.

[tormento]

Please checkout new version 2.1.2 from first post!
[2018-10-31][09:26:01] error: Script error: There is no function named 'Dither_convert_8_to_16'.
[2018-10-31][09:26:01] (D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.1.2—ErazorTT.avsi, line 241)
[2018-10-31][09:26:01] (E:\in\2_01 sacrificio del cervo sacro, Il\sacrificio_4td.avs, line 17)
Please get rid of old dither tools as was done by SMDegrain :)
Oh and btw using degrainTR=4 AND postSigma=3 is a very severe overkill.
Just trying to do a comparison with
SMDegrain (tr=4, thSAD=400, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)

Edit: tried to run under Simple x264 Launcher and results in a deadlock with Prefetch. Working (slow as hell) under VirtualDub. Tried again without prefetch under Simple x264 and I get something like 0.15 fps.

[ErazorTT]

[2018-10-31][09:26:01] error: Script error: There is no function named 'Dither_convert_8_to_16'.

The function Dither_convert_8_to_16 is not part of dither.dll but of dither.avsi, which can also be found in the same archive (http://ldesoras.free.fr/src/avs/dither-1.27.2.zip), you will need both files in you path.


Please get rid of old dither tools as was done by SMDegrain :)


Yes I am also no fan of this but as far as I see SMDegrain does still has this function call even in the newest version, so I do not know what you mean by "as was done by SMDegrain":

from SMDegrain v3.1.2.100s:

NL_in = lsb && !lsb_in ? input.Dither_convert_8_to_16() : input

[tormento]

need both files in you path.
Did it.
as far as I see SMDegrain does still has this function call even in the newest version
With the command line I use, it doesn't use dither at all (I did not have in my Plugins64 directory), so I suppose it's only a optional condition trigger.

Any hint about speed?

[ErazorTT]

Well concerning speed I can for sure say that using dfttest as postFFT is slow.
For full HD and using TemporalDegrain2(degrainTR=2,postFFT=3,postSigma=3,postDither=-1) on one core and with the x264 instance on the other core, I am getting something around 1 fps.

I do have almost no experience with KNLMeans or using MtMode or Prefetch.

Do I assume correctly that you are testing with high bit input?

[tormento]

Well concerning speed I can for sure say that using dfttest as postFFT is slow.
I am using KNLMeansCL as postFFT(=4).
I do have almost no experience with KNLMeans or using MtMode or Prefetch.
Picture that with SMDegrain (the syntax I posted) I get 12-13 fps with Prefetch(6) getting similar results. As I saw you already looked at other script to get inspiration, I humbly suggest you to get a look to SMDegrain also and get the good things from it too. :o And please, play a bit with Prefetch too. 1 fps on nowadays processors is really slow. We have GPU sitting there too, let's use them :) I have been successful to make your script to work with Prefetch and the maximum I get is still 0.98fps.
Do I assume correctly that you are testing with high bit input?
No, I use 8 bit input, as you can see from DGDecNV syntax.

[ErazorTT]

Does it change something to set postDither to 0? What speed do you reach then?

is this (https://forum.doom9.org/showthread.php?p=1856262#post1856262) still the actual script you managed to make prefetch running?

[tormento]

Does it change something to set postDither to 0? What speed do you reach then?
Running and I am at 0.86 with Prefetch(6)
is this (https://forum.doom9.org/showthread.php?p=1856262#post1856262) still the actual script you managed to make prefetch running?
Yep. It hangs a bit in the begninning, so much that the x264 launcher complains:
[2018-10-31][17:59:54] Warning: encoder did not respond for 60 seconds, potential deadlock...
then it starts.

Please, if you want, give latest SMDegrain a run with my same parameters, i.e.
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
<your preferred decoder>
CompTest(1)
SMDegrain (tr=4, thSAD=400, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)
Prefetch(6)

[ErazorTT]

So I made a perfomance test on my dual core 3Ghz Haswell with the following code with the colored expressions either being enabled or not:


SetFilterMTMode("DEFAULT_MT_MODE", 2)
LWLibavVideoSource("Z:\1080p.mkv")
TemporalDegrain2(...)
BilinearResize(480,270)
Trim(100,666)+Trim(9835,10000)
Prefetch(2)


These are the results:
https://i.postimg.cc/2SgYMF53/perf.png

Just using the BilinearResize without any other filter and the throughput is at 122 fps.
On one core TemporalDegrain2 is almost as fast as TemporalDegrain v1.23.
Using postFFT=3 decreases the speed dramatically and postFFT=4 is only any better if you have some usefull graphics card, not as my crappy internal Intel.
Increasing the number of threads using the parameter fftTreads helps somehow, it helps however more to use Prefetch.

@tormento: Could you please also test using postFFT=3 with your Prefetch of 6?
And, could it be that you also have an internal intel graphics card apart from your actual GPU? Because in this case I would guess that perhaps the KNLMeans runs on the wrong GPU. Could you give it another using KNLMeans with this (https://drive.google.com/open?id=1SUkbwe7e56QKokOU43C_izrz3VYOhFae) version?

[ChaosKing]

Nice script. It's a good smdegrain alternative.
I tested TemporalDegrain2(degrainTR=4, postFFT=3, fftthreads=4) with Prefetch(2), 4 and 6 - DVD 720x480
Went from 3.2 fps to 5.8fps. The biggest jump was with Prefetch(2) to 5.4fps. The cpu is at 50% max. Ryzen @ 3.7ghz 8core.
With degrainTR=2 I get 15.4 fps :D


Any chance this gets ported to Vapoursynth one day?

[ErazorTT]

Were you using both fftthreads=4 and Prefetch(2) at the same time? I though those to be mutually exclusive. Thus I would have guessed that it would be more performant to have only Prefetch, which then could be set higher. :confused: What is your experience with that?

Additionally I really would not set degrainTR higher than FPS/8, thus for the usual cinema film not higher than 3. There can be some very rare, hard to find but ugly effects! I could show an example when I have time to prepare the pictures later today. Thus I would decrease degrainTR to 3 or even 2 and instead increase postSigma to 2 or 3.

Well I have never used Vapoursynth, so this is not something which will happen immediately..

[ChaosKing]

Were you using both fftthreads=4 and Prefetch(2) at the same time? I though those to be mutually exclusive.
.

Yeah, it seems mixing both is not a good idea. You can see the negative effects even more with higher values. Prefetch(8) alone runs now with 7.2fps. If I add fftthreads (tried 2 and 8) it slows down to 3.5fps regardles of that fftthread value I set.

If you want give VapourSynth a try you can use my portable pack (all filters, scripts and editors included). https://forum.doom9.org/showthread.php?t=175529

EDIT
For some reason I set degrainTR=6 while testing with fftthreads...
Prefetch(8) + fftthreads=8 => 9.2 fps, so yes mixem them is ok :cool:

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

[tormento]

@tormento: Could you please also test using postFFT=3 with your Prefetch of 6?
Results on 1920x1032 input:

TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=0) 0.69 (1.56*) fps, 3791.50 kb/s
TemporalDegrain2(degrainTR=4,postFFT=3,postSigma=3,postDither=0) 0.45 (0.85*) fps, 3060.34 kb/s
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=0) 0.64 (0.98*) fps, 3331.73 kb/s

(* Prefeth=6)

And, as comparison:

SMDegrain (tr=4, thSAD=400, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true) 9.34 fps, 4083.54 kb/s

I think the problem does not reside on postFFT side. As you can see the delta is negligible with postFFT=0. Please notice that every output is then processed to x264 slow preset.
And, could it be that you also have an internal intel graphics card apart from your actual GPU? Because in this case I would guess that perhaps the KNLMeans runs on the wrong GPU.
My CPU is a Sandy Bridge and does not support OpenCL. Plus the slowness would appear on SMDegrain too.
Could you give it another using KNLMeans with this (https://drive.google.com/open?id=1SUkbwe7e56QKokOU43C_izrz3VYOhFae) version?
All the new trials were made with your newer script.

[ChaosKing]

I noticed that your scripts produces some halos:

200% zoom
https://i.imgur.com/IK83WEL.png

I used TemporalDegrain2(degrainTR=3, postFFT=3, fftthreads=8). It's still visible with postFFT=0 but slightly less.

[ErazorTT]

TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=0) 0.86 fps 3060 kb/s
TemporalDegrain2(degrainTR=4,postFFT=3,postSigma=3,postDither=0) 0.95 fps 3371 kb/s
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=0) 1.58 fps 3791 kb/s


This is ultra wierd! How can it be faster to have the postFFT enabled compared to not having it enabled :confused:
Were you running with Prefetch(x)? What do you get when you increase your Prefetch(x) setting from 1 to whatever you usually use?

[ErazorTT]

I noticed that your scripts produces some halos:
200% zoom
https://i.imgur.com/IK83WEL.png


Is it the original to the right? Because I for sure see there the same structure. It seems it is just visually hidden behind the noise. Once the noise is removed, the structure is revealed.

[tormento]

This is ultra wierd!
I will rerun again to have confirmation.

[tormento]

This is ultra wierd!
Post fixed.

[zorr]

AvisynthOptimizer could be used to test the speed of different Prefetch and SetFilterMTMode settings.

Additionally I really would not set degrainTR higher than FPS/8, thus for the usual cinema film not higher than 3. There can be some very rare, hard to find but ugly effects!

Also by comparing the degrained clip to the original with SSIM it should be easy to spot any anomalies in the rendering. The script could return the worst SSIM of any frame. It will probably need a long clip to find those rare errors though, but it should be possible. If anyone is interested I can help make the script ready for the optimizer.

[ErazorTT]

AvisynthOptimizer could be used to test the speed of different Prefetch and SetFilterMTMode settings.

That would be great, however as much as would love to do this test myself, I guess my crappy dual core laptop is not performant enough to do this analysts.


Also by comparing the degrained clip to the original with SSIM...

Yes , something along the lines of this here: http://forum.doom9.org/showthread.php?p=861726#post861726


It will probably need a long clip to find those rare errors though...

The suggestion by StainlessS is probably a good starting point:
http://forum.doom9.org/showthread.php?p=1856048#post1856048


If anyone is interested I can help make the script ready for the optimizer.

Yeah that would be interesting to see! (Who knows perhaps this would trigger my urge to get a decent standalone pc again :D )

[tormento]

That would be great, however as much as would love to do this test myself, I guess my crappy dual core laptop is not performant enough to do this analysts.
My two cents: I don't want to weigh you down but I simply think that the script, even as so much good as it is, is simply too slow to have any improvements with tweaks on the Prefetch side. I have looked at the CPU usage, both on single thread and MT, and there are so much time it plains does nothing. With Prefetch(6), over 8 logical cores, I get a media of 30% with peaks of 50%.
You (we) should analyze every single routine inside and find where the cycles run void.

And, since x264 Simple Launcher was created, it's the first time I see it telling me the script is not responding, to give you an idea.

Please, if you have time, try to create a simpler one, using only OpenCL filtering (KNLMeansCL in my mind) + MVTools. Probably the results will be crappier but we could have an idea of theoretical speed.

[ChaosKing]

I offer to run the Optimizer tests on my 8 core Ryzen.

[ErazorTT]

Well considering that the result from ChaosKing are more than an order of magnitude faster than yours, and yours are exactly as fast as both TempralDegrain v1 and v2 on my crappy laptop I would guess that there is something wrong for you. I don’t know what simple launcher is supposed to do but apparently there goes something wrong.
Considering that you have a Sandy Bridge this means that you have 4 cores. Perhaps it would be an idea to not set Prefetch higher that 3 and have x264 on the 4th core. And also try to run once with postFFT=1.

[ChaosKing]

My CPU util was still @ 50-60% max with Prefetch 8. But the big diffenrence could be this: I have a RX480 gpu, that means KNLMeansCL is not that slow on my system.
tormento, what fps do you get with KNLMeansCL alone?

[ChaosKing]

Here is a quick test for:
optimize degrainTR = _n_ | 1..4 | degrainTR
optimize postFFT = _n_ | 0,1,3 | postFFT

I used AddGrain(80, 0, 0, seed=2) on a clean anime 720p source
But after iter 16 I got into an endless DUPLICATE PARAMS loop.

225.84503 33630 degrainTR=1 postFFT=0
241.66373 76180 degrainTR=4 postFFT=0
239.99747 60510 degrainTR=3 postFFT=0
239.99747 61410 degrainTR=3 postFFT=0
239.99747 62140 degrainTR=3 postFFT=0
244.31024 16655 degrainTR=3 postFFT=3
244.09448 95600 degrainTR=4 postFFT=1
244.91441 18072 degrainTR=4 postFFT=3
244.09448 95270 degrainTR=4 postFFT=1
236.55763 48110 degrainTR=2 postFFT=0
225.84503 34390 degrainTR=1 postFFT=0
243.23091 80750 degrainTR=3 postFFT=1
244.91440 18117 degrainTR=4 postFFT=3
242.97444 15382 degrainTR=2 postFFT=3
241.66373 75960 degrainTR=4 postFFT=0
232.85495 53540 degrainTR=1 postFFT=1


https://i.imgur.com/bFROtKh.png

[ErazorTT]

Ok that is interesting! Perhaps you could also include a sweep over the postSigma = _n_ | 1,2,3,4 | . Since postFFT=0 is apparently always worse you could exclude it to save some time.

[ErazorTT]

@tormento: Could you please try again with this version here (https://drive.google.com/open?id=14uAFDJm1bHG64Xldvi1mzf2zB0y4ndw8). I included knlDevId so perhaps playing with it changing it from 0 to 1 will help..

[zorr]

Here is a quick test for:
optimize degrainTR = _n_ | 1..4 | degrainTR
optimize postFFT = _n_ | 0,1,3 | postFFT

I used AddGrain(80, 0, 0, seed=2) on a clean anime 720p source
But after iter 16 I got into an endless DUPLICATE PARAMS loop.

Hmm, seems *almost* normal behavior. The DUPLICATE PARAMS happens when the optimizer is unable to find a parameter combination it hasn't already tried. I should probably add an ending condition there as well or make it smart enough to realize it has tried all combinations.

However what I don't quite understand is why it did that after 16 iterations, there are 4*3 possible combinations which is 12. And it already has some duplicates in your log... :confused:

[ChaosKing]

degrainTR = 4 # optimize degrainTR = _n_ | 1..4 | degrainTR
postFFT = 1 # optimize postFFT = _n_ | 0,1,3 | postFFT
postSigma = 1 # optimize postSigma = _n_ | 1..4 | postSigma

Now with Prefetch(8), lower res (640x360) and trim to 150 frames.
Is it normal that the graph doesn't show lower values like 135?

145.50601 9670 degrainTR=1 postFFT=1 postSigma=3
145.67668 25930 degrainTR=2 postFFT=3 postSigma=1
142.8922 17800 degrainTR=3 postFFT=0 postSigma=1
147.25772 20230 degrainTR=3 postFFT=1 postSigma=3
142.8922 17830 degrainTR=3 postFFT=0 postSigma=2
142.8922 17730 degrainTR=3 postFFT=0 postSigma=1
135.96149 7380 degrainTR=1 postFFT=0 postSigma=1
145.5126 20260 degrainTR=3 postFFT=1 postSigma=1
142.8922 17950 degrainTR=3 postFFT=0 postSigma=2
135.96149 7350 degrainTR=1 postFFT=0 postSigma=1
142.8922 17950 degrainTR=3 postFFT=0 postSigma=1
144.04181 14660 degrainTR=2 postFFT=1 postSigma=1
143.90645 22950 degrainTR=4 postFFT=0 postSigma=2
143.90645 23380 degrainTR=4 postFFT=0 postSigma=1
140.8963 12090 degrainTR=2 postFFT=0 postSigma=2
147.57607 31830 degrainTR=3 postFFT=3 postSigma=3
145.67668 25760 degrainTR=2 postFFT=3 postSigma=1
147.12352 36800 degrainTR=4 postFFT=3 postSigma=1
140.8963 12100 degrainTR=2 postFFT=0 postSigma=3
140.8963 12100 degrainTR=2 postFFT=0 postSigma=1
145.50601 9660 degrainTR=1 postFFT=1 postSigma=3
139.70255 9660 degrainTR=1 postFFT=1 postSigma=1
147.17488 25320 degrainTR=4 postFFT=1 postSigma=2
143.70836 9700 degrainTR=1 postFFT=1 postSigma=2
146.21446 20850 degrainTR=1 postFFT=3 postSigma=4
146.8522 14590 degrainTR=2 postFFT=1 postSigma=3
135.96149 7390 degrainTR=1 postFFT=0 postSigma=2
135.96149 7380 degrainTR=1 postFFT=0 postSigma=3
147.3242 31640 degrainTR=3 postFFT=3 postSigma=2
142.22742 21040 degrainTR=1 postFFT=3 postSigma=1
147.40378 20430 degrainTR=3 postFFT=1 postSigma=4
142.8922 17960 degrainTR=3 postFFT=0 postSigma=4
147.4705 25270 degrainTR=4 postFFT=1 postSigma=3
147.70525 32060 degrainTR=3 postFFT=3 postSigma=4
146.24329 9590 degrainTR=1 postFFT=1 postSigma=4
147.18077 25890 degrainTR=2 postFFT=3 postSigma=3
147.1184 14480 degrainTR=2 postFFT=1 postSigma=4
144.46893 21110 degrainTR=1 postFFT=3 postSigma=2
145.5126 20240 degrainTR=3 postFFT=1 postSigma=1
142.8922 17930 degrainTR=3 postFFT=0 postSigma=3
146.74043 26020 degrainTR=2 postFFT=3 postSigma=2
140.8963 12540 degrainTR=2 postFFT=0 postSigma=4
147.25772 20260 degrainTR=3 postFFT=1 postSigma=3
147.41321 26070 degrainTR=2 postFFT=3 postSigma=4
143.90645 22770 degrainTR=4 postFFT=0 postSigma=4
147.84923 36290 degrainTR=4 postFFT=3 postSigma=4
135.96149 7400 degrainTR=1 postFFT=0 postSigma=4
146.84929 20350 degrainTR=3 postFFT=1 postSigma=2
146.16771 14490 degrainTR=2 postFFT=1 postSigma=2
147.7625 36640 degrainTR=4 postFFT=3 postSigma=3
147.56343 25300 degrainTR=4 postFFT=1 postSigma=4
145.57582 20730 degrainTR=1 postFFT=3 postSigma=3
146.18916 25550 degrainTR=4 postFFT=1 postSigma=1
143.90645 23240 degrainTR=4 postFFT=0 postSigma=3
147.58546 36390 degrainTR=4 postFFT=3 postSigma=2
146.68575 31290 degrainTR=3 postFFT=3 postSigma=1

https://i.imgur.com/3rnrBNA.png


The output by evaluate mode is also a bit strange, worst result = best?
Single run results: 56
Series results: 0

Run 1 best: 147.84923 36290 degrainTR=4 postFFT=3 postSigma=4

Best result: 147.84923
Worst result: 147.84923

Pareto front:
147.84923 36290 degrainTR=4 postFFT=3 postSigma=4
147.70525 32060 degrainTR=3 postFFT=3 postSigma=4
147.57607 31830 degrainTR=3 postFFT=3 postSigma=3
147.56343 25300 degrainTR=4 postFFT=1 postSigma=4
147.4705 25270 degrainTR=4 postFFT=1 postSigma=3
147.40378 20430 degrainTR=3 postFFT=1 postSigma=4
147.25772 20230 degrainTR=3 postFFT=1 postSigma=3
147.1184 14480 degrainTR=2 postFFT=1 postSigma=4
146.24329 9590 degrainTR=1 postFFT=1 postSigma=4
135.96149 7350 degrainTR=1 postFFT=0 postSigma=1

[ErazorTT]

Judging by this measurement the optimum is also the maximal settings which were allowed:

147.84923 36290 degrainTR=4 postFFT=3 postSigma=4

It would appear that the maxima fit degrainTR and postSigma were still too low in this run. However, the result should be wildly different in different circumstances: like for clips with much quick movements I would guess that increasing degrainTR above some threshold will be counterproductive.

[ChaosKing]

Bonus: degrainTR 5-6
148.04684 47280ms degrainTR=6 postFFT=3 postSigma=4
148.01166 42710ms degrainTR=5 postFFT=3 postSigma=4
147.94945 41310ms degrainTR=5 postFFT=3 postSigma=3
147.78264 37160ms degrainTR=6 postFFT=1 postSigma=4
147.7377 36780ms degrainTR=6 postFFT=1 postSigma=3
147.73164 30890ms degrainTR=5 postFFT=1 postSigma=4
147.67194 30840ms degrainTR=5 postFFT=1 postSigma=3
147.44595 30810ms degrainTR=5 postFFT=1 postSigma=2
144.64229 27510ms degrainTR=5 postFFT=0 postSigma=1

@zorr I had set it to -iters 30 by mistake but it ran 32 times nonetheless
LOG (x64, 0.9.8 beta)
Output 1:
name ssim
type FLOAT
goal MAX
unit
round 0
Output 2:
name time
type TIME
goal MIN
unit ms
round 10

Found following optimizable parameters:
# optimize degrainTR = _n_ | 5..6 | degrainTR
# optimize postFFT = _n_ | 0,1,3 | postFFT
# optimize postSigma = _n_ | 1..4 | postSigma
found 3 parameters to optimize

Running SPEA2
* 1 / 30 : 145.00519 56410ms degrainTR=6 postFFT=0 postSigma=1
+ 2 / 30 : 145.00519 55430ms degrainTR=6 postFFT=0 postSigma=3
+ 3 / 30 : 144.64229 28650ms degrainTR=5 postFFT=0 postSigma=2
4 / 30 : 144.64229 28710ms degrainTR=5 postFFT=0 postSigma=1
* 5 / 30 : 147.81573 42460ms degrainTR=5 postFFT=3 postSigma=2
+ 6 / 30 : 146.67145 31380ms degrainTR=5 postFFT=1 postSigma=1
7 / 30 : 145.00519 56330ms degrainTR=6 postFFT=0 postSigma=4
+ 8 / 30 : 144.64229 28330ms degrainTR=5 postFFT=0 postSigma=2
Parameter sensitivity estimation with 64 result combinations
-> degrainTR 0,542 postFFT 1,546 postSigma 0,990
Mutating 2 params by 22,0 %
+ 9 / 30 : 147.78264 37160ms degrainTR=6 postFFT=1 postSigma=4
+ 10 / 30 : 147.44595 30810ms degrainTR=5 postFFT=1 postSigma=2
11 / 30 : 144.64229 28410ms degrainTR=5 postFFT=0 postSigma=4
12 / 30 : 145.00519 53030ms degrainTR=6 postFFT=0 postSigma=1
13 / 30 : 147.45505 42150ms degrainTR=5 postFFT=3 postSigma=1
14 / 30 : 146.67145 30820ms degrainTR=5 postFFT=1 postSigma=1
15 / 30 : 146.8749 36550ms degrainTR=6 postFFT=1 postSigma=1
+ 16 / 30 : 144.64229 27580ms degrainTR=5 postFFT=0 postSigma=2
Parameter sensitivity estimation with 256 result combinations
-> degrainTR 0,556 postFFT 1,403 postSigma 0,968
Mutating 1 params by 14,0 %
mutation failed 1000 times, increasing mutation count to 2
+ 17 / 30 : 144.64229 27510ms degrainTR=5 postFFT=0 postSigma=1
18 / 30 : 145.00519 52870ms degrainTR=6 postFFT=0 postSigma=2
19 / 30 : 147.81573 42490ms degrainTR=5 postFFT=3 postSigma=2
20 / 30 : 144.64229 27880ms degrainTR=5 postFFT=0 postSigma=3
+ 21 / 30 : 147.7377 36780ms degrainTR=6 postFFT=1 postSigma=3
22 / 30 : 147.54588 36850ms degrainTR=6 postFFT=1 postSigma=2
+ 23 / 30 : 147.67194 30840ms degrainTR=5 postFFT=1 postSigma=3
24 / 30 : 147.57674 48110ms degrainTR=6 postFFT=3 postSigma=1
Parameter sensitivity estimation with 256 result combinations
-> degrainTR 0,559 postFFT 1,282 postSigma 1,054
Mutating 1 params by 6,0 %
mutation failed 1000 times, increasing mutation count to 2
mutation failed 1000 times, increasing mutation count to 2
mutation failed 1000 times, increasing mutation count to 2
mutation failed 2000 times, increasing mutation count to 3
25 / 30 : 145.00519 53010ms degrainTR=6 postFFT=0 postSigma=3
+ 26 / 30 : 147.73164 30890ms degrainTR=5 postFFT=1 postSigma=4
* 27 / 30 : 147.94945 41310ms degrainTR=5 postFFT=3 postSigma=3
28 / 30 : 147.88573 46830ms degrainTR=6 postFFT=3 postSigma=2
* 29 / 30 : 148.01166 42710ms degrainTR=5 postFFT=3 postSigma=4
30 / 30 : 147.99655 47120ms degrainTR=6 postFFT=3 postSigma=3
* 31 / 30 : 148.04684 47280ms degrainTR=6 postFFT=3 postSigma=4
32 / 30 : 145.00519 53230ms degrainTR=6 postFFT=0 postSigma=4
Parameter sensitivity estimation with 256 result combinations
-> degrainTR 0,566 postFFT 1,161 postSigma 1,152
Total execution time: 1339735ms
Pareto front:
148.04684 47280ms degrainTR=6 postFFT=3 postSigma=4
148.01166 42710ms degrainTR=5 postFFT=3 postSigma=4
147.94945 41310ms degrainTR=5 postFFT=3 postSigma=3
147.78264 37160ms degrainTR=6 postFFT=1 postSigma=4
147.7377 36780ms degrainTR=6 postFFT=1 postSigma=3
147.73164 30890ms degrainTR=5 postFFT=1 postSigma=4
147.67194 30840ms degrainTR=5 postFFT=1 postSigma=3
147.44595 30810ms degrainTR=5 postFFT=1 postSigma=2
144.64229 27510ms degrainTR=5 postFFT=0 postSigma=1
Running SPEA2
...

[ErazorTT]

What is actually the script you are using?

[ChaosKing]

https://forum.doom9.org/showpost.php?p=1856803&postcount=98

[ChaosKing]

Now I tested 100 frames from tears of steel, this scene https://www.youtube.com/watch?v=R6MlUcmOul8&feature=youtu.be&t=271

And here I noticed also some halos. You can see it very good on his hair in #2 http://screenshotcomparison.com/comparison/123735/

My script
ffms2("TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11.mkv").ConvertBits(8).bicubicresize(880,500).trim(6460,6560)
source = last
last=source.AddGrain(40, 0, 0, seed=2)
degrainTR = 5 # optimize degrainTR = _n_ | 1..5 | degrainTR
postFFT = 3 # optimize postFFT = _n_ | 0,1,3 | postFFT
postSigma = 1 # optimize postSigma = _n_ | 1..4 | postSigma
denoised = TemporalDegrain2(degrainTR=degrainTR, postFFT=postFFT, postSigma=postSigma)
# no Prefetch, i forgot to add it :)

@zorr
- Evaluate mode still shows version 0.9.8 instead of 0.9.9
- Worst result is still wrong in 0.9.9 and the visualisation also I guess (96.75 value is cut off)
AvisynthOptimizer v0.9.8-beta

Arguments
mode = evaluate
autorefresh = true

Running evaluation for log(s) .\avs_version (2018-11-04 10-10-30) optimize spea2 pop-8 mutcount-60%-1 mutamount-0.3-0.01 cross-0.1-20 iters-70 run-01.log
Using these settings:
ARGUMENT DESCRIPTION VALUE
-vismode visualization mode single
-scripts write scripts none
-globalpareto show series pareto true
-autorefresh autorefresh true
-highlight highlight latest 10
-multipareto show multiple pareto fronts 0 (OFF)
-top zoom into top x% results 20
-groupby group by parameter (OFF)
-maxgroups group by max groups N/A
-groupmin group by min value N/A
-groupmax group by max value N/A
-animation animation iterations per frame 0 (OFF)

Reading log file .\avs_version (2018-11-04 10-10-30) optimize spea2 pop-8 mutcount-60%-1 mutamount-0.3-0.01 cross-0.1-20 iters-70 run-01.log
Single run results: 64
Series results: 0

Run 1 best: 99.42768 51190 degrainTR=5 postFFT=3 postSigma=1

Best result: 99.42768
Worst result: 99.42768 <----- NOPE!

Pareto front:
99.42768 51190 degrainTR=5 postFFT=3 postSigma=1
99.42644 44710 degrainTR=4 postFFT=3 postSigma=1
99.3991 38630 degrainTR=3 postFFT=3 postSigma=1
99.39909 38140 degrainTR=3 postFFT=3 postSigma=1
99.37821 37100 degrainTR=5 postFFT=1 postSigma=1
99.35609 30730 degrainTR=4 postFFT=1 postSigma=2
99.3523 30310 degrainTR=4 postFFT=1 postSigma=1
99.34066 24040 degrainTR=3 postFFT=1 postSigma=2
99.26441 17570 degrainTR=2 postFFT=1 postSigma=2
99.15682 17560 degrainTR=2 postFFT=1 postSigma=4
99.067345 17490 degrainTR=2 postFFT=1 postSigma=1
99.05565 11640 degrainTR=1 postFFT=1 postSigma=4
96.75158 8700 degrainTR=1 postFFT=0 postSigma=2
https://i.imgur.com/zkLRXnc.png


98.24987 14380 degrainTR=2 postFFT=0 postSigma=3
99.31801 31720 degrainTR=2 postFFT=3 postSigma=4
99.34313 32060 degrainTR=2 postFFT=3 postSigma=2
99.3523 30310 degrainTR=4 postFFT=1 postSigma=1
96.75158 8700 degrainTR=1 postFFT=0 postSigma=2
99.39007 44140 degrainTR=4 postFFT=3 postSigma=2
96.75158 8720 degrainTR=1 postFFT=0 postSigma=3
98.24987 14580 degrainTR=2 postFFT=0 postSigma=4
98.72428 21350 degrainTR=3 postFFT=0 postSigma=3
99.052536 11670 degrainTR=1 postFFT=1 postSigma=3
99.02302 25530 degrainTR=1 postFFT=3 postSigma=2
99.05565 11640 degrainTR=1 postFFT=1 postSigma=4
98.72428 21600 degrainTR=3 postFFT=0 postSigma=4
98.12291 11930 degrainTR=1 postFFT=1 postSigma=1
99.05177 34090 degrainTR=5 postFFT=0 postSigma=1
99.15682 17560 degrainTR=2 postFFT=1 postSigma=4
96.75158 8820 degrainTR=1 postFFT=0 postSigma=1
98.878456 12010 degrainTR=1 postFFT=1 postSigma=2
99.28696 32500 degrainTR=2 postFFT=3 postSigma=1
99.24217 17770 degrainTR=2 postFFT=1 postSigma=3
99.37821 37100 degrainTR=5 postFFT=1 postSigma=1
96.75158 8750 degrainTR=1 postFFT=0 postSigma=4
98.94025 27930 degrainTR=4 postFFT=0 postSigma=1
98.24987 14310 degrainTR=2 postFFT=0 postSigma=2
99.27137 24320 degrainTR=3 postFFT=1 postSigma=3
99.352585 36270 degrainTR=5 postFFT=1 postSigma=2
98.72428 21830 degrainTR=3 postFFT=0 postSigma=2
99.42768 51190 degrainTR=5 postFFT=3 postSigma=1
99.188416 26020 degrainTR=1 postFFT=3 postSigma=4
99.35609 30730 degrainTR=4 postFFT=1 postSigma=2
99.37805 51230 degrainTR=5 postFFT=3 postSigma=2
99.14046 25910 degrainTR=1 postFFT=3 postSigma=3
99.2798 24180 degrainTR=3 postFFT=1 postSigma=1
99.15887 24290 degrainTR=3 postFFT=1 postSigma=4
99.34593 44000 degrainTR=4 postFFT=3 postSigma=3
99.42644 44710 degrainTR=4 postFFT=3 postSigma=1
99.05177 33440 degrainTR=5 postFFT=0 postSigma=2
98.72428 21520 degrainTR=3 postFFT=0 postSigma=1
99.38929 38540 degrainTR=3 postFFT=3 postSigma=2
99.34066 24040 degrainTR=3 postFFT=1 postSigma=2
99.39909 38140 degrainTR=3 postFFT=3 postSigma=1
98.94025 28150 degrainTR=4 postFFT=0 postSigma=2
99.35622 38870 degrainTR=3 postFFT=3 postSigma=3
98.24987 14870 degrainTR=2 postFFT=0 postSigma=1
99.32733 51160 degrainTR=5 postFFT=3 postSigma=3
98.688225 25490 degrainTR=1 postFFT=3 postSigma=1
99.30322 44120 degrainTR=4 postFFT=3 postSigma=4
99.26441 17570 degrainTR=2 postFFT=1 postSigma=2
98.94025 27280 degrainTR=4 postFFT=0 postSigma=4
99.32066 38310 degrainTR=3 postFFT=3 postSigma=4
99.067345 17490 degrainTR=2 postFFT=1 postSigma=1
99.26495 30370 degrainTR=4 postFFT=1 postSigma=3
99.280716 51640 degrainTR=5 postFFT=3 postSigma=4
99.24911 36540 degrainTR=5 postFFT=1 postSigma=3
99.1392 30790 degrainTR=4 postFFT=1 postSigma=4
99.33777 31310 degrainTR=2 postFFT=3 postSigma=3
99.05177 33620 degrainTR=5 postFFT=0 postSigma=3
99.115715 36940 degrainTR=5 postFFT=1 postSigma=4
99.05177 33770 degrainTR=5 postFFT=0 postSigma=4
98.94025 27360 degrainTR=4 postFFT=0 postSigma=3
98.12291 11790 degrainTR=1 postFFT=1 postSigma=1
99.15887 24470 degrainTR=3 postFFT=1 postSigma=4
98.94025 28210 degrainTR=4 postFFT=0 postSigma=2
99.3991 38630 degrainTR=3 postFFT=3 postSigma=1

[tormento]

Well considering that the result from ChaosKing are more than an order of magnitude faster than yours, and yours are exactly as fast as both TempralDegrain v1 and v2 on my crappy laptop I would guess that there is something wrong for you. I don’t know what simple launcher is supposed to do but apparently there goes something wrong.
Or probably you missed the fact I am running the script on a 1080p source and you both on 720p or DVD resolution? :D Which encoder you feed at the end? I am using x264 --preset slow.

To clear things up, I am now using AVSMeter64 to get script results with no encoder around.

@ChaosKing to answer you about KNLMeansCL performance, I run a simple KNLMeansCL() on 1080p source:
AVSMeter64.exe sacrificio_KNLMeansCL.avs

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

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

Frames processed: 1750 (0 - 1749)
FPS (min | max | average): 2.001 | 17.93 | 12.41
Process memory usage (max): 198 MiB
Thread count: 24
CPU usage (average): 9.6%

Time (elapsed): 00:02:21.065

Anyway... as I told twice... SMDegrain with KNLMeansCL prefilter works with 10x performance.

[ChaosKing]

tears of steel 1080p x64 test:

#0.82fps
TemporalDegrain2(degrainTR=3, postFFT=3, postSigma=1)

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

KNLMeansCL alone runs at 27fps on a 1080p source


I'm testing the script performance, so I don't feed to any encoder.

[tormento]

tears of steel 1080p x64 test:
Please try these (https://forum.doom9.org/showthread.php?p=1856708#post1856708) settings to mantain some uniformity.

EDIT:
#4fps
TemporalDegrain2(degrainTR=3, postFFT=3, postSigma=1, fftthreads=8)
Prefetch(8)

@ErazorTT

1.86 fps here on i7-2600k + GTX 760. I can't really see one order of magnitude.

[ChaosKing]

All with Prefetch(8). Now tested with avsmeter64, 300 frames, 1080p source - ffms2("TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11.mkv").trim(500,500+300)
AviSynth+ r2728, all plugins updated
Ryzen 1700 @ 3.7ghz, Rx480, 16gb ram 3000mhz
TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=0) #5.15
TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=0, fftthreads=8) #5.5
TemporalDegrain2(degrainTR=4,postFFT=3,postSigma=3,postDither=0) # 2.42
TemporalDegrain2(degrainTR=4,postFFT=3,postSigma=3,postDither=0, fftthreads=8) # 3.52
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=0) #4.23
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=0, fftthreads=8) #4.62

Have you the newest fftw lib installed?

[ErazorTT]

Or probably you missed the fact I am running the script on a 1080p source and you both on 720p or DVD resolution?


My performance measurement (here (https://forum.doom9.org/showthread.php?p=1856673#post1856673)) was using a 1080p source. Yielding around 1.7fps without postFFT on a dual core haswell laptop, i5-4288U.


Which encoder you feed at the end? I am using x264 --preset slow.


For measuring the speed of the script I use x264 with preset super fast, since I want to measure the differences between scripts not the impact of the encoder. However I very much see the point of measuring both, since in the end one has to do both at a time.


Anyway... as I told twice... SMDegrain with KNLMeansCL prefilter works with 10x performance.


Yes.. Apparently there is somewhere something wrong but I just dont know where... Without being able to test it myself, there nothing more I can do than guessing.. :(

[tormento]

For measuring the speed of the script I use x264 with preset super fast
Much better to feed directly to avsmeter
Yes.. Apparently there is somewhere something wrong but I just dont know where... Without being able to test it myself, there nothing more I can do than guessing.. :(
We are here to help ;)

[tormento]

Have you the newest fftw lib installed?
I am using 3.3.8 (https://forum.doom9.org/showthread.php?p=1855955#post1855955) AVX

[ErazorTT]

Much better to feed directly to avsmeter


Thats a good suggestion!

I am using 3.3.8 (https://forum.doom9.org/showthread.php?p=1855955#post1855955) AVX

Oh wow I test all the version from your link and the fastest version was "simd128+256" which made dfttest alsmot 10% faster!

EDIT:
Hm however fft3dfilter does not work with this version of fftw lib, it produces access violations...

[zorr]

@zorr
- Evaluate mode still shows version 0.9.8 instead of 0.9.9


Yes, I forgot to update the version number. It has happened a couple of times before. :o

- Worst result is still wrong in 0.9.9 and the visualisation also I guess (96.75 value is cut off)

The visualization by default "zooms in" into the best 20% of results. You can change that with argument -top, for example -top 50 would show the top 50% of results. If you want the zooming completely disabled use -top 100 but that doesn't usually look very good. Perhaps -top 99 will do what you want.

I wasn't able to reproduce the problem with the worst result, I also noticed that in your log the Series has zero results, probably has something to do with that.


Single run results: 64
Series results: 0


Can you give me the exact command line you use to call the optimizer? Are you calling it from the <optimizer>/bin directory or somewhere else? Where are your log files located at?

You also might try the latest version (https://drive.google.com/open?id=1pD9qguKcAkvVNTjpfJeixcukf4yXKtAI) which has one path related problem fixed.

@zorr I had set it to -iters 30 by mistake but it ran 32 times nonetheless

That's a limitation of the algorithms, they evaluate a whole population until they can stop. So the iteration count is always divisible by the population count.

[tormento]

Hm however fft3dfilter does not work with this version of fftw lib, it produces access violations...
Try to report in that thread.

[zorr]

Run 1 best: 99.42768 51190 degrainTR=5 postFFT=3 postSigma=1

Best result: 99.42768
Worst result: 99.42768 <----- NOPE!


Ah, I forgot what the worst result means. It's actually the best result of the worst run. When there is only one run then best == worst. The idea is that you can see how different results the runs give. I will change the labels to "Best run" and "Worst run" to make it easier to understand.

I have tracked down the Series results being 0, will be fixed in the next version.

And more on topic: it might be a good idea to test if there is any difference in quality when running in multithreaded mode versus single threaded. There shouldn't be, but it doesn't hurt to make sure...

[Zetti]

Thats a good suggestion!



Oh wow I test all the version from your link and the fastest version was "simd128+256" which made dfttest alsmot 10% faster!

EDIT:
Hm however fft3dfilter does not work with this version of fftw lib, it produces access violations...
The problem is fftw lib and not fft3dfilter.

See here: https://forum.doom9.org/showthread.php?p=1857182#post1857182

[tormento]

I want to share an updated version of the script TemporalDegrain.
What about a switch to use FFT3DGPU instead of FFT3DFilter? I'd like to see speed/quality differences. Problem is AFAIK we don't have a x64 version of it.

It could be nice to have a new compiled version from Pinterf, who already dealt with FFT3DFilter or (my dream) a FFT3DCL from Khanattila

[ErazorTT]

What about a switch to use FFT3DGPU instead of FFT3DFilter?


FFT is used in two instances in the script. You can already change both to using FFT3DGPU via function arguments. One by changing limitFFT to 2 and the other by changing postFFT to 2. PostFFT also has the options 3 (dfttest) and 4 (meansCL) which do not make sense for limitFFT.

I'd like to see speed/quality differences.


Yeah me too but I just have an integrated Intel GPU. Quality wise I would expect FFT3DGPU to behave very close to FFT3Dfilter. And especially for limitFFT there is will be no difference in quality, though perhaps very significantly in speed.

That said, FFT3DGPU has not seen any new version in ages while there have been updates to FFT3Dfilter.

[tormento]

One by changing limitFFT to 2
Ok... I did not notice that. Now that you point it, I can see it in the script code. Now I only need to find a FFT3DGPU x64...

EDIT: Here (https://forum.doom9.org/showthread.php?t=164513).
That said, FFT3DGPU has not seen any new version in ages while there have been updates to FFT3Dfilter.
A real pity. Just imagine to have a FFT3DCL...

[tormento]

TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=-1,limitFFT=1) 1.70 fps
TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=-1,limitFFT=2) 1.66 fps
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=-1,limitFFT=1) 1.12 fps
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=-1,limitFFT=2) 1.03 fps

So there should be a bottleneck somewhere...