Need Suggestions for VERY GRAINY source

[ChrisW77]

Didée, Thankyou. Great explanation. :)

You see, I'm always still learning, and I get frustrated when I can't see a solution that you see straight away. All I need is a brief explanation, and a possible script demo, and I learn from that.

Once again, thankyou.

[Lorax2161]

TemporalDegrain looks really nice, but my PC is way to slow to run this thing practically. So I used Didee's limiting approach and wrote something that required less MV operations with very good results IMHO. Let me know what you think!


-G

What speed improvements did you find with your version, and what processor type are you using?

TemporalDegrain is awesome, but I have to check the TV guide before I invoke it to see if there is anything else I wanted to capture in the next day or so before I begin encoding. :)

[g-force]

What speed improvements did you find with your version, and what processor type are you using?


I'm not sure right off hand all of the specs on the processor. It's an AMD from a few years ago. I'll take a look when I get home from work.

What I do know is that when I would call TemporalDegrain, it would take about 30sec to generate a frame, whereas mine took maybe a few seconds. In retrospect, I've found it to blur fast motion stuff a bit too much for what I intended to use it for, but I'm still trying to run with the idea of using the median aspects of Clense with mo-comp'd frames.

-G

[Nikos]

I think that there is a mistake in Didée's post #33.

o = last
f = o.MinBlur(1,2).MinBlur(2,2).RemoveGrain(11,-1)
f.FluxSmoothT(7).mt_AddDiff(mt_MakeDiff(o,f,U=1,V=1),U=4,V=4)
# eventually, limit the maximum pixel change to +/- 2 :
mt_LutXY(last,o,"x 2 + y < x 2 + x 2 - y > x 2 - x ? ?",U=2,V=2)

For example, if pixel value o = 100 and pixel value last = 93 then the output pixel value = 95.
That is pixel change = 5

In my opinion the right syntax is:

o = last
f = o.MinBlur(1,2).MinBlur(2,2).RemoveGrain(11,-1)
f.FluxSmoothT(7).mt_AddDiff(mt_MakeDiff(o,f,U=1,V=1),U=4,V=4)

# eventually, limit the maximum pixel change to +/- 2 :
mt_LutXY(o,last,"x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",U=2,V=2)

But, may be i am wrong :)

[Didée]

@Nikos: Exactly like you said, that LUT expression was wrong. Well spotted, thanks for noting!

Also, there's something strange with
>> mt_AddDiff(mt_MakeDiff(o,f,U=1,V=1),U=4,V=4)

UV=4 means copy chroma from 2nd clip argument. The 2nd clip argument is mt_MakeDiff(o,f,U=1,V=1), which has chroma in an undefined state.
Funny that this seems to output correct chroma nonetheless ...

LUT and chroma issues are in the script of post#33 are fixed now.

[Nikos]

Thanks Didée for the correction and for all your work.
From my tests on a very problematic HD movie the results from the script was great. The dirty dancing effect reduced with almost no smoothing.
I had tried many other filters without success.

Now the usual questions :)

1. In masktools Round(1.5)=2 or 1.

2. Why in mt_makediff with identical clips, the difference is 128 and not 0 like maths. In general i don't understand well the meaning of 128 :)

3. It's a good idea to use the motion compensate ML3DexGPU for prefiltering in my MC-denoise scripts?

I tried your script with the ML3DexGPU and the result happens to be sufficient and pleasant. This prefilter combo is able to cut down the dirty dancing noise almost completely with minimal blurriness.

Thanks again!!!

[Didée]

1. It should follow the usual convention for rounding, .5 is rounded upwards. (It appears to be so ... but don't nail me on that it does so in each possible case. I'm not the coder of MaskTools.)

2. A pixel can't have a negative value, only 0-255. In order to handle "negative" differences, the range -127..0..127 is offsetted to 0..128..255.

