Better and Faster way to do this script?

[zerowalker]

Is there an alternative way to do this script, or a way to speed it up.

Also i would prefer to not use fft3gpu as it seems to mess up after many uses in MeGUI which is only solved by restarting it.

May be the filter, or my GPU, but it only occurs after many uses like 10-20 Avisynth accessing that filter.


ConvertToYV12(matrix="Rec601", interlaced=false).Normalize(0.9)
smdegrain(tr=2,lsb=true,thsad=500,lsb_out=true,search=3)
fft3dgpu(sigma=1.3, plane=3)
Dither_convey_yuv4xxp16_on_yvxx()


It´s used for later encoding in 10 bit, which is why i work at a higher bit depth, to allow the extra 2 bit from 8 to be used as much as possible.

[zerowalker]

So there isn´t any alternative way to do this?
You can ignore the "Converttoyv12 blabla", and the Dither doesn´t have to be there, it´s just to utilize 10bit as it´s possible when working at 16bit.

But if there is a better way to perform this with similar results, i am all ear.
Or ways to speed it up, maybe x64 though i doubt it as plugins are quite limited there.
Perhaps you notice some setting i am using badly, as i came up with this through trial and error.

I did use MCTD before, but this was better and was faster, aswell as keeping details in dark areas.

I am using it for a Webcam which has much noise in dark scenes, especially chroma (hence fft3dgpu which solves that).
And smdegrain to try to just keep actual stuff instead of noise.


Anything is appreciated, hints, recommendations whatever:)

[cretindesalpes]

fft3dgpu is not made to process stack16 clips. Instead, use dfttest(sigma=something, Y=false, lsb_in=true, lsb=true) for a similar effect.

For speed-up, there not much more to do with smdegrain. You can play with the motion search parameters, but this will most likely hurt the motion estimation accuracy. You can also make dfttest all spatial (tbsize=1) because you already filtered temporally, and without motion compensation, filters with a temporal component may create ghosting or excessive blurring.

[zerowalker]

Ah okay, will try dfttest for that.

Btw is there a way to benchmark a script, so i can easier tell if it´s slower or not?

[Guest]

Btw is there a way to benchmark a script, so i can easier tell if it´s slower or not? AVSMeter:

http://forum.doom9.org/showthread.php?t=165528

[zerowalker]

Ah Great:)

sadly dfttest as i should have known, is alot slower than fft3dgpu.
I really only need some fast chroma cleanup, and it does the jobb extremely fast.
Is there a way to make it work in lsb?

Or well it does work now without problem, but i guess it does mess it up nevertheless as it doesn´t get the information right.

Perhaps i can just run fft3dgpu before smdegrain?
Or is there something wrong with that?

[zerowalker]

Is there any difference in using it as prefiltered vs using it before?

Quality wise that is?

I know some scripts use this, prefiltered here and there, but have never actually used it.

But in my eyes, it should be exactly the same, as 1 filter is messing with the picture, not several stages.

[feisty2]

Is there any difference in using it as prefiltered vs using it before?

Quality wise that is?

I know some scripts use this, prefiltered here and there, but have never actually used it.

But in my eyes, it should be exactly the same, as 1 filter is messing with the picture, not several stages.

no,using dft/fft filter as prefilter for motion compensated denoise filters (mdegrain/mcompensate+xxx) gives you much better results than using them directly

[zerowalker]

I tried using fft3d on the clip and had it as "prefilter", then used that as prefilter for smdegrain.

And well, it looked worse, it looked as if fft3d wasn´t used, there was chroma noise left, i compared before and after, and using

ff3d
smdegrain

was better than

pre = ff3d
smdegrain(pre)

not sure why though, perhaps i did something wrong?

[feisty2]

I tried using fft3d on the clip and had it as "prefilter", then used that as prefilter for smdegrain.

And well, it looked worse, it looked as if fft3d wasn´t used, there was chroma noise left, i compared before and after, and using

ff3d
smdegrain

was better than

pre = ff3d
smdegrain(pre)

not sure why though, perhaps i did something wrong?

use a higher "thSAD" and TNLmeans prefilter for very noisy clips something like "thSAD=1200,thSADC=1200" and it may cause artifacts in big chance,then use repair (mode=13) to remove artifacts
the final script may be something like