3. You tell, I don't know. The exact operation of ML3Dex isn't fully clear to me (have been a bit lazy when looking through that pdf) ... however in practice, it doesn't impress me too much. The temporal artefacts in motion areas (resp. areas with erroneous motion compensation) are pretty much the same as those of plain temporal median, so there's no benefit in that respect. In areas without motion (resp. in areas with correct motion compensation), it does remove a bit more signal spikes, no matter whether it's noise or detail.
Thus, for me ML3Dex isn't a interesting option. And ML3DexGPU isn't because I don't have GPU acceleration.

If it works sufficient for you, then you answered your own question. :)

[Nikos]

2. A pixel can't have a negative value, only 0-255. In order to handle "negative" differences, the range -127..0..127 is offsetted to 0..128..255

If pixels differences are above +/- 127 (very rare case), then what's happen?
I suppose that clip them to +/- 127.

Thanks again!!!

[yup]

Hi folks!
Simple idea. I very frequently use MVDegrain3 for denoising VHS cassette capture. I use big thSAD 800 for luma and 1200 for chroma for many parts video this work very good, but for frame with big scan I see ghosting, may be will be useful use mask with motion estimation (vector length). Separate all frame to three types slow motion, medium motion and fast motion (depending from value motion vector) and use three MVDegrain3 and after use mask.
yup.

[Snake91]

Hi to all, I'm encoding Matrix Revolutions from my HDDVD and i wanted to clean the flickering on the background (minimizing detail loss) that's sometimes there fro compressibility purpose. I've checked the first pages of the thread and tried this (http://forum.doom9.org/showthread.php?p=1073349#post1073349) script from Didée. The script doesn't give me any error nor when I load it nor when I'm encoding but the results are very strange with some frames getting more accelerated than the others.
Samples
http://www.megaupload.com/?d=J6ISVCM3 - Encoded
http://www.megaupload.com/?d=VAOBD7FL - Source

Watch the logo, this effect is repeated across all the movie making it unwatchable. If I use only dss and crop the video is perfect, how can I solve???

[Didée]

If I use only dss and crop the video is perfect, how can I solve???
(Frankly, I did not look at your files.)

Do not use DSS.

DSS is not frame accurate on seeking. With a script that's so ressource hungry as the one you're referring to, it is very likely that frames will be requested out-of-(linear)-order, and that's where DSS may and will cause problems.

Also, I don't know the HD version of that movie, only the SD one ... and that one is not extraordinarily noisy. I'd suspect that you don't need such a complex denoising strategy for this movie, and that a simple MDegrain2|3 should be sufficient.

(In particular, it's the act of MDegraining an already-MDegrain'ed clip that is eating ressources for breakfast. Such should not be done when poking in the blue, but only on well-aimed intention.)

[Snake91]

Do not use DSS.

DSS is not frame accurate on seeking. With a script that's so ressource hungry as the one you're referring to, it is very likely that frames will be requested out-of-(linear)-order, and that's where DSS may and will cause problems.
I've tried DSS2 (which has frame-accuracy) and it worked:eek:
Thanks a lot!!!

Also, I don't know the HD version of that movie, only the SD one ... and that one is not extraordinarily noisy. I'd suspect that you don't need such a complex denoising strategy for this movie, and that a simple MDegrain2|3 should be sufficient.

(In particular, it's the act of MDegraining an already-MDegrain'ed clip that is eating ressources for breakfast. Such should not be done when poking in the blue, but only on well-aimed intention.)Thanks for the suggestion, I will compare both and pick the best

[tormento]

Something to try: the following script will remove the low-frequency flicker, leaving the high-frequencies intact.
Would you accept the trial to write something that is available in avisynth x64 domain? :devil:

[Didée]

That script is based on FluxSmooth and MedianBlur. Unfortunately, neither of them has been ported to x64 yet.

It would be possible to construct something similar. MedianBlur can be done via mt_luts(). FluxSmooth could be approximated with a combination of Clense and TemporalSoften. But no, seems that Clense is not included in the current compilation of RemoveGrain_x64. (Not Joshy's compilation. And kassandro's 64bit compilation is said to not work at all)(?) - So it would need to be built by a 3-fold mt_logic() combination.

Workarounds for workarounds for workarounds. The result would probably run 5 to 10 times slower than the 32bit script. That's not really worth the effort.

Much better choice:
- Instead of challenging me to script that, challenge the plugin guys to port FluxSmooth and MedianBlur to 64bit. Possibly also Clense.
- For bonus points, someone write a plain Temporal-Median Filter that is actually usable. (MedianBlurT is not, if radius>2.)

[tormento]

Didée you are right and I apologise for threatening your patience ;) My disappoint comes from the impossibility to run MCTD in x64. After some frames in MT it just plain crashes.

I have some very difficulties to encode BD (Save private Ryan to tell one) and using higher CRF to fit a DVD9 is not an option as quality would suffer too much.

I am currently trying TemporalDegrain or MC Degrain3, however believe me or not the result are always over 10 GB. MCTD_x64 could be a solution. It's a pity it does not exist =)

[SilaSurfer]

Didée thank you for the script.

Really calms down that "naasty dance effect of grain". I was wondering could that script be modified to have stronger effect? In some of my Dvd sources it doesn't calm down grain fully, and Mdegrain after isn't really effective and produces smearing in those areas where that dancing effect is stronger mostly in the CGI elements of some movies that I tried on. Thanks

[Didée]

This thread has 16 pages, 300+ posts, and quite a few scrpts have been posted. Which script exactly are you speaking of?

If it's the initial denoising script I had posted - meanwhile converted to "TemporalDegrain" by Sagekilla - that one is basically performing source.MDegrain3().MDegrain3() ...

... so yes, you are right: using MDegrain after that isn't really effective. Why should it, after all. :D


But maybe we're talking past each other. Please specify.

[tormento]

This thread has 16 pages, 300+ posts, and quite a few scrpts have been posted. Which script exactly are you speaking of?
The one you will write for us using the *very fast* NLMeansCL filter ;)

[SilaSurfer]

This thread has 16 pages, 300+ posts, and quite a few scrpts have been posted.

Yes I know, took me some time to read it and a lot of coffee.:p


If it's the initial denoising script I had posted - meanwhile converted to "TemporalDegrain" by Sagekilla

Thats one of the best scripts in my opinion using Mdegrain denoising with a prefilter analysis clip. Used copy/paste on it straight to my hard drive so I can modify it for my own usage. :p But nope not this one.


... so yes, you are right: using MDegrain after that isn't really effective. Why should it, after all. :D

Why would I do that?:D Using Mdegrain1/2/3 on top already two instances of Mdegrain3. I was referring to how LF errors aka dancing effect can disturb ME engine using Mdegrain if it is not removed before so not only that efficiency od denoising is reduced but also smearing becomes present in those areas where that effect is present.

Which script exactly are you speaking of?

This one

o = last
f = o.MinBlur(1,2).MinBlur(2,2).RemoveGrain(11,-1)
f.FluxSmoothT(7).mt_AddDiff(mt_MakeDiff(o,f,U=2,V=2),U=4,V=4)

# eventually, limit the maximum pixel change to +/- 2 :
# mt_LutXY(o,last,"x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",U=2,V=2)

# to compare:
stackvertical(o,last)
#interleave(o,last)

return(last)

To modify it to have more stronger effect or am I mixing apples with oranges? :p
Thank you

[Didée]

The Question is - what are the apples, and what are the oranges? :)

In which way should it be stronger? Is it that FluxSmooth isn't strong enough (is there still residual flicker of low spatial frequencies)? Or is it that too much grain is in the output? If it's the latter - the whole purpose of this script is to not touch grain at all, and to calm down only the low spatial frequencies.

[SilaSurfer]

The Question is - what are the apples, and what are the oranges? :)

It's a form of expression. :p