a=last
pre=a.tnlmeans (az=6).repair (a,mode=13) #if "az=0" will cause "shaky" artifacts and I added repair because tnlmeans doesn't have scene change detection,you can use mcompensate instead of repair#
a.smdegrain (tr=6,thsad=1200,thsadc=1200,prefilter=pre).repair (a,mode=13)

[zerowalker]

But that looks totally different from what i am doing right now.

And it would be alot slower 2 passes of motion compensation and try to repair any artifacts.

I only want to first remove the chroma noise, then do some motion compensated denoise with smdegrain, the current setting it fine from my tests.


Avisource("...")
pre = Avisource("...").fft3dgpu(sigma=10.3, plane=3)
smdegrain(tr=2,lsb=true,thsad=400,lsb_out=true,search=3,prefilter=pre)
DitherPost()

Is this correct?

It probably can´t be as it doesn´t even change the chroma noise, so i think i misunderstand how "prefilter" works.

[Asmodian]

prefilter is only used for the determining the motion. This motion information is then used on the unfiltered clip not the prefiltered one. This is done because noise can confuse the motion discovery algorithm but denoising removes details so you discover the motion with a heavily denoised clip but process the original clip to keep as much detail as possible. Turn up the strength of smdegrain if you want stronger denoising, changing the settings of fft3dgpu in your script will only affect the motion information (and probably not change it too much).

[zerowalker]

Ah that explains it.

So i should use some high denoise to make it look good with movements, but much random noise and small details get´s removed.

Then use smdegrain on the original clip with the denoised as a reference?

But i will would have to use fft3d on both though, but still, learned something, thanks.

Any recommendations on Denoising for that reference?
FFT3DGPU works good with bad chroma, but for denoising and keeping details overall, it doesn´t seem to be that good, and introduces weird artifacts if used to heavy.


Also, is there a good way to know if ghosting occurs?
I am guessing not, but well it occurs always more or less as how the script works, but it´s pretty hard to decide where it really get´s noticeable.

[feisty2]

Ah that explains it.

Any recommendations on Denoising for that reference?
FFT3DGPU works good with bad chroma, but for denoising and keeping details overall, it doesn´t seem to be that good, and introduces weird artifacts if used to heavy.


if you really wanna exactly fix messd up chroma, something like "thsad=400,thsadc=1200" should help, there're 2 parameters in MDegrainN control the strength of denoising,"thSAD" and "tr" both higher means stronger effects

[zerowalker]

That isn´t enough to fix the Chroma.

The Chroma noise is pretty intense.

It´s probably from the darkness, the camera can´t handle it, and so the chroma noise appears.
Or well it´s always there, but it´s very strong the darker there is.

fft3dgpu(sigma=1.4, plane=3)
That pretty much clears it out.
Luckily without messing up anything.

[feisty2]

That isn´t enough to fix the Chroma.

The Chroma noise is pretty intense.

It´s probably from the darkness, the camera can´t handle it, and so the chroma noise appears.
Or well it´s always there, but it´s very strong the darker there is.

fft3dgpu(sigma=1.4, plane=3)
That pretty much clears it out.
Luckily without messing up anything.

what I'm trying to say is using fft/dft filter directly is not quality wise because this kind of filters will make your video look like oil painted,you may take a look at tnlmeans if you want really clean results,tnlmeans provides much higher quality than fft/dft

a=last
y=a.greyscale ()#.mdegrainn#
u=a.utoy ().tnlmeans (az=6).repair (a.utoy (),mode=13)
v=a.vtoy ().tnlmeans (az=6).repair (a.vtoy (),mode=13)
ytouv (u,v,y)

[zerowalker]

Ah, i know what you mean with the oil paint.
But for just fast Chroma, i don´t find any artifacts occurring whatsoever, at least not with this stuff.
If it was more delicate (which luma often is, as it´s the most important of the two) the oil would probably be there.

But will look and see if i see any benefit with tnlmeans for this setup for chroma.
Else it will surely be better at Luma and overall denoising as FFT really isn´t good for that, except for super fast denoise where you don´t care for much details.