In which way should it be stronger? Is it that FluxSmooth isn't strong enough (is there still residual flicker of low spatial frequencies)? Or is it that too much grain is in the output? If it's the latter - the whole purpose of this script is to not touch grain at all, and to calm down only the low spatial frequencies.

I'm fully aware this script is meant for removing LF flicker effect and not grain. ;) So Fluxsmooth should be tweaked to get stronger effect if so are those sideaffects of shading going to be more amplified if I do so? Thank you for your patience. :)

[Didée]

So Fluxsmooth should be tweaked to get stronger effect
Maybe yes, maybe no. Read on.

if so are those sideaffects of shading going to be more amplified if I do so?
Definetly yes. If FluxSmooth is set up more aggressively (i.e. bigger threshold), then it'll do more good where Flux is doing right, and will do more bad where Flux is doing wrong.

Remember FluxSmooth is a simple temporal smoother with median-like decision where to filter and where not.

Examples:

a) a pixel sequence: ... 80 81 85 79 80 ...

Flux will filter the "85" and the "79", because these two pixels are overshooting both of their neighbors.

b) pixel sequence: ... 80 81 85 85 81 80

Flux will filter *nothing*, because no pixel satisfies the "overshooting both neighbors" criteria.

For case b), this means:

- IF those two "85" are due to motion, then Flux has done correct.

- But IF those two "85" in fact are related to "flicker" in a "flat" a/o "static" area, then Flux has not filtered something that you would like to have filtered.


Truth is, this kind of "flickering of low spatial frequencies" is one of the ultimate foes, because right here it is where the nebula-of-uncertainty becomes thick:

a) without mocomp, you can't know if it's flicker or motion

b) with mocomp, you can't know if the mocomp has been misleaded by the flicker

c) With prefiltering before mosearch, you can't know if the prefilter has mangled moving areas (because of a)) and conseqquentially has misleaded the mosearch

Chicken-and-egg problem, without any definite solution.

[SilaSurfer]

Flickering. :devil: Thank you Didée for your explenation. I'm goint to go in a way of using your original script which was used with Zep's source by modifying it for my needs. Testing, testing and more testing.:p

[Didée]

Related - I've though several times if and how the "FluxSmooth principle" could be extended from the current 3-frame temporal window to a 5-frame temporal window.

A reasonable approach would be this:
- calculate temporal median with radius=2
- calculate temporal soften with radius=2
- for each pixel, use that result that caused the smaller difference


Radius=2 temporal median can be done via MedianBlurT, but this implementation is tooooo slow.

Instead, get the nice median2 script by g-force (http://forum.doom9.org/showthread.php?p=1169990#post1169990)!

For convenience and simple usage, create a "TMedian2" wrapper function:

function TMedian2(clip c) {
Median2( c.selectevery(1,-2), c.selectevery(1,-1), c, c.selectevery(1,1), c.selectevery(1,2) ) }

Armed with these helpers, a 5-frame-variant of FluxSmoothT could look like this:

function Flux5framesT(clip c, int "th", int "thC") {
th = default(th,7)
thC = default(thC,th)
med = c.TMedian2()
avg = c.temporalsoften(2,th,thC,24,2)
medD = mt_makediff(c,med,U=3,V=3)
avgD = mt_makediff(c,avg,U=3,V=3)
DD = mt_lutxy(medD,avgD,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?",U=3,V=3)
c.mt_makediff(DD,U=3,V=3)
}

[tormento]

Please port that AVS to x64 aware version ;)

[Didée]

No, I'm bored of it. Wait for the x256-version of Avisynth 7.0.

[SilaSurfer]

Armed with these helpers, a 5-frame-variant of FluxSmoothT could look like this:

function Flux5framesT(clip c, int "th", int "thC") {
th = default(th,7)
thC = default(thC,th)
med = c.TMedian2()
avg = c.temporalsoften(2,th,thC,24,2)
medD = mt_makediff(c,med,U=3,V=3)
avgD = mt_makedif(c,avg,U=3,V=3)
DD = mt_lutxy(medD,avgD,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?",U=3,V=3)
c.mt_makediff(DD,U=3,V=3)
}

Didée I now you get this a lot but you are a genius.:eek:;) Tried the script on the same source and the result is fantastic. Really calms down grain when LF flicker is removed. Now I can use this filtering on a clip for ME analysis. I only have to tweak th setting, right? Thanks again.

[Didée]

For this one, 'th' and 'thC' are the only knobs to tweak, yes.

Somewhere earlier in this thread I had posted a pre-calm script (with MinBlur() and FluxSmooth) - in essence the same as I suggested at the end of this post (http://forum.doom9.org/showthread.php?p=1471926#post1471926) to TheProfileth.

Depending on the source characteristics, using Flux5 instead of simple Flux within such a pre-calmer can make sense.

[SilaSurfer]

Another one for the recipe book. Those sideaffect of shading do not happen with Flux5fremesT script? Thanks Didée.

BTW There is a typo in your Flux5framesT script

avgD = mt_makedif(c,avg,U=3,V=3) --> avgD = mt_makediff(c,avg,U=3,V=3);)

[Didée]

Yeah, a few minutes ago I discovered that typo, too.

Of course, Flux5 is *not* safe in regards to weak shadings in moving areas. Vanilla Flux is not safe, and Flux5 is even less. Well, you can't expect anything else from a simple, thresholded temporal smoother. It's a compromise the user needs to balance out.

[SilaSurfer]

Thanks again Didée for your patience and interest for helping out.

[SilaSurfer]

Didée from your post #70


The biggest difference to Zep's denoising is - most probably, since we didn't see his script up to now - the usage of fft3dfilter. It seems that he used to much of it, or at to strong settings. All the ringing and texture echoing is a typical side-effect fft3dfilter, when not used with enough caution. Judging from the overall look, I'd guess that Zep first did an initial filtering with fft3dfilter, and then continued to further process the result with MV-denoising. (Some places look like fft3d-banding that has been temporally averaged, but it's hard to judge after x264-compression.)

In comparison, my script never applies fft3dfilter in the chain that produces the output clip. Instead, it is only used as a "brake" to keep the 1st temporal filter within reasonable bounds. (Which is essential in the bigger scripts where the 1st stage is done with median filtering.)

Does this mean that whatever is used in prefiltering step in this case Fft3dfilter, is like you never used it, but still got results from it? If so for example I could apply two stages of Flux5FramesT for prefiltering to MDegrain2?

Flux5FramesT().Flux5FramesT() to really make the clip calm.

[SilaSurfer]

Didée nevermind my previous post. I wanted to ask you what do you think about this. Would need some suggestions if you have any.;):D

SetMTMode(5,2)
SetMemoryMax(1000)




MPEG2Source("C:\System\fotr1.d2v", info=3)
Colormatrix(hints=true)

crop(8,78,704,420)
source=last
a=source.Fft3dgpu(sigma=16, sigma2=10, Sigma3=6, sigma4=8, bt=4) # Deblocking and some sigma4 help to Flux5framesT() which comes next
b = a.RemoveGrain(11)
f = b.Flux5FramesT().merge(b,0.49)

Nr1=a.mt_makediff(mt_makediff(b,f,U=3,V=3),U=3,V=3) # Prefiltering clip for MAnalyze

SetMTMode(2)


NR1_super=NR1.Msuper(pel=2, sharp=2)
source_super = source.MSuper(pel=2,sharp=2, levels=1)
bv2=MAnalyse(NR1_super,isb=true, delta=2, overlap=4, truemotion=false)
bv1=MAnalyse(NR1_super,isb=true, delta=1, overlap=4, truemotion=false)
fv1=MAnalyse(NR1_super,isb=false,delta=1, overlap=4, truemotion=false)
fv2=MAnalyse(NR1_super,isb=false,delta=2, overlap=4, truemotion=false)
NR2=source.MDegrain2(source_super, bv1,fv1,bv2,fv2, thsad=300, thscd1=300, thscd2=90).contra(source) # Denoising and Your Contrasharpening. Function (see below)

SetMTmode(5)
sharp0 = NR2.Seesaw(nrlimit=0, nrlimit2=99, bias=49, sstr=1.24, Spower=3, Szp=12, Sdamplo=4, SdampHi=19, Slimit=99, sootheT=0, sootheS=0)
SetMTMode(2)
sharpD = mt_makediff(NR2,sharp0)
zeroD = sharpD.mt_lut("x",Y=-128)

sup1 = NR2.MSuper(pel=2,sharp=2)
sup2 = sharpD.MSuper(pel=2,sharp=2,levels=1)

zeroD.MDegrain2(sup2,bv1,fv1,bv2,fv2) # Motion Compensated Sharpening. Your 2a variant which doesn't denoise. I split the denoising and sharpening to avoid artefacts.

NR2.mt_makediff(last,U=2,V=2)


GradFun2DBmod(thr=1.4, str=1.2, mode=2,adapt=64, temp=50) #Some dihtering and adding grain to prevent blocking and banding
SetMTMode(5)


Spline64resize(704,288)

function contra (clip denoised, clip original)
{
s = denoised.minblur(1,1) # Damp down remaining spots of the denoised clip.
allD = mt_makediff(original,denoised) # The difference achieved by the denoising.
ssD = mt_makediff(s,s.removegrain(11,-1)) # The difference of a simple kernel blur.
ssDD = ssD.repair(allD,1) # Limit the difference to the max of what the denoising removed locally.
ssDD = SSDD.mt_lutxy(ssD,"x 128 - abs y 128 - abs < x y ?") # abs(diff) after limiting may not be bigger than before.

denoised.mt_adddiff(ssDD,U=2,V=2) # Apply the limited difference. (Sharpening is just inverse blurring.)

return( last )
}

This was tested on not so good Dvd source. It contains a lot of dark areas where blocking is present. Areas with grain inherit those nice charming LF errors aka Flicker. So what do you think of my first "cough" advanced script? (Also having a flu overhere):p

[Didée]

Well, what to say. Technically, the flow of processing is all valid. On some sources this will look great, on some sources it will look desastrous. :)

Seeing the source is LOTR, I'd say the prefiltering is MUCH too strong. LOTR is rather clean with only little noise, no need to break a fly on a wheel. The current prefiltering will nuke-out enough content to make the motionsearch worse than it could be. Sometimes less is simply more.

Also, you're producing a little stamp of 704x288. So much filtering for only so few pixels in the result? :D

[SilaSurfer]

True. Lord of the Rings: Fellowship of the ring SEE first part. Yeah Fft3dgpu is really on steroids. Will try it with lowered settings. Thanks

[SilaSurfer]

Yeah that is too much filtering. I lowered Fft3dgpu to sigma=2, bt=1, used Mdegrain1 instead of Mdegrain2, and for sharpening with SeeSaw I used SootheS=25. What is the max value for FluxsmoothT(Temporal)?

[Didée]

Maximum is 255. Perhaps more, but in 8-bit-sources pixel differences can not be larger than 255, anyway.
Of course, with such big threshold there will appear motion artifacts.

Out of the sleeve,

MinBlur(1)
FluxSmoothT().merge(last,0.251)
sbr()

should be a "simple" but effective searchclip-pre-processing for such rather clean sources.


If you don't have them in the toolbox - - -
# Highpass of spatial r=1 Gaussian
function sbr(clip c)
{
rg11=c.removegrain(11,-1)
rg11D=mt_makediff(c,rg11)
rg11DD=mt_makediff(rg11D,rg11D.removegrain(11,-1)).mt_lutxy(rg11D,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?")
c.mt_makediff(rg11DD,U=2,V=2)
}


# Nifty Gauss/Median combination
function MinBlur(clip clp, int r, int "uv")
{
uv = default(uv,3)
uv2 = (uv==2) ? 1 : uv
rg4 = (uv==3) ? 4 : -1
rg11 = (uv==3) ? 11 : -1
rg20 = (uv==3) ? 20 : -1
medf = (uv==3) ? 1 : -333

RG11D = (r==1) ? mt_makediff(clp,clp.removegrain(11,rg11),U=uv2,V=uv2)
\ : (r==2) ? mt_makediff(clp,clp.removegrain(11,rg11).removegrain(20,rg20),U=uv2,V=uv2)
\ : mt_makediff(clp,clp.removegrain(11,rg11).removegrain(20,rg20).removegrain(20,rg20),U=uv2,V=uv2)
RG4D = (r==1) ? mt_makediff(clp,clp.removegrain(4,rg4),U=uv2,V=uv2)
\ : (r==2) ? mt_makediff(clp,clp.medianblur(2,2*medf,2*medf),U=uv2,V=uv2)
\ : mt_makediff(clp,clp.medianblur(3,3*medf,3*medf),U=uv2,V=uv2)
DD = mt_lutxy(RG11D,RG4D,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?",U=uv2,V=uv2)
clp.mt_makediff(DD,U=uv,V=uv)
return(last)
}

[SilaSurfer]

I meant SootheS=75. How come every time I ask you something you hit me with another function?:D;) Thanks Didée I like it a lot!

BTW this doesn't really belong in this thread but since it is connected to my script: MY script crawls on my system even with SetMTMode it doesn't get any faster and I was meaning to ask you what do you think about MVToolsMulti version which has multithreading built in. I know it is somewhat unstable but I could gain a couple fps?

[Boulder]

Maximum is 255. Perhaps more, but in 8-bit-sources pixel differences can not be larger than 255, anyway.
Of course, with such big threshold there will appear motion artifacts.

Out of the sleeve,

MinBlur(1)
FluxSmoothT().merge(last,0.251)
sbr()

should be a "simple" but effective searchclip-pre-processing for such rather clean sources.It seems to blur the image quite a bit even with clean sources. Is that intentional?

[Didée]

Yes, sure, that's intentional. Preprocessing for the searchclip. Did you see that? ;)

If you have a nicely sharp & high-contrast clip, with "default operation as per documentation" you'll end up with pretty big SADs wherever there's an edge. Means, little to nothing will happen on edges. Which is quite counterproductive when the goal is to calm (the effect of) a sharpener.

[Boulder]

Yes, sure, that's intentional. Preprocessing for the searchclip. Did you see that? ;)Of course :) I was just wondering that it was meant for clean sources but your further explanation makes the idea clearer. Probably the function would work just nicely on lower quality sources as well as it at least kills the excess noise and blocks.

[SilaSurfer]

Yeah it's great for ME, just tried it. Works better then Fft3dgpu at least for me. :)

[cobo]

MinBlur(1)
FluxSmoothT().merge(last,0.251)
sbr()


Last is meant to be merged with itself here, or am I misunderstanding?

[Didée]

MinBlur(1)
FluxSmoothT().merge(last,0.251)
sbr()


or, of you prefer, the same with explicit naming:

spatial = MinBlur(1)
temporal = spatial.FluxsmoothT()
mixed = temporal.merge(spatial,0.251)

mixed.sbr()

[davsim]

Thanks to Didée and Sagekilla for all your efforts.

I've just been reading through old threads to catch up on degraining/denoising. I came across the old sample clip Babylon5_snip.m2v and tried quite a few different scripts, until getting this very nice result with Temporal Degrain:

source:

http://i.imgur.com/Vq8r9s.png (http://i.imgur.com/Vq8r9.png)

TemporalDegrain(degrain=2, SAD1=300, SAD2=200, ov=4, blksize=8) :
(also re-encoded as x264)

http://i.imgur.com/YRxZSs.jpg (http://i.imgur.com/YRxZS.png)