Need Suggestions for VERY GRAINY source [Archive]

Zep

1st December 2007, 16:50

I have a 1280 x 720p source. it is VERY GRAINY to the point of be annoying and my enjoyment during viewing is adversely affected. :(

What is even worse and makes this grain even more noticeable is the fact that the grain DANCES around frame to frame so on as an example walls and sky your eye is drawn to this as if thousands of insects are buzzing about lol So I end up seeing that and not what I should be paying attention to.

I have tried DeGrainMedian(limitY=8,limitUV=15,mode=0) and it does not even come close to helping this. it gets rid of some grain but doe not fix the dancing.

I have tried

vbw1=MVAnalyse(isb=true,truemotion=true,delta=1,pel=2,chroma=true,blksize=8,overlap=2,idx=1,sharp=1)
vfw1=MVAnalyse(isb=false,truemotion=true,delta=1,pel=2,chroma=true,blksize=8,overlap=2,idx=1,sharp=1)
vbw2=MVAnalyse(isb=true,truemotion=true,delta=2,pel=2,chroma=true,blksize=8,overlap=2,idx=1,sharp=1)
vfw2=MVAnalyse(isb=false,truemotion=true,delta=2,pel=2,chroma=true,blksize=8,overlap=2,idx=1,sharp=1)
MVDegrain2(last,vbw1,vfw1,vbw2,vfw2,thSAD=100,idx=1)

Same result basically. However I have a feeling someone who knows MVDegrain2 very well could help me with parms to better make this work since I never used MVDegrain2 until to today.

I have tried HQDN3D with interesting results. It gets the grain semi ok but same problem in that any grain left over is dancing
so your eye is drawn to it.

I have tried FFT3DFilter and same as all of the above and it tend to blur a little more. Though using this after some of the above with a light setting helps.

I have also tried a temporal smoother after all the above and it helps some but starts to blur/lose detail.

ok you can get a 9 meg clip from this link which first shows a WALL with grain then the sky with mega grain.

http://www.megaupload.com/?d=Z8EUNJY4

any suggestions?

Thanks!

buzzqw

1st December 2007, 17:49

file not avaiable

BHH

DeathAngelBR

1st December 2007, 18:23

I have also tried a temporal smoother after all the above and it helps some but starts to blur/lose detail.

Maybe a sharpener after the denoise filter chain can fix that.

mikeytown2

1st December 2007, 20:54

MVDegrain2(last,vbw1,vfw1,vbw2,vfw2,thSAD=100,idx=1)

If you increase this 10x to oh
MVDegrain2(last,vbw1,vfw1,vbw2,vfw2,thSAD=1000,idx=1)
it actually works fairly well. Add these and you got a nice looking video
FFT3dGPU()
LimitedSharpenFaster()

In terms of detail loss, the grain is what gives that clip its perceived detail.

Spuds

2nd December 2007, 00:22

Hard to say exactly what to do with that since the vid does not have much detail to use as an anchor. I ran mc_spuds with various settings on the clip, pick what you think looks best to your eye if any.

Here is the wall:
http://img81.imageshack.us/img81/6376/walloneaj0.th.jpg (http://img81.imageshack.us/my.php?image=walloneaj0.jpg)

Here is the sky:
http://img66.imageshack.us/img66/5757/skyoneur4.th.png (http://img66.imageshack.us/my.php?image=skyoneur4.png)

R3Z

3rd December 2007, 05:20

How about posting a non cropped original source ?

The source you posted has no detail apart from the noise, so any recomendations made on the source you posted might not work.

Zep

3rd December 2007, 05:22

file not avaiable

BHH

that is strange I just Downloaded the file from the link fine.

hmmm...

Zep

3rd December 2007, 05:23

Zep

3rd December 2007, 05:28

Hard to say exactly what to do with that since the vid does not have much detail to use as an anchor. I ran mc_spuds with various settings on the clip, pick what you think looks best to your eye if any.

ahhh very good results with some of those settings.

The in between settings work very well. Leave a little grain
and still keeps all the detail.

thanks

Zep

3rd December 2007, 05:35

How about posting a non cropped original source ?

The source you posted has no detail apart from the noise, so any recomendations made on the source you posted might not work.

I will make one and put it up tomorrow along with
a clip I did that came out very well in my first dozen or so
tests with all the above suggestions. In fact I will un crop
the original clip so you all get an better idea of the detailed stuff
as well as able to compare to what I feel is the best filtered
clip thus far.

thanks!

Sagekilla

3rd December 2007, 06:50

This looks like a clip from 300, because the grain looks very similar to the one in it. But that's just what I think.

Dark Shikari

3rd December 2007, 07:11

This looks like a clip from 300, because the grain looks very similar to the one in it. But that's just what I think.If it is, I would recommend a combination of HQdn3D and RemoveGrain(19), as thats what I used.

Sagekilla

3rd December 2007, 07:34

If it is, I would recommend a combination of HQdn3D and RemoveGrain(19), as thats what I used.

Yeah, I'm quite certian now that it is.. Those clouds look like the ones from 300. Also, could you post a sample screenshot of before and after? I'm curious as to how well that works, since I plan on re-encoding 300 (Despite the fact that I managed to get it to about 1.5 GB at full DVD resolution somehow without any external filters..) Here's what I mean:

http://img.photobucket.com/albums/v621/Sagekilla/300_clip.png

Looks almost identical to the types of clouds up there, and the noise too. It's kind of hard to tell in the picture I have here because this was post-encode, not the source file. Even if it's not 300, the grain type looks very similar to 300, and that combination you used might work just as well.

Dark Shikari

3rd December 2007, 08:14

Yeah, I'm quite certian now that it is.. Those clouds look like the ones from 300. Also, could you post a sample screenshot of before and after? I'm curious as to how well that works, since I plan on re-encoding 300 (Despite the fact that I managed to get it to about 1.5 GB at full DVD resolution somehow without any external filters..) Here's what I mean:

http://img.photobucket.com/albums/v621/Sagekilla/300_clip.png

Looks almost identical to the types of clouds up there, and the noise too. It's kind of hard to tell in the picture I have here because this was post-encode, not the source file. Even if it's not 300, the grain type looks very similar to 300, and that combination you used might work just as well.I got 300 at 720p to 700MB without serious quality issues (slight background blocking, detail loss, but nothing atrocious) so you should be able to shrink it well beyond that at standard definition.

Basically the issue is that any noise reduction that actually gets rid of the grain is going to cut the detail enough to make it very compressible.

Zep

4th December 2007, 21:48

This looks like a clip from 300, because the grain looks very similar to the one in it. But that's just what I think.

you are correct! great eyes! :)

I have been ripping the BluRay over and over trying to get rid of the damn grain which almost
ruins the movie for me ( I love the movie enough to try and fix it for my own personal tastes)

I'm uploading an original clip and my best effort at grain removal now. note the size difference as
well. The original clip 98 megs and the grain removal 73 megs. I compressed the clips single
constant quality of Q=1 in xvid and no bframes and everything turned up to max for these clips.
It shows very well the huge difference grain removal has on this movie.

anyway,

I thought about turning up the grain removal even more and trying a sharpen filter after
but I'm afraid of losing too much detail so for now I'm trying to find a grain removal amount
that I can stand and that does not hurt the detail much. I think this latest round it damn good
as you will see after you DL both clips and compare.

here are the clips

Original (http://www.megaupload.com/?d=UALDTUIM)

With grain removal (http://www.megaupload.com/?d=HQFBODID)

Thanks

Dark Shikari

4th December 2007, 22:07

you are correct! great eyes! :)

I have been ripping the BluRay over and over trying to get rid
of the damn grain which ruins the movie for me (well sorta since
I love the movie enough to try and fix it for my own personal tastes)

I'm uploading an original clip and my best effort at grain removal now
and will post link in a few minutes once both are all up.I got 300 to under 700 megabytes and completely denoised, so you should be able to do it too.

As I said, HQDN3D, RemoveGrain(19), and fft3dfilter are your friends.

Sagekilla

4th December 2007, 23:40

you are correct! great eyes! :)

I have been ripping the BluRay over and over trying to get rid of the damn grain which almost
ruins the movie for me ( I love the movie enough to try and fix it for my own personal tastes)

I'm uploading an original clip and my best effort at grain removal now. note the size difference as
well. The original clip 98 megs and the grain removal 73 megs. I compressed the clips single
constant quality of Q=1 in xvid and no bframes and everything turned up to max for these clips.
It shows very well the huge difference grain removal has on this movie.

anyway,

I thought about turning up the grain removal even more and trying a sharpen filter after
but I'm afraid of losing too much detail so for now I'm trying to find a grain removal amount
that I can stand and that does not hurt the detail much. I think this latest round it damn good
as you will see after you DL both clips and compare.

here are the clips

Original (http://www.megaupload.com/?d=UALDTUIM)

With grain removal (http://www.megaupload.com/?d=HQFBODID)

Thanks

Indeed, if you can manage a 25% reduction in file sizes perhaps I can get the same (If not more, since I'm not using matrixes that suck up extra bitrate) reduction in bitrate using Dark Shikari's suggestions.

@Dark Shikari: What settings did you use for HQdn3D to get it to such low bitrates?

Dark Shikari

4th December 2007, 23:55

Indeed, if you can manage a 25% reduction in file sizes perhaps I can get the same (If not more, since I'm not using matrixes that suck up extra bitrate) reduction in bitrate using Dark Shikari's suggestions.

@Dark Shikari: What settings did you use for HQdn3D to get it to such low bitrates?
I think I used (I no longer have the script):

src=last
removegrain(19)
removegrain(19)
DeGrainMedian(mode=0)
fft3dgpu(precision=2)
hqdn3d(0,0,3,6)
fft3dfilter(sigma=0,sharpen=1)
last.mergechroma(src)
Lanczos4Resize(1280,720)

Sagekilla

5th December 2007, 00:12

I think I used (I no longer have the script):

src=last
removegrain(19)
removegrain(19)
DeGrainMedian(mode=0)
fft3dgpu(precision=2)
hqdn3d(0,0,3,6)
fft3dfilter(sigma=0,sharpen=1)
last.mergechroma(src)
Lanczos4Resize(1280,720)

Hm, wish I could do the same with my source but seeing as it's SD-only I'd lose too much sharpness. The following seems to do the job well though, cutting the needed bitrate by over 66%

hqdn3d()
RemoveGrain(19)

Zep

5th December 2007, 04:01

I got 300 to under 700 megabytes and completely denoised, so you should be able to do it too.

As I said, HQDN3D, RemoveGrain(19), and fft3dfilter are your friends.

there is is NO WAY in hell you can get 300 to 700 megs at 1280 x 720p even with max settings in x264. Even at 4.4 gigs I tell the difference in quality VS direct from the bluray.

I cringe at what the quality must be on your encode :)

I tried HQDN3D, RemoveGrain(19), and fft3dfilter.

none were good on their own but maybe all 3 together would be ok but I would expect loss of detail. Note if you are doing the low rez DVD then the grain will not as bad and you will need different methods and more light weight filters could do the job odds are. IMHO of course :)

so did you look at the clips? what did you think?

Dark Shikari

5th December 2007, 04:07

there is is NO WAY in hell you can get 300 to 700 megs at 1280 x 720p even with max settings in x264. Even at 4.4 gigs I tell the difference in quality VS direct from the bluray.Obviously you can tell the difference; you can't get visually lossless at any smaller than the original in most cases anyways.

The quality is quite good overall though if you're not a quality snob. You'd be quite surprised how good x264 is at low bitrates, especially when you've denoised it heavily (thus also reducing the bit cost for highest detail areas).

Zep

5th December 2007, 04:08

I think I used (I no longer have the script):

src=last
removegrain(19)
removegrain(19)
DeGrainMedian(mode=0)
fft3dgpu(precision=2)
hqdn3d(0,0,3,6)
fft3dfilter(sigma=0,sharpen=1)
last.mergechroma(src)
Lanczos4Resize(1280,720)

the fact you had to Lanczos4Resize(1280,720) means you smoothed out the encode IMHO too much and lost detail else no need for that filter call. Which is why I decided not to go that route.

I would love to see a clip of that of the same scenes in my clips. :P

Zep

5th December 2007, 04:12

Obviously you can tell the difference; you can't get visually lossless at any smaller than the original in most cases anyways.

The quality is quite good overall though if you're not a quality snob. You'd be quite surprised how good x264 is at low bitrates, especially when you've denoised it heavily (thus also reducing the bit cost for highest detail areas).

yeah but I want it really good. what is the point of spending all this time tweaking the grain removal only to have lower quality elsewhere?

My goal was to get rid of a good amount of grain and keep it looking as good as the bluray as much as possible on 1 DVD-R.

Dark Shikari

5th December 2007, 04:23

yeah but I want it really good. what is the point of spending all this time tweaking the grain removal only to have lower quality elsewhere?

My goal was to get rid of a good amount of grain and keep it looking as good as the bluray as much as possible on 1 DVD-R.300 has enough grain that if you remove the grain, you will lose loads and loads of detail. Its pretty much unavoidable.

Sagekilla

5th December 2007, 04:56

300 has enough grain that if you remove the grain, you will lose loads and loads of detail. Its pretty much unavoidable.

Yeah, RemoveGrain(19) alone gave the grain a jittery look so I had to keep the HQdn3D before that so it wouldn't have a flicker. A simple LimitedSharpenFaster added on helped retain some "detail" so it didn't look horrendous though.

Wish I had a blu-ray source so I could encode to 720p though.

Zep

5th December 2007, 22:47

300 has enough grain that if you remove the grain, you will lose loads and loads of detail. Its pretty much unavoidable.

which is why if you look at my clips you will see I did not remove all the grain.

Comparing to the Bluray 95% of detail is still there after my grain removal and is the best
balance I could get. i.e. get rid of just enough grain and grain dancing to not annoy me
while watching and thus keep most of detail intact to not annoy me on that front as well :D

Zep

5th December 2007, 23:01

300 has enough grain that if you remove the grain, you will lose loads and loads of detail. Its pretty much unavoidable.

BTW

interestingly enough it is not the grain that annoys me. It
is the DANCING grain. So I feel you can get rid of a lot of
dancing grain and keep detail if you use filters that look for
grain dance and only Degrain those areas while leaving the
rest alone. Most of the grain for instance is NOT on actors
faces and real live stuff. It appears they added in forced grain
to all the CGI created stuff like the cool skies.

I have been experimenting with a edge/detail finding filters than then mask those areas
which I then use so that the grain removal does NOT remove from the masked areas.
In fact I'm doing it right now and the results are very impressive. I have been able
to turn up grain removal while keeping even more detail than before. This
is how I plan to do the final encode for sure. The down side is SUPER SLOW :(
It will take days to encode the final.

Sagekilla

5th December 2007, 23:27

which is why if you look at my clips you will see I did not remove all the grain.

Comparing to the Bluray 95% of detail is still there after my grain removal and is the best
balance I could get. i.e. get rid of just enough grain and grain dancing to not annoy me
while watching and thus keep most of detail intact to not annoy me on that front as well :D

I wish I had a Blu-ray source to work off of like you do, I just went with HQdn3D() after a resize since RemoveGrain(19) decimated WAY too much detail and softened the image a lot.

Pookie

6th December 2007, 00:20

Didee's suggestions from previous threads:

source=last
denoised=fft3dfilter(sigma=8,sigma2=8,plane=4,degrid=1)
backward_vec2 = MVAnalyse(denoised,isb = true, delta = 2, pel = 2, blksize=16, overlap=8, sharp=1, idx = 1)
backward_vec1 = MVAnalyse(denoised,isb = true, delta = 1, pel = 2, blksize=16, overlap=8, sharp=1, idx = 1)
forward_vec1 = MVAnalyse(denoised,isb = false, delta = 1, pel = 2, blksize=16, overlap=8, sharp=1, idx = 1)
forward_vec2 = MVAnalyse(denoised,isb = false, delta = 2, pel = 2, blksize=16, overlap=8, sharp=1, idx = 1)
MVDegrain2(source,backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=800,idx=2)

Didée

6th December 2007, 00:58

Pookie

6th December 2007, 01:13

"Using a prefilter together with such a high thSAD is guaranteed to introduce artifacts in areas where MC fails"

Indeed. You can't tell from the cropped example source file what thSAD values to use because it is only a small segment of wall and sky. It would be nice to see something of detail to determine if the degraining is going to be too strong.

Sagekilla

6th December 2007, 02:33

Similar, but not exactly like that. The prefilter should be able to cut down the grain almost completely. Some loss of detail is nothing to worry about at this stage. Then, thSAD should not be increased, but instead decreased from the default 400.
Using a prefilter together with such a high thSAD is guaranteed to introduce artifacts in areas where MC fails.

Alltogether, that suggestion was just an "easy" version of a general methodology. A script allowing for full control over all aspects is ten times as long as that, and quite a bit slower as well.

I can see plenty of places where the MC fails and 300 becomes a soupy mess.. Namely the snow scene with the wolf, where the snow just accumulates and becomes a soup of artifacts.

Can you recommend a version that'll work without those problems?

Didée

6th December 2007, 17:46

@ Sagekilla:
In other words, you mean if the holy grail of noise removal already has been discovered?
I fear it has not, yet.

@ Zep: Some more thoughts on "dancing" grain.

This sort of "dancing" usually isn't a property of the original grain, at least for the most part. Grain in itself usually is a high-frequency distortion only. The "dancing" effect is introduced by lossy DCT-based compressors, where in the lossy compression process some error is introduced into the low-frequency parts, caused mainly by the hi-frequency parts.

Something to try: the following script will remove the low-frequency flicker, leaving the high-frequencies intact.

#LoadPlugins: MedianBlur.dll
# RemoveGrain.dll
# mt_masktools.dll
# FluxSmooth.dll

AviSource("K:\300_original.avi")

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)

#------------------------------------------
# Taken from MCBob.avs:
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 : -200

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)
}

In result, there will be almost no smoothing, and the grain basically is fully preserved. It's just the flicker, or "dancing" effect, that will be removed.
As a side-effect, there might occur some slight toning-down of shadings when there is motion. One can definetly see it in single-frame comparisons by flipping between original and processed. But one will hardly note that during watching the movie.

Zep

6th December 2007, 22:20

Zep

6th December 2007, 22:22

@ Sagekilla:
In other words, you mean if the holy grail of noise removal already has been discovered?
I fear it has not, yet.

@ Zep: Some more thoughts on "dancing" grain.

This sort of "dancing" usually isn't a property of the original grain, at least for the most part. Grain in itself usually is a high-frequency distortion only. The "dancing" effect is introduced by lossy DCT-based compressors, where in the lossy compression process some error is introduced into the low-frequency parts, caused mainly by the hi-frequency parts.

Something to try: the following script will remove the low-frequency flicker, leaving the high-frequencies intact.

#LoadPlugins: MedianBlur.dll
# RemoveGrain.dll
# mt_masktools.dll
# FluxSmooth.dll

AviSource("K:\300_original.avi")

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)

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

return(last)

#------------------------------------------
# Taken from MCBob.avs:
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 : -200

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)
}

In result, there will be almost no smoothing, and the grain basically is fully preserved. It's just the flicker, or "dancing" effect, that will be removed.
As a side-effect, there might occur some slight toning-down of shadings when there is motion. One can definetly see it in single-frame comparisons by flipping between original and processed. But one will hardly note that during watching the movie.

ok I guess I finally found all the same versions of the plugins you are using.
My result was not that good. for me my removal is much better. not only is more grain
removed and less dancing grain with what does remain but more detail in mine is retained.

however mine runs slower than the above by a fair bit.

thanks for the ideas though :)

Sagekilla

6th December 2007, 23:21

Thanks for the script Didee! It worked much better than any of the other methods before (for me anyway.) I didn't get much of a bitrate reduction, 100-150 kbps at best, but at least the grain isn't jumping around like it used to, and I still get retain some of the "detail," even if some of it is fake from the grain. It may not be the Holy Grail of removing noise/grain, but for 300 it works perfectly.

Edit: I tried it out on my copy of "Knocked Up" as well, and it seemed to do a very nice job of stabilizing the grain so the backgrounds look static for the most part.

Zep

7th December 2007, 10:46

Thanks for the script Didee! It worked much better than any of the other methods before (for me anyway.) I didn't get much of a bitrate reduction, 100-150 kbps at best,

because it is not really doing much. At least for me it only reduces the amount of grain by a very small amount and what is left is dancing around almost as much.

if you want to see a fast and really good grain removal use ffdshow noise removal and turn on Denoise3d but only use the HQ setting and max it out. Very fast and very good.

Now mix that with your avi synth script and tweak from there.

I think you see better results because you are not coming from the Bluray but are using the lower rez version which has far less grain and most of these plugs are geared to low rez DVD. Removegrain just can't cut it on high rez Bluray source and this is where removegrainHD is better and why it was written.

Terranigma

7th December 2007, 15:31

because it is not really doing much.
Did you remove the stackvertical line, and uncomment interleave/mt_LutXY and added selectevery(2,1)?

Didée

7th December 2007, 16:42

Zep, it seems you were expecting the wrong thing from that script...

My result was not that good.
because it is not really doing much. At least for me it only reduces the amount of grain by a very small amount
That was exactly the aim of the exercise. The grain is hardly touched at all. Removed are only the bad effects that the grain forced the original source encoder to do.

...and what is left is dancing around almost as much.
Can't agree with that. To my eyes it looks noticeable different.
If I literally go one step back - so that I hardly can see the hi-freq grain at all anymore - then I still see lots of flickering in the "original", while the lowpass-processed one looks pretty solid.

for me my removal is much better. not only is more grain removed and less dancing grain with what does remain...
no doubt about that. Since my script didnt't try at all to remove any grain, your script surely did remove more.

Again: That script was in no way meant for grain removal. It was also not meant as script to use for final encoding (although one can do so, if the result happens to be sufficient and pleasant.)
It was only showing that one of the major annoyances of very grainy sources, namely the low-frequency flicker - can be tackled with rather simple means.
One step further, something in this direction often is very useful for subsequent motioncompensated denoising. If the flicker is left in, it eventually will also disturb the ME engine (making the vectors follow the flicker, causing spatial shifts where in fact there should be none), which will lower the benefit one can get from MC-NR. When the flicker is taken out before the motion search, chances are better to get more clean vectors.

...but more detail in mine is retained.
Is it so? Or is it perhaps wishful thinking?

Random example: Frame 180.

The overall difference caused by ...

left: my script, right: your 'best.so.far' clip
http://img503.imageshack.us/img503/4121/lowpassdifferencevx4.th.png (http://img503.imageshack.us/my.php?image=lowpassdifferencevx4.png) - http://img207.imageshack.us/img207/7982/zepdifferencehl7.th.png (http://img207.imageshack.us/my.php?image=zepdifferencehl7.png)

Or: flip forth-back between these three: my script - original - your 'best.so.far'
http://img511.imageshack.us/img511/23/lowpassprocessedyn8.th.png (http://img511.imageshack.us/my.php?image=lowpassprocessedyn8.png) - http://img511.imageshack.us/img511/9413/originalut6.th.png (http://img511.imageshack.us/my.php?image=originalut6.png) - http://img228.imageshack.us/img228/799/zepsbestsofarej7.th.png (http://img228.imageshack.us/my.php?image=zepsbestsofarej7.png)

Okay, we didn't see either your latest script or its results, but from what you said it was basically similar to what you showed with 'best.so.far", plus masking of certain areas, allowing for even stronger settings. Now, I doubt that the kinds of negative impacts, as shown above, can be rescued by only a little masking...
Get this right: the result of your 'best.so.far' is not bad at all, it's quite good. But there *is* smearing / shifting, and there *is* detail loss. Hence I can't follow your finding that your script "keeps more detail", when mine doesn't loose any to start with.

We surely all are interested in seeing the latest script you came up with. However, after years of toying around with very grainy sources in all kinds of even-so-sophisticated ways, I can tell: grain removal on strong-grained sources won't ever be perfect. It's always a "you win here, you lose there" game. Winning without losing is out of reach.

---

BTW, what BlureRay is this that we're juggling around with 720p?

Terranigma

7th December 2007, 17:15

One step further, something in this direction often is very useful for subsequent motioncompensated denoising. If the flicker is left in, it eventually will also disturb the ME engine (making the vectors follow the flicker, causing spatial shifts where in fact there should be none), which will lower the benefit one can get from MC-NR. When the flicker is taken out before the motion search, chances are better to get more clean vectors.

Didée, are you saying it'd be more beneficial to use this idea you came up with, to remove low-frequencies, will work better if it's used before mo-comp. denoising?

Didée

7th December 2007, 18:42

this idea you came up with The idea in itself is not exactly new - Fizick once made a basic script with multi-freq filtering, and IIRC that was before his first implementation of FFT3DFilter. It's been a while since then. :D

are you saying it'd be more beneficial to use this idea you came up with, to remove low-frequencies, will work better if it's used before mo-comp. denoising? It's still the basic method of using a pre-filter before doing the motion search. This can be done in several different ways, and this here was just one of them that can be used. E.g., if one is using a pure spatial prefilter, the effect is the opposite: it will take out the hi-freq's, but leave the flicker mostly intact, therefore still irritating the ME engine.
Fact is, with strong grain there is so much uncertainty at the pixel level that there is hardly any "this is the right way to do". There are plenty of different possible points to break into the circle of catch-22 ... but there's no "correct" one.

Terranigma

7th December 2007, 19:05

Ah I see, I understand now. Thanks for clarifying. :)

Sagekilla

8th December 2007, 05:48

Personally, I prefer Didee's script over most plugins I've tried for removing grain since it doesn't blur the image at all, and when it comes to the dancing grain like in 300 it stabilizes it so it doesn't look horrendous after encoding. Really, my biggest beef is how soft the image becomes after most denoise/grain filters so Didee's script is really what I've been looking for.

I really wasn't expecting too much in the bitrate reduction department after I read his explanation, but just the sheer increase in video quality (to my eyes) from not having dancing grain is more then enough.

Pookie

8th December 2007, 08:33

Another one for the cookbook.:D Thanks (again), Didée.

Zep

10th December 2007, 20:49

Another one for the cookbook.:D Thanks (again), Didée.

ok all I finally did the final encode which took 3 days to crunch :D
Please download and take a look I am curious as to all your thoughts!

The clips (http://www.megaupload.com/?d=90HDTJL0)

I learned A LOT from this thread. Nothing worked straight up to the level I wanted and the best by far was to use a little of everything I learned in this thread and test test test then tweak and test some more lol I hope you all check out the final result clip I think you will be very surprised at just how awesome it came out and IMHO trounces the original in all aspects.

Some Notes and things I learned about grain.

File Size. Grain kills the ability to compress more than I thought. I used x.264 and to reach a Q=16 average the original needed a 9000 bitrate and mine without grain only needed a 4000 bitrate and mine IMHO looks better and has in some areas more detail. (get to that in a minute)

the codec it self plays a huge part on detail loss even with massive bitrate. In this case I learned x.264 blows out detail no matter how much bitrate you give it because of the inloop filters so if you have the bitrate turn them off. If you do not then yeah leave them on as they help a ton with blocking etc....

grain and dancing grain (dancing grain is what really annoys me) really is only noticeable to the point of distraction on walls, and sky and wheat fields and skin (not face as much like say a women's smooth tummy, i.e. not so detailed skin areas). Where there is lots of detail it gets lost in that detail so that made it easy to find the level of detail and mask then only remove A LOT of grain from the low level detail areas, some from middle detail areas and almost none from high detail areas so we can keep as much detail a possible since the filtering will always get rid of some. Down side is SLOW SLOW SLOW.

Where you place filters in the chain is so important when it comes to what I feel is re-mastering type of filtering. an example is my huge filter chain washed out the colors some and lightened up everything so I had to add more filters to adjust that and when you look at the original you even see that they had the same problem and I was able to make it look even better than the original in that area also like on the shields where the highlights were so bright and huge it made the them look fake but my tweaks added back the bronze color and toned down the contrast so it looked real and the color more rich and vibrant. The thing is if I place the filters at the end of chain it just sorta gave the whole frame a boost and it looked fake since some things shouldn't get the boost. However, if I used it at the start of chain then let all the removal and detail enhancement at it, they knocked it back down to not fake levels and they did it selectively. A bronze shield that needed a touch of more yellow-bronze got it but a silver sword did not else it would have turned purple or blue and not stayed silver looking. very interesting results here.

Anyway, if you watch the clips note the wheat behind the bad guy while he says "the hot gates" huge difference in dancing pixels between the clips. A ton to none. After that the sky is next place that looks so much better. Even the kings son's face looks better because in this example the dancing grain was drawing your eye away from detail. This is what I meant above by how some detail is even better with the grain removed. Another is the pull back shot with wheat all around. The original has so much dancing grain it makes it hard to see each stalk since the grain is jumping on and off them and since each grain was as large or larger that the stalk width it hid them but with it gone you can see each stalk and the fine lines. The wheat has more detail now and so does the mountain range in the distance or perhaps I should say it has more perceived detail. :P

Anyway I am very pleased with the results and the only thing I may do differently is to run it again with more bitrate :)

Sagekilla

10th December 2007, 21:14

because it is not really doing much. At least for me it only reduces the amount of grain by a very small amount and what is left is dancing around almost as much.

if you want to see a fast and really good grain removal use ffdshow noise removal and turn on Denoise3d but only use the HQ setting and max it out. Very fast and very good.

Now mix that with your avi synth script and tweak from there.

I think you see better results because you are not coming from the Bluray but are using the lower rez version which has far less grain and most of these plugs are geared to low rez DVD. Removegrain just can't cut it on high rez Bluray source and this is where removegrainHD is better and why it was written.

The point for me is not to touch the grain in 300 since it's very difficult to remove grain and retain sharpness. I refuse to degrain if it means my image is becoming smoother, and I've already encoded the video and quite like how the results have come out.

Edit: To clarify, none of the degrain scripts I've tried have offered a decent way to get rid of the dancing grain (Which is my goal really) while maintaining sharpness, and Didee's script is what really does this for me. Plus, I don't use ffdshow at all so I can't do postprocessing that way.

Zep

10th December 2007, 21:52

The point for me is not to touch the grain in 300 since it's very difficult to remove grain and retain sharpness. I refuse to degrain if it means my image is becoming smoother, and I've already encoded the video and quite like how the results have come out.

Edit: To clarify, none of the degrain scripts I've tried have offered a decent way to get rid of the dancing grain (Which is my goal really) while maintaining sharpness, and Didee's script is what really does this for me. Plus, I don't use ffdshow at all so I can't do postprocessing that way.

you say all that without looking at my final clip (for now anyway odds are I will run more testing next weekend) or reading my last post I take it.

My clip has almost no grain and almost no loss of detail and in some areas more detail and I do it at half the bitrate of the original. If I had to choose which one to watch I would take mine by miles and I bet most would and that is right now. I could easily make it even better if I wanted to spend more time and use the same bitrate as the original. (I would get the Q average in x.264 down to 12 I bet and could turn off the in loop filters hahaha)

The bit rate issue alone is such a huge plus you could really go to town with more filtering like mega masking for selective removal as well as selective sharpening. Furthermore, IIRC you said you do not have the Bluray. if you did you would see that Didee's script doesn't work on it that well. Dancing grain was almost as bad and there was loss of detail on top of that. My guess is the same reason removegrainHD was made. With higher rez source you need go beyond just 9 pixel box to catch the grain. Anyway, that script may work on low rez stuff but it didn't do much on direct from the Bluray source. Trust me I wish it did as it would have saved me a lot of time.

Anyway, download my latest clip and compare as an example the start of the clip the kings face VS the original. The detail is still there. (read my post above about MASKING and you will know why it is still there)

StifflerStealth

10th December 2007, 23:47

Sagekilla

11th December 2007, 00:34

you say all that without looking at my final clip (for now anyway odds are I will run more testing next weekend) or reading my last post I take it.

My clip has almost no grain and almost no loss of detail and in some areas more detail and I do it at half the bitrate of the original. If I had to choose which one to watch I would take mine by miles and I bet most would and that is right now. I could easily make it even better if I wanted to spend more time and use the same bitrate as the original. (I would get the Q average in x.264 down to 12 I bet and could turn off the in loop filters hahaha)

The bit rate issue alone is such a huge plus you could really go to town with more filtering like mega masking for selective removal as well as selective sharpening. Furthermore, IIRC you said you do not have the Bluray. if you did you would see that Didee's script doesn't work on it that well. Dancing grain was almost as bad and there was loss of detail on top of that. My guess is the same reason removegrainHD was made. With higher rez source you need go beyond just 9 pixel box to catch the grain. Anyway, that script may work on low rez stuff but it didn't do much on direct from the Bluray source. Trust me I wish it did as it would have saved me a lot of time.

Anyway, download my latest clip and compare as an example the start of the clip the kings face VS the original. The detail is still there. (read my post above about MASKING and you will know why it is still there)

Yeah but there's exactly that: You have HD vs my SD. I don't know how well my source would hold up to your script. I'd love to test your script on my SD source but I haven't found a script (or didn't look hard enough, will later when I'm not so busy)

Didée

11th December 2007, 13:38

Please download and take a look I am curious as to all your thoughts!
In a nutshell:

- Grain removed, at the price of:

- faces often times look soapy
- some detail is emphasised, some detail is lost or blurred
- there is edge ringing and mosquito noise / texture echoes caused by FFT3DFilter

Anyway I am very pleased with the results and the only thing I may do differently is to run it again with more bitrate :) For what you have there, the bitrate is fully sufficient. More bitrate won't help for the downsides introduced by your filterchain.

It's by all means a respectable try, but "remastering" (your words) needs a bit more than this.

Zep

11th December 2007, 22:55

Zep, could you post your final AVS script that you used to make that final build? I would love to learn off of it. I have other movies that I own that are grainy and it ticks me off each time I watch them. They are as bad as 300, especially the first two Harry Potter movies. It's like they cone back to Video Tape days. :(

And I too have learned a lot about grain in this thread. The tips posted here are invaluable.

so I take it you watched the clips and like my final result? if you compare them side by side the difference really is huge and at half the bitrate I am very happy with the result.

so which one would you watch? hahaha

yes I will post the script first chance I get.

Zep

11th December 2007, 23:01

Yeah but there's exactly that: You have HD vs my SD. I don't know how well my source would hold up to your script. I'd love to test your script on my SD source but I haven't found a script (or didn't look hard enough, will later when I'm not so busy)

yeah my script may not work so well on lower rez stuff. I admit I spent hours and hours tweaking to the point it may only work on this movie and its grain for all I know.

What is even worse the speed. Even pass 1 in x.264 was only like 10 FPS and I normally get like 40 FPS when do just basic filtering.

Pass 2 was like 1.7 FPS :(

Did you get a chance to look at the final encode? Just curious as to your thoughts about it and if you felt it kept enough detail.
yes there was and will always be a little loss of detail but I tried very hard to keep the loss in the detail areas to a minimum via masking. it is by no means perfect.

Zep

12th December 2007, 00:15

In a nutshell:

- Grain removed, at the price of:

- faces often times look soapy
- some detail is emphasised, some detail is lost or blurred
- there is edge ringing and mosquito noise / texture echoes caused by FFT3DFilter

For what you have there, the bitrate is fully sufficient. More bitrate won't help for the downsides introduced by your filterchain.

It's by all means a respectable try, but "remastering" (your words) needs a bit more than this.

well if you look at the original there is just as much mosquito noise and even more in some scenes which I could upload if you really wanted to see more. And I could get rid of it with more tweaking and a mosquito noise filter in the chain. heck even adding undot may fix it since it is so light mosquito noise but I haven't gotten that far yet and I doubt I ever will.

"It's by all means a respectable try" thank you and I can improve and may give it a go some more in the areas you noted. I too saw the cons but it is slow going to test. I need a 8 core box for sure haha

Please do not twist context/meaning of what I said. I certainly did not say it is "remastering" in the hard core way you are trying to make it sound like I said.

what I did say however was "I feel is re-mastering type of filtering"

"I feel" as in my opinion

"type of filtering" as in it is not remastering in the classic sense but in the general sense of giving an over all better experience even at the cost of some things taking a slight hit. Also note this really is meant to be seen in motion. That is what I tweaked it for. if you do frame to frame compares only then yes you can see the cons a lot easier and will not even see the dancing grain in stills which was my main goal to get rid of even if it meant other areas had to take a slight degradation. This thread is about grain removal first and foremost after all. ;)

of course even with the cons the big question is, based on just the 1 clip which would you rather watch? Me I can't stand the dancing grain so you know what I would watch :D

Zep

12th December 2007, 00:20

It's by all means a respectable try

BTW - since you do have the original source clip why not give it a go and see what you can do with it and upload here so we can all learn even more. I for one would use anything you come up with to make it even better.

thanks,

Zep

dbzgundam

12th December 2007, 17:10

Be grateful you guys can at least enjoy the grain as an unmuddied mess in the Blu-Ray version. :)

The DVD version is not as forgiving (http://thevideophile.blogspot.com/2007/08/biggest-fucking-letdown-ever.html)

The heavy grain look as of late is just a mystery to me. I understand wanting SOME grain in an image, but film stocks have improved drastically over the last few years in constant efforts to reduce this if anything, and the advent of digital video has only led to nearly-grain-free (Well it is grain free, but has noise now) picture quality... Oh well.

I actually used degrain1 for this beast, and it handled it pretty well. The movie is actually fairly compressible due to the softness of the picture, large amount of slow motion scenes, and while it does have high contrast, a lot of blown out areas make it that much less difficult to compress.

Sagekilla

12th December 2007, 22:11

yeah my script may not work so well on lower rez stuff. I admit I spent hours and hours tweaking to the point it may only work on this movie and its grain for all I know.

What is even worse the speed. Even pass 1 in x.264 was only like 10 FPS and I normally get like 40 FPS when do just basic filtering.

Pass 2 was like 1.7 FPS :(

Did you get a chance to look at the final encode? Just curious as to your thoughts about it and if you felt it kept enough detail.
yes there was and will always be a little loss of detail but I tried very hard to keep the loss in the detail areas to a minimum via masking. it is by no means perfect.

Yes I did look at the encode, and personally I think if I were to use your script for encoding 300 it wouldn't be too bad since I'm using a much smaller resolution. (864x368 vs 1920x816) Plus I do use 1-pass crf so wouldn't have to worry about it being slow on a first pass since I am doing only one :)

Zanejin

12th December 2007, 22:16

The heavy grain look as of late is just a mystery to me. I understand wanting SOME grain in an image, but film stocks have improved drastically over the last few years in constant efforts to reduce this if anything, and the advent of digital video has only led to nearly-grain-free (Well it is grain free, but has noise now) picture quality... Oh well.

Grain is apparently becoming more and more popular and is not as undesired as one may think. It may give the illusion of detail and improve perceived color depth by dithering, or its abundance may simply appear more attractive to the general public. Much of 300's grain was added after filming.

Sagekilla

12th December 2007, 22:18

Pookie

14th December 2007, 09:37

Looks like Kassandro has chimed in on this topic-

http://videoprocessing.11.forumer.com/viewtopic.php?t=102

Didée

15th December 2007, 05:47

To not get accused of only babbling & critizising, without demonstrating something better, I gave it a go. Note it was quite an effort, since my PC is sub- (sub-sub-sub-...)-par for using demanding filters on & H264-encoding of HD content. You guys have machines that crunch 10 times faster than mine ...

Sample: MegaUpload (http://www.megaupload.com/de/?d=MVMZ5GTJ) -or- RapidShare (http://rapidshare.com/files/76643066/easy.mkv.html) (67MB)
[edit: now with working links...]

Bitrate came out a tad higher than that of Zep's sample (his: 4992 kbit, mine: 5066 kbit). No color correction was done. The grain was processed strictly temporal (spatial processing was only used for probability checks, but not applied in the denoising chain), and straightforward: no kind of area/detail/whatever masking was used.
Also, no arbitrary "pimp-it-up" sharpening was used; what has been used is a "dont-add-more-than-what-was-removed-previously" kind of sharpening. The goal was to keep the result looking the same as the original does ... just without the grain.

The filterchain definetly could benefit from some additional twists, but my pre-Christian Celeron doesn't allow for more. (That's why the result is named "easy".) The x264 encoding surely could be done better too - I'm an old-fashioned Xvid user, tweaking x264 is too complicated for me.:) (truley, I'm not fully satisfied with what I managed to get from x264. Is someone giving lessons?)

Some screenshots:

(middle= original / left= Zep's / right= my try)

Frame 50: http://img89.imageshack.us/img89/8953/fr50zeptx4.th.png (http://img89.imageshack.us/my.php?image=fr50zeptx4.png) <= http://img502.imageshack.us/img502/2481/fr50origfj5.th.png (http://img502.imageshack.us/my.php?image=fr50origfj5.png) => http://img502.imageshack.us/img502/5325/fr50easyis9.th.png (http://img502.imageshack.us/my.php?image=fr50easyis9.png)

Frame 686: http://img502.imageshack.us/img502/6344/fr686zephs1.th.png (http://img502.imageshack.us/my.php?image=fr686zephs1.png) <= http://img262.imageshack.us/img262/6521/fr686orighy8.th.png (http://img262.imageshack.us/my.php?image=fr686orighy8.png) => http://img502.imageshack.us/img502/4734/fr686easyyh5.th.png (http://img502.imageshack.us/my.php?image=fr686easyyh5.png)

Frame 910: http://img502.imageshack.us/img502/6100/fr910zepwh2.th.png (http://img502.imageshack.us/my.php?image=fr910zepwh2.png) <= http://img502.imageshack.us/img502/6963/fr910origci3.th.png (http://img502.imageshack.us/my.php?image=fr910origci3.png) => http://img502.imageshack.us/img502/2824/fr910easygd4.th.png (http://img502.imageshack.us/my.php?image=fr910easygd4.png)

Frame 1274: http://img502.imageshack.us/img502/5051/fr1274zepne5.th.png (http://img502.imageshack.us/my.php?image=fr1274zepne5.png) <= http://img502.imageshack.us/img502/9753/fr1274origmy6.th.png (http://img502.imageshack.us/my.php?image=fr1274origmy6.png) => http://img502.imageshack.us/img502/1777/fr1274easyjz6.th.png (http://img502.imageshack.us/my.php?image=fr1274easyjz6.png)

Frame 2100: http://img502.imageshack.us/img502/281/fr2100zepmx7.th.png (http://img502.imageshack.us/my.php?image=fr2100zepmx7.png) <= http://img502.imageshack.us/img502/9140/fr2100origux3.th.png (http://img502.imageshack.us/my.php?image=fr2100origux3.png) => http://img502.imageshack.us/img502/5899/fr2100easydb1.th.png (http://img502.imageshack.us/my.php?image=fr2100easydb1.png)

[post break because of image limit]

Didée

15th December 2007, 05:48

[continued]

Four Zoomings to quickly point out differences:

http://img262.imageshack.us/img262/5415/fr910zoom1zepja4.th.png (http://img262.imageshack.us/my.php?image=fr910zoom1zepja4.png) vs. http://img262.imageshack.us/img262/4253/fr910zoom1easybp7.th.png (http://img262.imageshack.us/my.php?image=fr910zoom1easybp7.png)

http://img262.imageshack.us/img262/6372/fr910zoom2zeprb1.th.png (http://img262.imageshack.us/my.php?image=fr910zoom2zeprb1.png) vs. http://img262.imageshack.us/img262/2808/fr910zoom2easyhz2.th.png (http://img262.imageshack.us/my.php?image=fr910zoom2easyhz2.png)

http://img262.imageshack.us/img262/3802/fr1274zoom1zepbb7.th.png (http://img262.imageshack.us/my.php?image=fr1274zoom1zepbb7.png) vs. http://img262.imageshack.us/img262/2751/fr1274zoom1easyqd3.th.png (http://img262.imageshack.us/my.php?image=fr1274zoom1easyqd3.png)

http://img262.imageshack.us/img262/2857/fr1274zoom2zepdm7.th.png (http://img262.imageshack.us/my.php?image=fr1274zoom2zepdm7.png) vs. http://img262.imageshack.us/img262/7929/fr1274zoom2easyku0.th.png (http://img262.imageshack.us/my.php?image=fr1274zoom2easyku0.png)

Hope this is sufficient to make my point: removing grain is okay if it annoys, but I'd want my result to keep the "natural" look. Sharp soup I like to eat, but not to watch.

Edit - the script: (compact version)

# LoadPlugins: FFT3DFilter.dll / mt_masktools.dll / MVTools.dll / RemoveGrain.dll / Repair.dll

AVCSource("X:\original.dga",deblock=true)

o = last
fft = o.fft3dfilter(sigma=16,sigma2=10,sigma3=6,sigma4=4,bt=5,bw=16,bh=16,ow=8,oh=8)
fftD = mt_makediff(o,fft)

b3vec1 = fft.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)
b2vec1 = fft.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
b1vec1 = fft.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f1vec1 = fft.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f2vec1 = fft.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
f3vec1 = fft.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)

NR1 = o .MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=2)
NR1D = mt_makediff(o,NR1)

DD = mt_lutxy(fftD,NR1D,"x 128 - abs y 128 - abs < x y ?")
NR1x = o.mt_makediff(DD,U=2,V=2)

NR2 = NR1x.MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=3)

s = NR2.minblur(1,1)
allD = mt_makediff(o,NR2)
ssD = mt_makediff(s,s.removegrain(11,-1))
ssDD = ssD.repair(allD,1) .mt_lutxy(ssD,"x 128 - abs y 128 - abs < x y ?")

NR2.mt_adddiff(ssDD,U=2,V=2)

return(last)

#------------------------------------------
# Taken from MCBob.avs:
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 : -200

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)
}

Note#1: The green part in the "ssDD=..." line was actually missing:eek: when I was creating the sample! Without that lutxy(), in some places a small amount of the original low-freq flicker is reintroduced. Consequentially, the sample is worse than it should have been. (a bit, at least) :)

Note#2: The script uses MVDegrain3. If you don't have MVTools v1.9.0, you can either use MVDegrain2 instead (with slightly worse results), or make a donation to Fizick (recommended!) to get the goodies more early. :)

Zanejin

15th December 2007, 07:39

Didée, both download links for your clip are... mis-pasted, shall we say? The results look great, though, and the zoomed-in screen-captures definitely show that your encode removes grain at a lower cost to detail—especially facial detail and skin features.

jeffy

15th December 2007, 07:41

Didée, please, could you:
1) correct the links to your samples
2) post the final script you used for encoding
EDIT: added: 3) the x264 commandline you used
Thank you.

Didée

15th December 2007, 15:51

The links are correct now. Sorry, it was in the middle of the night ...

post the final script you used for encoding
With pleasure. The final script used for encoding was this:

l = AviSource("processed_left_half.avi") .crop(0,0,640,528)
r = AviSource("processed_right_half.avi") .crop(64,0,640,528)

stackhorizontal( l, r ) ;) :)

The commandline was
--bframes 3 --b-pyramid --ref 4 --deblock -3:-3 --crf 18.75 --ipratio 1.25 --partitions all --direct temporal
--weightb --me hex --subme 5 --mixed-refs --bime --8x8dct --no-fast-pskip --aq-strength 0.2 --aq-sensitivity 12.5
--deadzone-inter 5 --deadzone-intra 9 -o "X:\easy.mkv" "X:\glue.left.right.avs"

Terranigma

15th December 2007, 15:57

EDIT: added: 3) the x264 commandline you used
Thank you.
use avinaptic to get the info.

The x264 encoding surely could be done better too - I'm an old-fashioned Xvid user, tweaking x264 is too complicated for me.:) (truley, I'm not fully satisfied with what I managed to get from x264. Is someone giving lessons?)

People tend to optimize their settings for maximum efficiency, and what I mean by this is optimizing for top quality alongside speed and grain retention. Because of how trellis-2 operates, no one really uses it (unless adaptive quantization is used as well to help with grain retention.)

Settings that aren't, and shouldn't be used for this type of processing, is b-rdo, subme-7, and trellis-2 for one. Also, sometimes, cpu usage plays a part in this as well, so mixed references is usually a no no :)

If you'd' like to see what the experts tends to leans towards, then you can get an idea from this commandline:

--pass 2 --bitrate xxxx --keyint 250 --min-keyint 25 --ref 5 --no-fast-pskip --bframes 3 --b-pyramid --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --partitions all --8x8dct --direct auto --ratetol 1.5 --me umh --threads auto --thread-input --cqmfile "Prestige CQM.cfg" --progress --no-psnr --no-ssim --output "C:\Output Video.mkv" "C:\Input Video.avs"

Of course, getting to know what bitrate should be used, a crf encode is usually done first of a rate between 18.0 - 22.0. Mostly, 20.0

nice grain/quality/cpu usage/encoding speed. Adaptive quantization most of the times isn't needed with the above.

jeffy

15th December 2007, 16:39

The links are correct now. Sorry, it was in the middle of the night ...

With pleasure. The final script used for encoding was this:

l = AviSource("processed_left_half.avi") .crop(0,0,640,528)
r = AviSource("processed_right_half.avi") .crop(64,0,640,528)

stackhorizontal( l, r ) ;) :)

Didée: you know what I meant, we're not playing scrabble, are we? :) :D
Could you please post *cough* all the scripts you used until you reached these final encodes in their final form? :p
(I don't think think I will find a better wording.)

foxyshadis

15th December 2007, 21:00

The interesting thing about yours, Didée, is that it seems to meld the grain into what looks like fine detail. It's probably not the detail that was on the film prints, but it's essentially the same fake detail that the eye creates out of the grain.

Frankly, I'd love to use whatever you did on some detail-free videos, by first overlaying them with layers of grain. I've been trying to do that for years, but I could never find the right add/remove cycle to keep it from dancing and swimming.

Sagekilla

16th December 2007, 00:47

Terranigma

16th December 2007, 00:56

I noticed in the close up of faces yours had more skin detail than Zep's.
Perhaps because zep's was oversharpened? Sure, it may look great while playing, but when zoomed, you can see the detail that was destroyed. It's never good to oversharpen; there's a detail analysis out there that talks about edge-enhancement; maybe you could find it. :)

Didée

16th December 2007, 04:41

Could you please post *cough* all the scripts you used until you reached these final encodes in their final form?
You man ALL the scripts I used until finally arriving where we are now? Are you serious? That's probably thousand scripts and more, over all the years! :p

@ Terranigma: Thanks for the tips.;) In fact it's not too surprising ... it's a few details which are hard to judge from the theoretical side, while practice then may be different even more. (And doing much of testing is no fun for me ... if you had my PC, you would understand why...)
BTW, the latest plaything of Dark Shikari (new AQ) seems to come along very nice. I like it much. Hope that it's "generic" enough to become an official feature...

* * *

OK, I added the script to post#61 (http://forum.doom9.org/showthread.php?p=1076276#post1076276). The only change is that I added a small check that ultimately should have been there, but wasn't :o ...

In my opinion, the script's processing is rather easy, technically. It's kind of slow because quite some MV-stuff is used - but the mere processing chain is in no way fancy, but pretty straightforward. (It's a stripped-down-to-bare-bone version of really fancy grain removal scripts...)

The script again, blown up with some comments and hook-in points for easier modification:
AVCSource("X:\original.dga",deblock=true)

o = last
fft = o.fft3dfilter(sigma=16,sigma2=10,sigma3=6,sigma4=4,bt=5,bw=16,bh=16,ow=8,oh=8)

# "srch" is a prefiltered clip on which the motion serach is done.
# Here, we simply use FFT3DFilter. There're lots of other possibilities. Basically, you shouldn't use
# a clip with "a tiny bit of filtering". The search clip has to be CALM. Ideally, it should be "dead calm".
srch = fft

# "spat" is a prefiltered clip which is used to limit the effect of the 1st MV-denoise stage.
# For simplicity, we just use the same FFT3DFilter. There're lots of other possibilities.
spat = fft
spatD = mt_makediff(o,spat)

# motion vector search (with very basic parameters. Add your own parameters as needed.)
b3vec1 = srch.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)
b2vec1 = srch.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
b1vec1 = srch.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f1vec1 = srch.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f2vec1 = srch.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
f3vec1 = srch.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)

# 1st MV-denoising stage. Usually here's some temporal-median filtering going on.
# For simplicity, we just use MVDegrain.
NR1 = o .MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=2)
NR1D = mt_makediff(o,NR1)

# limit NR1 to not do more than what "spat" would do
DD = mt_lutxy(spatD,NR1D,"x 128 - abs y 128 - abs < x y ?")
NR1x = o.mt_makediff(DD,U=2,V=2)

# 2nd MV-denoising stage. We use MVDegrain.
NR2 = NR1x.MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=3)

# contra-sharpening: sharpen the denoised clip, but don't add more to any pixel than what was removed previously.
# (Here: a simple area-based version with relaxed restriction. The full version is more complicated.)
s = NR2.minblur(1,1) # damp down remaining spots of the denoised clip
allD = mt_makediff(o,NR2) # 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.

NR2.mt_adddiff(ssDD,U=2,V=2) # apply the limited difference. (sharpening is just inverse blurring)

return(last)

This is what is done:

1) Make a pre-filtering with FFT3DFilter. This one will be used for analysis and probability comparisons.

2) search motion vectors on the (calm) pre-filtered clip.

3) Cut down the grain's amplitude by:

- 3a) Make a motion-compensated denoising (optimally by temporal medianfiltering with temp.radius=2, but I'm having serious issues with the [only] available filter)

- 3b) Limit the effect of 3a) by that of a spatial filter

4) Make a motion-compensated temporal averaging of the clip with flattened grain

5) Sharpen the denoised clip. This is done in such a way that the sharpener is not allow to "add" more than what was previously "removed" by the denoising.

... and that's all, nothing spectacular.

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.)

@ foxyshadis
Yeah, the effect of producing "fixed grainage" ... it's interesting that the effect is almost impossible to avoid when strictly using only temporal averaging. Earlier I tried to get rid of it (it looks poor when the grainage is too strong), but that alwas comes at the cost of serious detail loss. I settled for keeping the effect low, then it looks quite convincing, mostly.

Can't tell if you get the same effect with synthetically generated noise. I suspect the effect comes from the fact that compressed film grain has pretty much invariance in its variance (hope this makes sense), where the gaussian noise of the usual noise generators seems to be much more regular. So, it could be you'd need a way to make the added noise, well, more "dirty".

Sagekilla

16th December 2007, 05:00

How do you convert the parameters for MVDegrain3 to MVDegrain 2? I'm looking at the code and the documentation but I'm having a very hard time converting it.

Edit: Figured it out. To anyone else confused, just replace the MVDegrain3 function with the following in both places it appears in: MVDegrain2(b1vec1,f1vec1,b2vec1,f2vec1,thSAD=300,idx=2)

Edit 2: Love how the filter works, I got a 43% reduction in bitrate when I used the filter chain. I also skewed the results slightly because I had Dark Shikari's new AQ running in both the degrained and straight from source encodes.

Spuds

16th December 2007, 17:32

Didée

As always very nice script, I really like the contra-sharpening section I think I will put that to some use in my overly complicated script :) Seeing the results of degrain3 is also very nice.

There were a couple of things I did not quite understand so if you could be so kind as to help me :confused:

1) on the nr1= line you use idx=2, should that be idx=1 or does the call to mvdegrain3 need to point to a different cache then the idx=1 vectors?

2) on the nr2= line you reuse the original motion vectors in mvdegrain3 but on a different (denoised) frame. At what point do motion vectors become invalid for reuse? I was under the impression that once you changed the center frame that new wing vectors should be computed. I'm also confused by idx in this line but the answer to 1 should help here.

Thanks!

EDIT: Ah now I see what you did, that center frame is not changed but limited. Should have followed the nr1x creation a bit more closely before I typed in my question number 2, now I see why those vectors can be used. Still confused by idx.

Sagekilla

16th December 2007, 17:36

Also, I'd love to see this more complicated version if you know how to/have it! As slow as the script runs with my insane x264 settings (0.8 fps, 20 hours for 60k frames!) I have no qualms with running a several day long encode to degrain 300 at a higher quality. Even a simple little suggestion on how to improve it more would be great :) I wish I could test out MVDegrain3 to see how much better it works, but there's no way for me to make a donation to get it (Seeing as I'm only 17 = no way for me to make that donation)

Didée

16th December 2007, 18:40

Spuds: don't think too complicated!;)
Motion vectors never get "invalid" in that sense. With idx, it's always the same game:

vec = clip1.MVAnalyse( ..., idx = _idx1 )
foo = clip2.MVToolsFunction( vec,.., idx = _idx2 )

As long as clip1 == clip2 (identical), you can (and should) use identical values for _idx1 and _idx2.

As soon as clip1 != clip2 (not identical), you have to use different values for _idx1 and _idx2.

The vectors stored in 'vec' stay valid as long as clip1 and clip2 are of same size, and are in sync. (E.g. If one of both clips got trim()'ed, then you need new vectors, obviously.)

Fizick

16th December 2007, 20:27

Didée

16th December 2007, 21:26

Some things get posted in form of a Function(). Some things get posted in form of a plain script.

Functions do have names. Plain scripts are just nameless plain scripts.

Usually, there is a reason for the decision of whether to post something as function or as plain script. :)

(If it has to be by all means, how about YAMCGC_EV - "Yet another motion compensated grain cruncher (easy version)" ...) :P

Zep

16th December 2007, 21:27

Sagekilla

16th December 2007, 21:31

Note in addition: If you use single MVTools function with some input clip, idx may be simply omitted (it will be set to unique numbers internally for every such call).

Didée,
you must provide some name for your new script! :)
LowFrequencyFlickerRemover (LFFR) or somewhat like MiddleFreqDegrain ?

Sagekilla, be patient. :)

Will do :) I'm really curious as to how much of an improve MVDegrain 3 will be making, and it seems like (from what I can infer) it uses an extra forward and backward motion vector.

Zep

16th December 2007, 21:33

Yes I did look at the encode, and personally I think if I were to use your script for encoding 300 it wouldn't be too bad since I'm using a much smaller resolution. (864x368 vs 1920x816) Plus I do use 1-pass crf so wouldn't have to worry about it being slow on a first pass since I am doing only one :)

haha yeah that should speed things up a good bit :D

Also I use pretty high x.264 settings. When I do get the best script from this thread and all the great ideas from everyone.
I plan to run a HQ-INSANE (Every setting maxed out) MEGA final run which should look awesome for only take like a week to encode :D

Going by what Didee said I have done more tests today and I need to better be able to selectively mask areas so the cons he was talking about are not so bad.

Sagekilla

16th December 2007, 21:35

haha yeah that should speed things up a good bit :D

Also I use pretty high x.264 settings. When I do get the best script from this thread and all the great ideas from everyone.
I plan to run a HQ-INSANE (Every setting maxed out) MEGA final run which should look awesome for only take like a week to encode :D

Going by what Didee said I have done more tests today and I need to better be able to selectively mask areas so the cons he was talking about are not so bad.

Mmm, yes it is quite a bit faster than an HD source, a blazing 0.87 fps! Only settings not maxed are refs (6) and ME (umh)

But, back on topic though, was your script (generally speaking) about the same methodology that Didee was using for degraining?

Terranigma

16th December 2007, 21:35

Will do :) I'm really curious as to how much of an improve MVDegrain 3 will be making, and it seems like (from what I can infer) it uses an extra forward and backward motion vector.
Well, I guess you could compare frames 3 to frames 2 from spuds' mc denoiser. Not sure it'd be that much of a difference like that script though. For now, we must speculate. :P

The thing I'm most interested in, is the faster mvanalyze.
That's why I made this (http://forum.doom9.org/showpost.php?p=1075538&postcount=562) post. :)

Zep

16th December 2007, 21:38

Grain is apparently becoming more and more popular and is not as undesired as one may think. It may give the illusion of detail and improve perceived color depth by dithering, or its abundance may simply appear more attractive to the general public. Much of 300's grain was added after filming.

yes but they added dancing grain and that is what really bugs me.

an example. The Spartan queen is very beautiful and in one close up shot of her face there was so much dancing grain her cute little birth mark could not be seen cause the dancing pixels were all over it to the point it to looked like grain. Same thing with her eye lashes. Total blasted out because of the dancing grain which makes it hard to see any detail that happens to be about the size of the grain. very distracting to me :(

Sagekilla

16th December 2007, 21:40

yes but they added dancing grain and that is what really bugs me.

an example. The Spartan queen is very beautiful and in one close up shot of her face there was so much dancing grain her cute little birth mark could not be seen cause the dancing pixels were all over it to the point it to looked like grain. Same thing with her eye lashes. Total blasted out because of the dancing grain which makes it hard to see any detail that happens to be about the size of the grain. very distracting to me :(

Indeed, I'm willing to settle with the level of grain present in 300 if it was not dancing grain. But, thanks to Didee I'll be using this script to see how well it degrains other noisy material and if it does work just as well, grain may very well disappear from my x264 encodes.

Terranigma

16th December 2007, 21:41

yes but they added dancing grain and that is what really bugs me.

I've noticed this dancing grain in newer dvd's as well. Looks like the only thing that can be done about it is to encode as mpeg-2, since it tends to hold grain easily, and banding? Not a problem with mpeg-2. :P

Sagekilla

16th December 2007, 21:43

I've noticed this dancing grain in newer dvd's as well. Looks like the only thing that can be done about it is to encode as mpeg-2, since it tends to hold grain easily, and banding? Not a problem with mpeg-2. :P

I've noticed that as well. MPEG-2 seems to handle video very well at a decent bitrate, whereas x264 you need to play around with the settings a bit to get it to work nicely, even with high bitrates. Kind of feels like we've gone two steps forward in terms of compression and a few more backwards in terms of grain retention/banding/other artifacts

Zep

16th December 2007, 21:47

Zep

16th December 2007, 21:51

Note#2: The script uses MVDegrain3. If you don't have MVTools v1.9.0, you can either use MVDegrain2 instead (with slightly worse results), or make a donation to Fizick (recommended!) to get the goodies more early. :)

I will give your script a go and yes though dancing grains is my main concern I do prefer at least 50% reduction in grain straight up. I truly feel they added too much heavy grain to this movie.

MVDegrain3?????? No fair!!!! access to tools we (I) do not have hahahahaha :D

Sagekilla

16th December 2007, 21:54

Personally, I think your spatial degrain looks a lot smoother and has an airbrushed look, Zep. Didee's looks like it retains more of the fine nuances in skin detail.

Zep

16th December 2007, 22:04

Very nicely done Didee.. Your script looks like it retains much more detail than Zep's does, with that said I have to hand it to both of you.. Both are an amazing improvement over the original, well done :)

I'd really love to see the filter chain you used to degrain the movie like that Didee! Also, it seems like the reason why yours was a slightly higher bitrate could because of the more detail yours retains. I noticed in the close up of faces yours had more skin detail than Zep's.

yeah I like them both a lot. I do want to pump up the selective sat more in Didee's and add in a some more selective masking to try and better hit only the areas that annoy ME but seem to be fine for Didee.

oh and hey slight advantage to didee for getting to work
FROM my better than original but I admitted could be improved starting point :) Now that I have his scripts I think I can do even better than either of ours by merging some of mine with his. Then didee will get to a new starting point to work from hahahaha

at this rate we may make it better looking than the I-MAX release :D

Zep

16th December 2007, 22:11

Perhaps because zep's was oversharpened? Sure, it may look great while playing, but when zoomed, you can see the detail that was destroyed. It's never good to oversharpen; there's a detail analysis out there that talks about edge-enhancement; maybe you could find it. :)

maybe. I used Didee SEESAW and it was the very first time I ever use it. I went with settings that pokie posted in a thread than brought out /sharpened and episode of "Lost"

I never tweaked it because I do not know enough about SEESAW
to know what does what. The problem I am still having is getting the perfect masks. some scene I get a perfect one then other it is way off (even more so in a fast cut scene change the first frame or 2 the masks suck) :(

Zep

16th December 2007, 22:26

Mmm, yes it is quite a bit faster than an HD source, a blazing 0.87 fps! Only settings not maxed are refs (6) and ME (umh)

But, back on topic though, was your script (generally speaking) about the same methodology that Didee was using for degraining?

some yes some no. His is more temporal, mine more spatial.

the thing that I MUST make clear is that Didee's and my goals on the final are not the same. I want all dancing grain removed
and more non dancing grain removed.

Didee is ok with leaving a good amount of grain in and looking for more of a balance to save detail and maybe give it a more natural look etc...

Me am leaning more towards more grain removal at the expense of slight detail loss because for me it is all about MOTION. His frame to frame compares to mine will always be better. heck I like them better also. But when watching the clips I lean towards my latest test clips I did today. Granted I now am using Didee's script tweak added with my own.

MY WHOLE POINT of that RANT?

this stuff is very subjective! I thought I was ok with a fair amount of grain left in as long as it was not dancing grain but it appears I hate any grain more than I thought :D

Zep

16th December 2007, 22:29

I've noticed this dancing grain in newer dvd's as well. Looks like the only thing that can be done about it is to encode as mpeg-2, since it tends to hold grain easily, and banding? Not a problem with mpeg-2. :P

yes! and I want to know WHY? damn it they should leave it clear and crisp. If we want grain it is much easier to ADD then to remove. :P

Terranigma

16th December 2007, 22:32

yes! and I want to know WHY?
To annoy consumers :angry:

Zep

16th December 2007, 22:36

Zep!

Didee!

clean out your PM box I can't send my reply to you because your PM space is all used up :D

let me know in PM when I can try to send my reply again. yes I answered your questions and yes you will find it interesting
(your first sentence was correct on so many levels haha)

thanks,

Zep

Zep

16th December 2007, 22:38

To annoy consumers :angry:

LOL yeah :P

seriously though I wonder why they added so much to 300. Grain is one thing but all that *dancing* grain is another and really does take away from the enjoyment (For me anyway) of the movie.

Zep

16th December 2007, 22:54

Hope this is sufficient to make my point: removing grain is okay if it annoys, but I'd want my result to keep the "natural" look. Sharp soup I like to eat, but not to watch.

So you are saying pookie's settings to your SEESAW added too much sharpening to my final huh :D

yes I used SEESAW :P and it was the very first time ever I used it and since I had no idea what settings to use I used one pookie posted somewhere showing sharpening to an episode of "Lost". yeah now that I think about it I should have turned it down some as I see looking at the pookie post he really brought out the detail/sharpen a lot in his example still frame compare. I probably should have cut the sharpening in SEESAW by about half and went more temporal for the grain removal/dancing. I do like the added rich colors I did though. I think the original was a little bland also. I feel now that with your script and mine and the tweaks I did today it is really rocking.

only down side the final encode is gonna take a week :(

Zep

16th December 2007, 23:14

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.)

basically correct. I on purpose went overkill on fft3dfilter with sigma 8 on luma only to get rid of more than just dancing grain but as much grain as I could without totally destroying the detail. Some mush came from this and why I had to add masking and then later I decided to add SEESAW but now that I look back at the final encode I feel the settings were too strong on BOTH fft3dfilter and seesaw. If I went sigma 6 then I could have lowered the SEESAW strength a lot and got more balanced encode I guess.

Still I do like mine a lot than the original and up until just 2 weeks ago I never ever did grain removal before. This was my very first foray into this area.

I have learned much in this thread over the last 2 weeks and now with your script and some of mine added and tweaked I think my next final encode it gonna just be mega awesome! ( for my tastes anyway haha)

(you may still think I blasted out too much grain)

Zep

17th December 2007, 00:40

@ Didee,

I like very much your final test. (I just watched it) Even though it leaves a little grain it is more than ok even for me because the detail is more even across the whole clip :D (I clearly overdid removal which then forced me to over sharpen)

Now the hard part for you. That scene is on the LOW END of the grain dancing and brutal grain scale. I picked that scene because it is a favorite scene of mine and also why I left the audio in when I made the clips :D

I ran your script and it is now having a harder time on the night scenes and the scenes where the grain is really really bad. My original final made them great and better than the clips I uploaded. My guess is than some of the cons were hidden (like ringing or halo) because they are dark night scenes and the eye can't spot them so easy. The grain looks even worse then because dark night sky with WHITE grain dancing stands out even more etc...

So now it has me wondering if you would be able to add some way to determine darker scenes and/or more grain so that your script will adjust the strengths during those scenes.

I can UL some clips for you to test on if you think it is possible and worth adding to your script.

PM me so we can talk more :)

Huge thanks!

Zep

Terranigma

17th December 2007, 00:52

I ran your script and it is now having a harder time on the night scenes and the scenes where the grain is really really bad.

Hmm, I thought that was just me. :cool:

After looking at the script, I don't think it's designed for dark noise filtering, but I could be wrong.

Zep

17th December 2007, 01:12

Hmm, I thought that was just me. :cool:

After looking at the script, I don't think it's designed for dark noise filtering, but I could be wrong.

Well to be fair Didee only had a very bright day scene to work with and he did an amazing job with it. I like it better than mine on grain and detail but I like mine better in night scenes and mega grain scenes.

if he could add a way to detect and change strengths based on darkness and grain amount. I would not even bother with my script anymore and I would only add some color masking to the chain so I could pick and choose sat boost / color corrections because I feel the original color wise is bland and washed out some.

Zep

17th December 2007, 01:24

Personally, I think your spatial degrain looks a lot smoother and has an airbrushed look, Zep. Didee's looks like it retains more of the fine nuances in skin detail.

wow I replied to so many posts I think I missed this one? lol

Thank you for that comment you gave me a warm fuzzy :)

Anyway, that is an interesting observation and now that you mention it yeah I guess it does. That may be a good thing if you feel the movie should look more like frank miller's graphic novel and have a more surrealistic look. Hmmm...

Didée

17th December 2007, 01:34

Sagekilla

19th December 2007, 03:57

Hmm, the script you came up with could probably stand to benefit from multithreading, correct Didee? I just noticed in VirtualDubMod that running the avisynth script to do pre-processing on my video, task manager shows only 50% usage on my dual core with only the script running.

Zep

19th December 2007, 04:36

It would not surprise me if that script acts "too weak" in scenes where the grain is much stronger.
Regarding low-light night scenes - is it so that the script doesn't remove enough grain there, or is it so that it does too much damage in dark scenes?
Some samples definetly would help to judge.

a little of both.

I will cut a night scene and one that has a lot of grain and and give you a link As Soon As Possible. (I'll go do it now and edit this post when done)

ok here are the clips (http://www.megaupload.com/?d=A6D5XYCY)

Thanks

Zep

Didée

19th December 2007, 23:19

Zep

20th December 2007, 02:35

Got the samples, thank you. But now, where are the big problems? I tried the posted script on both samples, and for the most parts everything seems reasonable. Can't find any too-little grain removal in the mega-grain sample, and no serious harm done in the night-scene sample.
There are, however, some problems in those scenes with hectic motion where MVTools don't manage to predict correctly. (Whether this is noticeable during final playback is another question - even the source shows some defects in those areas.)
It is possible to compensate this with a tiny change to the script: in the *first* MVDegrain, raise thSAD to 600 or even 900. This will force the alternative filter (named "spat") to be used in those spots - and if you don't like the given alternative filter (FFT3D), use another one.
Or am I looking for the wrong things somehow?

I only said it was having a harder time. :) The settings would not need to be massively changed as noted in my earlier post. I was hoping more for just tweak per grain and scene dection if even possible or worth the hassle.

Anyway, maybe MVDegrain3 is better than MVDegrain2? Are you on a LCD or CRT? A good LCD shows flaws much better. A CRT is soft, not sharp at all and hides a lot of stuff like macro block edges and light grain.

and of course maybe I am just more sensitive to grain. :)

Thanks,

Zep

Didée

20th December 2007, 03:12

Definetly CRT here. I'll try to avoid LCD until SED comes around (though not sure if I manage to bear up that pledge...)

MVDegrain2 uses 4 frames to denoise the current frame. MVDegrain3 uses 6 frames. 6/4 = 1.5 means that MVDegrain3 is potentially 50% more effective in denoising than MVDegrain2. Upper bound, that is.
So yes, on the strong-grain sequences you'll definetly see more residual flicker when only MVDegrain2 is used.

I tried to re-build MVDegrainX with a script function, mainly because I wanted to plug one or two features into it which MVDegrain does not provide at all. Theoretically, it should be no problem to make it with MVMask+TTempsmooth ... but somehow I don't get similar enough. It's quite similar, but there's something about the weight reduction that just won't line up. Either the script is somewhat less sensitive to errors, or it is more ... but never exactly the same.

Here's the outline of the function: (attention, not all features of MVDegrain are implemented yet)

edit: corrected for proof-of-concept usability.
function Scripted_MVDegrain3(clip c, clip "mvbw", clip "mvfw", clip "mvbw2", clip "mvfw2", clip "mvbw3", clip "mvfw3",
\ int "thSAD", int "plane", int "limit", clip "pelclip", int "idx")
{
thSAD = default(thSAD, 400)
plane = default(plane, 4)
limit = default(limit, 255)
_idx = default(idx, -11)

thSAD = thSAD / 8

# alt = c.FFT3DFilter(sigma=10,sigma2=6,sigma3=4,sigma4=2,bw=16,bh=16,ow=8,oh=8,bt=1)

SAD_fw3 = c.MVMask(mvfw3, kind=1, ml=thSAD, gamma=0.999, Ysc=255)
SAD_fw2 = c.MVMask(mvfw2, kind=1, ml=thSAD, gamma=0.999, Ysc=255)
SAD_fw1 = c.MVMask(mvfw, kind=1, ml=thSAD, gamma=0.999, Ysc=255)
SAD_bw1 = c.MVMask(mvbw, kind=1, ml=thSAD, gamma=0.999, Ysc=255)
SAD_bw2 = c.MVMask(mvbw2, kind=1, ml=thSAD, gamma=0.999, Ysc=255)
SAD_bw3 = c.MVMask(mvbw3, kind=1, ml=thSAD, gamma=0.999, Ysc=255)

comp_fw3 = c.MVCompensate(mvfw3, idx=_idx) # .mt_merge(alt,SAD_fw3,U=3,V=3)
comp_fw2 = c.MVCompensate(mvfw2, idx=_idx) # .mt_merge(alt,SAD_fw2,U=3,V=3)
comp_fw1 = c.MVCompensate(mvfw, idx=_idx) # .mt_merge(alt,SAD_fw1,U=3,V=3)
comp_bw1 = c.MVCompensate(mvbw, idx=_idx) # .mt_merge(alt,SAD_bw1,U=3,V=3)
comp_bw2 = c.MVCompensate(mvbw2, idx=_idx) # .mt_merge(alt,SAD_bw2,U=3,V=3)
comp_bw3 = c.MVCompensate(mvbw3, idx=_idx) # .mt_merge(alt,SAD_bw3,U=3,V=3)

black = blankclip(c,color_yuv=$008080)
long = interleave( comp_fw3,comp_fw2,comp_fw1, c, comp_bw1,comp_bw2,comp_bw3 )
long_SAD = interleave( SAD_fw3, SAD_fw2, SAD_fw1, black, SAD_bw1, SAD_bw2, SAD_bw3 )

long.TTempSmooth(3,255,255,1,1,strength=4,pfclip=long_SAD,fp=false,scthresh=99.9)
# long.temporalsoften(3,255,255,24,2) # instead of TTempSmooth - if and only IF alt-clip is used
SelectEvery(7,3)
}

Someone tell me where the error is? Under Suspect are the thSAD divider ... the doc about MVMask says something about "internal normalisation factor of 'blocksize*blocksize/4' " , but using that, the end result won't fit at all ...

Didée

20th December 2007, 05:09

Sudden enlightment! It's "scthresh" in TTempSmooth, which is relative to pfclip if same is used. And the default of 12% is of course way too low when pfclip contains a mask that is scaled to [0,255] ...

Updated the above replacement function. It's now fairly similar to MVDegrain3. Not identical (rounding differences due to overlapping, etc.), quite a bit slower, and only valid for 8x8 blocks.
It should be sufficient to use "Scripted_MVDegrain3()" as a replacement for "MVDegrain3()" in the formerly posted degraining script.

Boulder

20th December 2007, 05:13

Didée, do you recommend doing very heavy pre-denoising (for the MVAnalyse parts) in all cases, or just in those cases where the video is ultra-grainy?

Didée

20th December 2007, 05:51

There's no fixed rule for that. It depends on how strong the grain is, on the blocksize you're using in MVAnalyse, on whether you want to completely erase the grain or if you just want to reduce it alittle, ...
The pre-denoising deals mostly for getting a more stable vector field in more-or-less static areas. (I find it pretty disappointing when you're using such a sophisticated method like active motion compensation, but end up with "swimming" because your sophisticated method got confused in those parts which should be the most easy ones: the static parts).
But it's also about error reckognition by thSAD or whatever else ... with pre-denoising the chances are IMO better to reckognize ME errors without getting confused by the grain variances.
Therefore, same as usual: as much as needed, as little as possible. With strong grain, stronger preprocessing is really benefitial. With less strong grain preprocessing becomes less important ... up to the point of zero-strength grain, where all grain filtering becomes useless anyway. :)

Sagekilla

20th December 2007, 06:44

For anyone who's interested, I got a decent speed boost adding SetMTMode(2,2) at the beginning of the script. It seems to run fine with the whole filter chain and I got a 5 minute pre-process down to about 3 minutes. I don't know if it's actually working perfectly w/o any issues or not, but I find it a bit amazing that it's seemingly working perfect on my first try with MT.

Edit: By the way Didee, I'm in absolute love with this clip when it comes to using it on some video clips I take with my camera. It cleans up the noise very well while retaining 99% of the detail :)

Boulder

20th December 2007, 07:30

Therefore, same as usual: as much as needed, as little as possible. With strong grain, stronger preprocessing is really benefitial. With less strong grain preprocessing becomes less important ... up to the point of zero-strength grain, where all grain filtering becomes useless anyway. :)Thanks, that is what I actually figured myself as well. Recently I've been battling mostly with DVB sources so there's not much grain but noise (=swimming blocks) from the inefficient MPEG2 compression. I've been using FFT3DFilter for pre-denoising with some success, but probably need to come up with a better solution:devil: Interlaced sources at an average bitrate of 2500kbps are a really beautiful thing..

Terranigma

20th December 2007, 15:37

Didée, is it possible to use pre-filtering only for analysis purposes, then restore whatever detail it washes out?
Like, first, removing all grain to see the clip's real motion, then call mvanalyse to do the analysis, and lastly, restore/reverse completely the effect of the prefilter? Sort of like how you did for your 300 sample, but without the pre-filtering actually doing any denoising.

Didée

20th December 2007, 16:12

Of course it's possible ... that's old stuff, didn't we cover that already time ago? ;)

To do analysis on a preprocessed clip, without the preprocessing interfering with the end result, you've to use different idx'es, like in:
pre = source.YourSuitedPrefilter()
vbw = pre.MVanalyse(isb=true, idx= N )
vfw = pre.MVanalyse(isb=false, idx= N )

source.MVDegrain(vbw,vfw, idx= N+1 )
So, no need to "restore" anything that the prefilter took away. When the idx values are different, then the processed clip "pre" plays no role at all in the denoising stage. Only the ME vectors that were achieved from it.

Terranigma

20th December 2007, 16:45

Yes we have. My mistake came from using the "pre-ed" clip in my denoiser instead like so:
pre = source.YourSuitedPrefilter()
vbw = pre.MVanalyse(isb=true, idx= N )
vfw = pre.MVanalyse(isb=false, idx= N )

pre.MVDegrain(vbw,vfw, idx= N+1 )
:o

Sagekilla

21st December 2007, 22:24

Well, I got bored today so I decided to make a simple function out of Didee's script. I particularly like how well it degrains and denoises all my video I throw at it (300, video captured from my digital camera, any random noisy or grainy video I happen to have) so I figured it would be easier to do a simple call then copy and paste it every time.

Here's the function, I'll be adding in Didee's scripted MVDegrain3 later on and the option to specify your own denoised clip so you can use something else to do pre-filtering. Also, I recommend throwing in SetMTMode(2,2) in too if you have multiple CPUs so it isn't terribly slow. Also, please give any feedback you have on it! Much thanks to Didee for creating the script in the first place :)

Click here for the latest version (http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs)

Sagekilla

21st December 2007, 22:30

Come to think of it, can anyone point out how exactly I can make avisynth switch between two different options in a script? Like.. I give the user option of MVDegrain = "2" or "3" and I want it to switch between either one depending on what option they define, or else it defaults to "2."

Searching through avisynth wiki but I can't find out how to do this.

Ignore what I just said, I figured it out.

Terranigma

21st December 2007, 22:39

Sagekilla

21st December 2007, 22:55

Essentially, wouldn't mvdegrain3 be the exact same thing as mvdegrain2 + mvdegrain1, whereas the call to mvdegrain1 uses delta 3 and the same idx value?
Like
source2=source.mvdegrain2(delta1,delta2,delta1,delta2,idx=2)
source2.mvdegrain1(delta3,delta3,idx=2)
;)

That would be filtering it twice in a row though: first with sequence 60, 61, 63, 64 and then filtering it once more with 59, 65. I think what MVDegrain3 would be doing is doing a single filtering pass using the information from frames 59, 60, 61, 63, 64, 65 for frame 62, not a "denoise some, then denoise some more"

Edit: Added in functionality to define your own denoised clip and Didee's faux MVDegrain3.

Terranigma

21st December 2007, 23:15

That would be filtering it twice in a row though: first with sequence 60, 61, 63, 64 and then filtering it once more with 59, 65. I think what MVDegrain3 would be doing is doing a single filtering pass using the information from frames 59, 60, 61, 63, 64, 65 for frame 62, not a "denoise some, then .

No, I don't think so. source2 uses the information from the first part of mvdegrain2, and then uses the higher deltas for more noise removal, and idx2 will make sure it process the same clip. Let me do a quick test using subtract of 2 mvdegrain1 vs. mvdegrain2 and report back. :)

Terranigma

21st December 2007, 23:25

Sagekilla

21st December 2007, 23:32

I was right to a certain extent, but there's some differences. :p

MVDegrain2:
http://img218.imageshack.us/img218/9749/mvd2io8.png

2x MVDegrain1:
http://img218.imageshack.us/img218/7426/2mvd1cl2.png

So it seems my way actually removes a bit more noise, so you'll end up with mvdegrain3+ :p

Think we're both right and wrong to some extent, since MVDegrain3 does use 6 frames to denoise, but how it does it I have no idea. So I guess that would make your method some sort of.. MVDegrain3.5 huh? :)

I'm going to do some testing for myself and see which method I like better: Didee's or yours. Then I'm gonna run back and implement the one I like better.

Terranigma

21st December 2007, 23:38

Think we're both right and wrong to some extent, since MVDegrain3 does use 6 frames to denoise, but how it does it I have no idea. So I guess that would make your method some sort of.. MVDegrain3.5 huh? :)

I'm going to do some testing for myself and see which method I like better: Didee's or yours. Then I'm gonna run back and implement the one I like better.

Well, I don't use Didee's script, nor the script you posted. I was using another script with 2 mvdegrain calls.

Anyways, here's a screenshot comparison of the normal script with mvd2 vs. this mvdegrain.

mvd2:
http://img297.imageshack.us/img297/8881/mvd2og5.png

mvd3ish:
http://img147.imageshack.us/img147/4870/mvd3tn5.png

Sagekilla

21st December 2007, 23:40

Well, I don't use Didee's script, nor the script you posted. I was using another script with 2 mvdegrain calls.

Anyways, here's a screenshot comparison of the normal script with mvd2 vs. this mvdegrain.

mvd2:
http://img297.imageshack.us/img297/8881/mvd2og5.png

mvd3ish:
http://img147.imageshack.us/img147/4870/mvd3tn5.png

Hmm, neat. I might end up just using yours since it looks like this one does a much better job then the faux MVD3 by Didee. I did a quick visual comparison and there was little improvement through his method in my testing.

Didée

21st December 2007, 23:41

@ Terranigma: Basically correct, but not quite like you posted it. In ^^that way, the weightings of the "wing" frames are screwed: Too much weights go to the frames [current-3] and [current+3].

You need to do

degrain_2 = source.mvdegrain2(delta1,delta2,delta1,delta2,idx=2)
degrain_2_1 = source2.mvdegrain1(delta3,delta3,idx=2)

degrain_3 = degrain_2 .merge( degrain_2_1 , 0.4286)

to get the correct weightings.

So it seems my way actually removes a bit more noise, so you'll end up with mvdegrain3
Without corrected weightings, it will denoise less, not more. (Unless you split the idx'es, then it will denoise more indeed.)

@ Sagekilla: That way is not some funky "denoise some, then denoise some more". It's quite possible to do so.
MVDegrain3 melts 7 frames together at one.
Since Terranigma used the *same* idx values (which in this case is correct), what happens is that the 2nd MVDegrain uses the 1st MVDegrain'ed clip as base, but will average with the not-yet processed wingframes. I.e. first there are 5 frames melted together. Then, in the 2nd step, the missing two frames are additionally melted into the first melting.
When done with the correct weighting, then the result is the same, except for rounding differences.

---

ColorYUV-analyzing a diff, I see min/max 126/130, loose min/max 127/129. That's rounding differences, yep.

Terranigma

22nd December 2007, 00:00

Didée

22nd December 2007, 00:33

Terranigma

22nd December 2007, 00:39

@Terranigma: Yeah, whatever you're doing there. BTW did you use the correct weightings to simulate MVDegrain2 by 2xMVDegrain1...? :p

Yes :)

However ... the reason to make a step-by-step rebuild of MVDegrain3 was more towards adding some features in that MVDegrainX does not have at all. (When going to make suggestions to a dev, ears are wider open when you can show a working solution instead of just boring with theoretical blabla.)

Par ex: Seamless integration of using an alternative filter (resp. an alternatively filtered clip), weighted by thSAD:

http://img151.imageshack.us/img151/4931/mvdegrainmu4.th.png (http://img151.imageshack.us/my.php?image=mvdegrainmu4.png)

Note the motion regions where MVDegrain3 folds its arms & says "no, here I do nothing".
(That's more interesting than discussing how to simulate MVDgr7 with MVDgr1.)
Ahh, so that's what that is: I noticed this the other day With 1 call of mvdegrain, whereas adding a second call totally eliminated it; and I thought that was just because I was using mvdegrain4 (though improperly).. but otoh, raising the thsad did absolutely nothing for the 1 call.

Didée

22nd December 2007, 00:58

I noticed this the other day With 1 call of mvdegrain, whereas adding a second call totally eliminated it;
Nope. Those not-processed areas are because block SAD is too high there (bad compensation because ME did not find a good match.)
It doesn't matter how often you call MVDegrain over and over. Not-compensateable areas keep being not-compensateable, block SAD keeps being high, the not-filtered areas keep being not filtered.

If you have scripts that in practice make happen what in theory should not happen, that's fine. But without posting them, nobody can follow.

Terranigma

22nd December 2007, 01:13

If you have scripts that in practice make happen what in theory should not happen, that's fine. But without posting them, nobody can follow.

Well, wouldn't combining mvmask with the analysis solve the error? By the way, since you mentioned non-compensateable, one could surely fix this by using truemotion=false right? I'm doing a frame-by-frame step through as of now to see where the problem lied. I changed some parameters in mvmask, so surely it's going to have some effect on the analysis. Maybe I should revert to what the mask was originally, then try the new mask.

I'll report back with updated info. :)

Didée

22nd December 2007, 01:32

Terranigma

22nd December 2007, 01:57

Sure, there's lots of tweaking possible with MVAnalyse's settings.
Regarding "not-compensateable": elimination of that problem is of course not possible. Possible is a very noticeable improvement on the problem, by using different settings than the default ones ... truemotion=false makes a difference. searchparam=8 makes a difference. Both together make a big difference.
However: Though a good part of those differences are good ones (better compensation of problematic motion areas), some of those differences are bad ones (losing motion coherence, getting either "swimming" [or just "less pleasing"] denoising in flat areas like sky, fog, etc.)

As always, there is no 'best'. Only different pro's and con's.
Did I ever mention the "you win here, you lose there" proverb ... ;)

That proverb seems to hold true. I thought a certain clip of mines was a lost cause. I usually use search 3, which in turns, also seems to lock the searchparam at 255 (max) :rolleyes:, but there have been downsides as you said: Swimming in once grainy, flat areas (doesn't matter if it's prefiltered and denoised completely), and weak denoising for flat skies (Though I pinned down what was causing the weak denoising for the sky, but never for the swimming.) so search 2 should be just fine for most clips it seems.

Anyways, would it be possible for you to upload a sample of that clip so that I can test this script with mvdegrain with it? After stepping through frame-by-frame, all images seems to be fine all of a sudden (maybe because I can't seem to recall the previous settings i've used completely. :p)

Didée

22nd December 2007, 03:03

The samples were uploaded by Zep - see this post (http://forum.doom9.org/showthread.php?p=1072657#post1072657) and this post (http://forum.doom9.org/showthread.php?p=1074907#post1074907).

I usually use search 3 [...] but there have been downsides as you said: Swimming in once grainy, flat areas (doesn't matter if it's prefiltered and denoised completely)
Inspired by one of Dark Shikari's early posts in this thread (though only after recovering from the sickness when seeing RemoveGrain(19)^2 being used), I tried the almost-forgotten HQDN3D and found it to be a pretty effective way to eliminate remaining flicker from flat areas for the search clip. It's a really tricky thing - in those areas that are [supposed to be] *very* flat, even the most minor flicker will invite the motion engine to follow it. E.g., the "bands" that are often produced by fft3dfilter usually are hopping-around a bit. Although they're mostly only +/-1 pixel value , it's enough to attract motion vectors ...

[...] so search 2 should be just fine for most clips it seems.
Probably, yes.

P.S.: Added some comments to the script posted in #107. ;-)

Terranigma

22nd December 2007, 04:32

instead of posting new updated posts, how about just editing your posts with the new code, oh and use size=1? :)

Zep

23rd December 2007, 06:14

@Terranigma: Yeah, whatever you're doing there. BTW did you use the correct weightings to simulate MVDegrain2 by 2xMVDegrain1...? :p

However ... the reason to make a step-by-step rebuild of MVDegrain3 was more towards adding some features in that MVDegrainX does not have at all. (When going to make suggestions to a dev, ears are wider open when you can show a working solution instead of just boring with theoretical blabla.)

Par ex: Seamless integration of using an alternative filter (resp. an alternatively filtered clip), weighted by thSAD:

http://img151.imageshack.us/img151/4931/mvdegrainmu4.th.png (http://img151.imageshack.us/my.php?image=mvdegrainmu4.png)

Note the motion regions where MVDegrain3 folds its arms & says "no, here I do nothing".
(That's more interesting than discussing how to simulate MVDgr7 with MVDgr1.)

ok you have got to be kidding me lol I just spent 4 days encoding pass1 and it JUST finished and I went in and looked at that very frame you posted above and sure enough it is showing even worse that what you posted. My guess MVDegrain2 not as good as MVDegrain3 again lol Thank goodness I stopped the 2nd pass because I see other flaws in your posted pic as well as my scans now. In this regard it is worse than my first encode but I didn't notice it because I was too focused on grain! grrr..... :D

Ok I now have to decide what to do. I do have the pass 1 stats file which should be plenty good no matter how I do pass 2. I think I will try your scripted_MVdegrain3 and run pass2 with it.

I also smacked my head about 2 days into the encode when I realized it was taking so long that what I should have done was use tritical's Twrite() and saved a lossless file so that I could run pass2 from it and not have to redo all the grain removable calcs for pass2. Normally Twrite() (well the encoder and massive HD I/O anyway) is too slow to use for me but when I am doing something like this and just getting 1.1 FPS a second it is more than fast enough and 60 gig lossless VBLE file is no problem for this project :P

now I will go and see just how slow the scripted version is lol
if it is like under 1 FPS oh my this may take a week to encode :scared: (UPDATE .3 FPS lol will take 9 days to encode lol)

BTW - what is pelclip for? (or what will it be used for in the future)

thanks

Zep

Zep

23rd December 2007, 06:48

ankurs

23rd December 2007, 13:06

http://i15.tinypic.com/6jb8ism.jpg

this is what i got when i tried to use Temporal Degrain V1.07 with all the required plugins(latest versions) in the script ( lots of them .. wish they could be autoloaded :p )

well thing is this is what i have at line 7 of my script

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\HQdn3D.dll")

never used this filter ever before .. just saw that it was required by the script and downloaded it of the link which was given in the script itself by Sagekilla .. think there is some incompatibility with it of the filters which i am calling in the script ( P.S : Used to have the same problem until placed the ffw3.dll file in system 32 folder and then it started wrking ) no idea if even this requires a file of such sorts to be placed in that folder ? if so then please help me out :)

ankurs

23rd December 2007, 13:57

also getting this even though all the required plugins are there ,,

http://i1.tinypic.com/727lq2d.jpg

this is the filter loading part of my script

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\ColorMatrix.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\fft3dfilter.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MT.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MVtools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrain.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Repair.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\HQdn3D.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MaskTools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\warpsharp.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\asharp.dll")
Import("C:\Program Files\AviSynth 2.5\plugins\LimitedSharpenFaster.avsi")
Import("C:\Program Files\AviSynth 2.5\plugins\ylevelsS.avs")
Import("C:\Program Files\AviSynth 2.5\plugins\soothe.avs")
Import("C:\Program Files\AviSynth 2.5\plugins\Temporal Degrain.avs")

??

ankurs

23rd December 2007, 13:59

the first instance is when HQdn3D.dll was not there in the plugins directory :shy: my mistake :p but after putting it there i am getting the second error which is posted above this post ..

Didée

23rd December 2007, 14:11

MinBlur() is a well-hidden little function. Find it e.g. in the script posted in #61 of this thread.

ankurs

23rd December 2007, 14:15

ohk i just figured out one thing .. the first error was caused by HQdn3D.dll not being there in the plugins folder .. when i put it there i got a second error in vdub which is given in the above post :p .. help me plz :) ?

ankurs

23rd December 2007, 14:21

MinBlur() is a hideous little function. Find it e.g. in the script posted in #61 of this thread.

thanks a LOT didee .. its working now :D loving the results of this woohoo :p

ohk i just figured out one thing .. the first error was caused by HQdn3D.dll not being there in the plugins folder .. when i put it there i got a second error in vdub which is given in the above post :p .. help me plz :) ?

sorry double post .. staff plz delete it :rolleyes:

Terranigma

23rd December 2007, 15:02

sorry double post .. staff plz delete it :rolleyes:

You can delete it yourself, no? When you choose to edit.

Sagekilla

23rd December 2007, 21:54

jokin

27th December 2007, 14:23

@Sagekilla

I get the following error with your script.

Script Error: syntax error
(C:\Program Files\AviSynth 2.5\plugins\temporaldegrain.avs, line 80, column 0)

I have repasted the script several times and it still gets the error. Any Ideas? I have all the plugins loaded.

Thank You

EDIT: I seemed to have found my problem. I needed some text after the ":" in the NR1 and NR2 lines.

ankurs

27th December 2007, 19:24

Hm now that's really odd. I just noticed I have mcbob, and I don't have the minblur defined anywhere in my function! That's probably why it was working fine for me for so long.. I have to go do some testing to see what's going on.

I fixed that little issue, thanks for helping point that out ankurs + Didee!

The updated build that should work without mcbob.avs, it's at #116 (http://forum.doom9.org/showpost.php?p=1078534&postcount=116) in this thread.

thanks for the update ! i suppose u meant that now we dont need to load minblur() to get this working ? because i think it was originally a part of the mcbob script which didee helped me out to on a previous page .. but now i am facing the same error as jokin :/

P.S : I also suppose that removing its need means making the script faster :p

@Sagekilla

I get the following error with your script.

Script Error: syntax error
(C:\Program Files\AviSynth 2.5\plugins\temporaldegrain.avs, line 80, column 0)

I have repasted the script several times and it still gets the error. Any Ideas? I have all the plugins loaded.

Thank You

EDIT: I seemed to have found my problem. I needed some text after the ":" in the NR1 and NR2 lines.

hmm well right now i am getting the same error too .. and cant seem to figure out which text is needed and also after which lines :confused: please help me out if you can jokin and sagekilla :rolleyes:

ankurs

27th December 2007, 19:35

well i did try what jokin said but got another error :(

http://i5.tinypic.com/6sbs5qc.jpg

P.S : If u can jokin then please put in the working script which you have here in a codebox :p

Didée

27th December 2007, 20:00

The script currently posted in post#116 is bugged by three incorrect linebreaks.
(And no, you don't need just "some text" after those : characters. You need some certain text after them - precisely the text that appears two lines later ...)

Until Sagekilla comes around for cleaning, here's the corrected script:

#############################################################################
# Temporal Degrain V1.08 (Dec 23, 2007) #
# Function by Sagekilla, original script created by Didee #
# #
# Works as a simple temporal degraining function that'll remove MOST grain #
# from video sources, including dancing grain, like the grain found on 300. #
# Features an optional MVDegrain3, which you need TTempSmooth for. #
# #
# Required plugins: FFT3DFilter / MT.dll / mt_masktools / MVtools.dll #
# HQdn3D.dll / RemoveGrain.dll / Repair.dll #
# #
# FFT3DFilter: http://bag.hotmail.ru/fft3dfilter/fft3dfilter.dhtml #
# MT: http://avisynth.org/tsp/ #
# mt_masktools: http://manao4.free.fr/mt_masktools.html #
# MVtools: http://avisynth.org.ru/mvtools/mvtools.html #
# RemoveGrain: http://www.removegrain.de.tf/ #
# Repair: See above #
# HQdn3D: http://akuvian.org/src/avisynth/hqdn3d/ #
#############################################################################

########################################################
# Description of functions #
# denoise = Denoised clip for detecting motion vectors #
# sigma = FFT3D filtering strength #
# bw = FFT3D block width #
# bh = FFT3D block height #
# pel = MVAnalyse Subpixel accuracy #
# ov = MVAnalyse block overlap #
# SAD1 = thSAD for MVDegrain #
# SAD2 = thSAD for MVDegrain #
# degrain = MVDegrain with 2 or 3 vectors #
# HQ = Enables HQdn3D prepass for motion vectors #
########################################################

function TemporalDegrain ( clip input, clip "denoise", int "sigma", int "bw", int "bh",
\ int "pel", int "ov", int "degrain", int "SAD1", int "SAD2", bool "HQ" )
{
o = input
sigma = default( sigma, 16 ) # Increase to (slightly) improve motion vectors
bw = default( bw, 16 ) # FFT3D block width
bh = default( bh, 16 ) # FFT3D block height
pel = default( pel, 2 ) # (1, 2, 4) Increase to 4 for more quality, slower speed
ov = default( ov, 4 ) # Increase for better motion vectors but slower speed
degrain = default( Degrain, 2 ) # MVDegrain 2 or 3. 3 is slower and (slightly) higher quality
SAD1 = default( SAD1, 300 ) # Threshold for degraining, decrease for more effect
SAD2 = default( SAD2, 300 ) # See above
HQ = default( HQ, false ) # Clean up motion vector search some more
s2 = sigma - 6 # See sigma
s3 = sigma - 10 # See sigma
s4 = sigma - 12 # See sigma
ow = bw / 2 # Don't adjust unless you need speed
oh = bh / 2 # See above

# "srch" is a prefiltered clip on which the motion serach is done.
# Here, we simply use FFT3DFilter. There're lots of other possibilities. Basically, you shouldn't use
# a clip with "a tiny bit of filtering". The search clip has to be CALM. Ideally, it should be "dead calm".
filter = defined(denoise) ? denoise : o.fft3dfilter(sigma=sigma,sigma2=s2,sigma3=s3,sigma4=s4,bt=5,bw=bw,bh=bh,ow=ow,oh=oh)
filter = (HQ==true) ? filter.HQdn3D(4,3,6,6) : filter
srch = filter

# "spat" is a prefiltered clip which is used to limit the effect of the 1st MV-denoise stage.
# For simplicity, we just use the same FFT3DFilter. There're lots of other possibilities.
spat = filter
spatD = mt_makediff(o,spat)

# Motion vector search (With very basic parameters. Add your own parameters as needed.)
b3vec = (degrain==3) ? srch.MVAnalyse(isb = true, delta = 3, pel = pel, overlap = ov, idx = 1) : BlankClip
b2vec = srch.MVAnalyse(isb = true, delta = 2, pel = pel, overlap = ov, idx = 1)
b1vec = srch.MVAnalyse(isb = true, delta = 1, pel = pel, overlap = ov, idx = 1)
f1vec = srch.MVAnalyse(isb = false, delta = 1, pel = pel, overlap = ov, idx = 1)
f2vec = srch.MVAnalyse(isb = false, delta = 2, pel = pel, overlap = ov, idx = 1)
f3vec = (degrain==3) ? srch.MVAnalyse(isb = false, delta = 3, pel = pel, overlap = ov, idx = 1) : BlankClip

# First MV-denoising stage. Usually here's some temporal-median filtering going on.
# For simplicity, we just use MVDegrain.
NR1 = (degrain==3) ? o.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD1,idx=2) :
\ o.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD1,idx=2)
NR1D = mt_makediff(o,NR1)

# Limit NR1 to not do more than what "spat" would do.
DD = mt_lutxy(spatD,NR1D,"x 128 - abs y 128 - abs < x y ?")
NR1x = o.mt_makediff(DD,U=2,V=2)

# Second MV-denoising stage. We use MVDegrain2.
NR2 = (degrain==3) ? NR1x.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD2,idx=3) :
\ NR1x.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD2,idx=3)

# Contra-sharpening: sharpen the denoised clip, but don't add more to any pixel than what was removed previously.
# (Here: A simple area-based version with relaxed restriction. The full version is more complicated.)
s = NR2.minblur(1,1) # Damp down remaining spots of the denoised clip.
allD = mt_makediff(o,NR2) # The difference achieved by the denoising.
2ssD = 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.

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

return(last)
}

function MVDegrain3 ( clip input, clip "bvec1", clip "fvec1", clip "bvec2", clip "fvec2", clip "bvec3", clip "fvec3", int "thSAD", int "idx" )
{
SAD = default( thSAD, 400)
idx = default( idx, -11)

degrain1 = input.mvdegrain2(bvec1,fvec1,bvec2,fvec2,thSAD=SAD,idx=idx)
degrain2 = degrain1.mvdegrain1(bvec3,fvec3,thSAD=SAD,idx=idx)
output = degrain1.merge(degrain2, 0.4286)
return(output)
}

# From Didee's MCBob script
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 : -200

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)
}

ankurs

27th December 2007, 20:11

^

yes it is working fine now :) .. let me try and do some sample encodes with both of them ( the previous version and the present one ) and see if there are any speed differences which i am able to achieve on the same sample .. hopefully will post the results here soon ..

P.S : Thanks a LOT didee .. u da man :p

Sagekilla

28th December 2007, 06:44

Thanks for the correction Didee, I'll get back to working on that and fixing that little screw up when I get the chance. For now, I need to sleep as it's 12:45 AM.

Boulder

28th December 2007, 10:54

SAD1 = default( SAD1, 300 ) # Threshold for degraining, decrease for more effectIsn't this the other way around, a lower threshold means less effect?

Terranigma

28th December 2007, 15:46

SAD1 = default( SAD1, 300 ) # Threshold for degraining, decrease for more effectIsn't this the other way around, a lower threshold means less effect?
Depends. For thsad strength in mvdegrain, yes, but for other means such as mvmask, a lower value will result in more areas being affected. For the ml value, I usually have it to whatever the thsad strength is divided by 8.

Boulder

28th December 2007, 16:17

Depends. For thsad strength in mvdegrain, yes, but for other means such as mvmask, a lower value will result in more areas being affected. For the ml value, I usually have it to whatever the thsad strength is divided by 8.Yes, I meant threshold in MVDegrain as is it used in the function :)

Sagekilla

28th December 2007, 19:44

I fixed a few things, mostly cosmetics and (hopefully) fixed that line break screwup. Also fixed a potential error from having too low of a sigma, since I had sigma2,3,4 based off sigma 1 on a subtraction basis. It now works as a (rounded) fraction of sigma. Still, you shouldn't need to adjust it or any of the params, except maybe enabling HQ mode, since the script works great at defaults.

Updated script is at post #116 (http://forum.doom9.org/showpost.php?p=1078534&postcount=116)

CruNcher

14th January 2008, 19:05

Didee how did you avoid Grain in Motion in your easy.mkv?, all my tries endup in grain when characters move :(

Didée

14th January 2008, 21:16

how did you avoid Grain in Motion in your easy.mkv? By mumbling some secret incantations while the posted script (http://forum.doom9.org/showthread.php?p=1076276#post1076276) was rendering. :)

Zep

14th January 2008, 21:50

Didee how did you avoid Grain in Motion in your easy.mkv?, all my tries endup in grain when characters move :(

note the huge problem though that Didee posted about later.
it is very nasty and I had to end up not using motion vectors at all cause they just screw up too much and are also so darn slow to calc.

My current testing I have dumped all MV calls and I am doing just masking like I was doing at the start of thread. It is sorta a hybrid now from how I started out and Didee's script and it works better than either way. No MVAnalyse artifacts when it can not figured out what to do which is often in this very high motion movie.

BTW - Didee I am doing the full 1080p now and not 720p anymore and the detail is just so sweet :)

Sagekilla

14th January 2008, 22:50

By mumbling some secret incantations while the posted script (http://forum.doom9.org/showthread.php?p=1076276#post1076276) was rendering. :)

Or the associated function (http://forum.doom9.org/showpost.php?p=1078534&postcount=116) made from magical bits, which can make things easier :)

CruNcher

14th January 2008, 23:37

oops i see i removed that part when trying to make it processing faster (minblur) thought it was belonging to the contrast sharpener as a whole ;)

Great Dragon

28th January 2008, 15:51

How can i use MT with this function?
setmtmode(any) - dont work. CPU load is 25% only, and speed dont increase.
MT("temporaldegrain()",4,4) - picture get broken.

Sagekilla

28th January 2008, 19:02

I don't use MT() actually. I use the MTified version of Avisynth, and use the following:

SetMTMode(2)
TemporalDegrain()

Gives me usually 80% speed boost. I have to debug and see how the function plays with MT(), because I've never used it thus far. On a side note, have you tried using other MT modes, like 2, 3, or 5?
I have to update the function anyway, it's quite borked at the moment in several aspects because of my muddling around.

Latest vesrion is in #116 (http://forum.doom9.org/showpost.php?p=1078534&postcount=116)

Dreassica

28th January 2008, 19:42

Odd, MT(2) doesn't give me any speedboost at all with this script, on a q6600 its 1.6fps for both standard and MT().

Sagekilla

28th January 2008, 19:51

Odd indeed, because I've seen my virtualdubmod scripts run faster with it on. This was when I was testing a very old version of this script though.. Things may have changed in between, so I'll have to do testing again to see if this still holds true. Also, I did some testing and found MVTools functions don't like to play nice with MT()

Try running the following as a function. It won't work at all. So no multithreading for the MVDegrain, unfortunately.

Avisource("test.avi")
MT("Degrain(),2,2")

function Degrain ( clip input )
{
o = input

b2vec = o.MVAnalyse(isb=true, delta=2, pel=2, idx=1)
b1vec = o.MVAnalyse(isb=true, delta=1, pel=2, idx=1)
f1vec = o.MVAnalyse(isb=false, delta=1, pel=2, idx=1)
f2vec = o.MVAnalyse(isb=false, delta=2, pel=2, idx=1)

NR1 = o.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=300,idx=2)

return(NR1)
}

Sagekilla

28th January 2008, 20:02

Alright, I've done a quick test on 50 frames and without SetMTMode(2), it took 31 seconds to run the script. With SetMTMode, it took 23 seconds less. Roughly 35% faster with multithreading.

Conspiracy theories anyone?

Dreassica

28th January 2008, 20:10

That little script doesnt load.

Didée

28th January 2008, 20:21

Sagekilla, the script in post#161 can't work: "2ssD" in the contra-sharp section is a plain impossibility, it should read "ssD". ;)

Also, SeeSaw is in there now ... what a pity.

edit: script in post#163 is missing a ")" parenthesis at the end of line 2.

Adub

28th January 2008, 20:39

What versions of Masktools and MVtools do you have?

Sagekilla

28th January 2008, 20:53

Dreassica

28th January 2008, 21:14

Still getting a syntax error from that line.

Didée

28th January 2008, 21:20

I've no clue about MT stuff, I'm on single core only ... however

MT("Degrain()",2,2)

would seem logical.

Sagekilla

28th January 2008, 21:21

Yeah, that whole line got narfed up. It was just a script to demonstrate that MV Tools and MT don't play nicely, except I keep screwing up the script somehow.

Dreassica

28th January 2008, 21:22

Yep, moved the " and now it loads fine.
Video is screwed up though.

Using setmtmode(2,4) it works fine. Oddly here I do get a significant boost in speed. from 1.15min on a 1000 frame sample without, to 24 seconds with setmtmode. But I get zero speedincrease with temporaldegrain script.

Boulder

28th January 2008, 21:26

MT and MVTools don't work together. You need to use SetMTMode if you want multithreading.

Sagekilla

28th January 2008, 21:30

Yep, moved the " and now it loads fine.
Video is screwed up though.

Exactly my point: The reason why MT("Temporal_Degrain",2,2) doesn't work (graphical errors) is because MT and MVTools shouldn't mix. One particualr thing is idx needs to be unique for each thread, according to this (http://forum.doom9.org/showthread.php?t=94996&page=33) (See first post)

Dreassica

28th January 2008, 21:33

Well then why does setmtmode work fine then? Or am I missing something here.

Boulder

28th January 2008, 21:38

MT splits the frame in multiple halves, SetMTMode processes multiple whole frames simultaneously.

Dreassica

28th January 2008, 21:46

Guess I did miss something basic then :)
Still odd that I don't get any benefit from using it on temporalgrain only.

Sagekilla

28th January 2008, 21:50

Guess I did miss something basic then :)
Still odd that I don't get any benefit from using it on temporalgrain only.

Indeed, you said you're running a Q6600? I'm running an Opteron 170 (dual core) and SetMTMode(2) provides me a 35% speed boost. Try this:

SetMTMode(2)
Avisource("file.avi")
Trim(2000,2049)
TemporalDegrain()

Then run it through VirtualDubMod, tell it to save as Lagarith on your hard drive and check the time it takes. Run another version of the script, except without SetMTMode(2) and check the time. There SHOULD be a speedup, I see no reason for it not to.

Dreassica

28th January 2008, 22:02

Sagekilla

28th January 2008, 22:09

Odd just caling it without arguments i get roughly 4 to 5 times the fps with setmtmode, maybe callign slowest arguments in temporaldegrain kills any advantage I'dget with setmtmode, as I only get .1 increase in fps.
Used TemporalDegrain(degrain=3,sad1=100,sad2=100,pel=4,ov=4)

That's because TemporalDegrain defaults to degrain=2, sad1=300, sad2=300, pel=2, ov=4. You used much slower settings (namely pel=4 and degrain=3) so that's why it was so much faster. Also, try giving HQ=2 a spin. TD defaults to HQ=1, but 2 enables HQdn3D prepass for the motion vector search. It usually gives a small boost in compression ratios.

Dreassica

28th January 2008, 22:15

But is it THAT slower taht it completely nullifies multithreading advantage??

Sagekilla

28th January 2008, 22:19

But is it THAT slower taht it completely nullifies multithreading advantage??

I'll have to take a look and see.. By using MVDegrain3, you're using two extra frames to denoise (slower there), and you have to analyze another two frames (even slower). Plus, you're using twice the subpixel resolution so that slows things down even further. I usually use TemporalDegrain(HQ=2,degrain=2) and it gets the job done nicely, since pel=4 usually gives very minimal benefit. You'd get more out of going to Degrain=3 than going from pel=2 to pel=4 in any of the degrains, I blelieve.

It COULD be possible by using MVDegrain3, the function becomes so CPU bound on the MVTools functions that there's little benefit gained from using threading in the other filters. You can try using threads=2 to enable FFT3DFilter's built in multithreading, see if that helps any.

Dreassica

28th January 2008, 22:26

Oddly, increasing threads to 6 significantly boosts speeds up from 1.6fps to 3.2fps, tried 8 but then vdub shuts down after 10 secs.

Sagekilla

28th January 2008, 22:37

Odd indeed.. Perhaps it has something to do with how SetMTMode works -- since it works on a frame by frame basis, and now you're processing 6 full frames.

Sagekilla

12th February 2008, 06:18

Updated the script. It now does one last pass to remove any stray bits of dancing grain/noise. Was playing around with 300 and found that a (mostly) temporal HQDn3D could remove the tiny bits remaining. Enjoy. (http://forum.doom9.org/showpost.php?p=1078534&postcount=116)

Zep

12th February 2008, 22:57

Oddly, increasing threads to 6 significantly boosts speeds up from 1.6fps to 3.2fps, tried 8 but then vdub shuts down after 10 secs.

Most of the time it means you ran out of memory and Virtual memory doesn't help. You could increase VM and not crash but it will slow you way down.

Nikos

12th February 2008, 23:47

From post #116
SAD1 = default( SAD1, 300 ) # Threshold for degraining

From post #148
SAD1 = default( SAD1, 300 ) # Threshold for degraining, decrease for more effect

Small values mean more denoising or the opposite?
Any other parameter that affect the strenght of the denoising?

From old Fizick post:
There is no "filtering strength" parameter in MVDegrain.
It uses "simple" (i.e. very complex) temporal averaging.
The more frames, the more averaging.
But you can get more strong filtering with "overlap" option (up to half of block size).

I am a little confuse....

Thanks

Sagekilla

13th February 2008, 01:17

Ignore what I said in later posts. The script in #116 is the official one, all comments in other posts like #148 should be completely ignored. In #148, the reason why I commented SAD1 as having a greater effect was because when I tested it, lower values tended to have a stronger effect while higher ones had weaker effects. This was based entirely on my sample of 300 though, and should be taken with a grain (Ha! I cringed making that pun) of salt.

To answer your question though, if you read the MVtools documentation it points out what thSAD really is. thSAD determines the weighting applied to a pixel when MVDegrain processes a pixel. So, while it's not really a "strength" parameter, it can determine what gets processed and what doesn't.

Manao or Fizick, please correct me here if I'm wrong :) This is just based on my interpretation of the documentation.

Note: I'll be going back to remove all instances of my old function so there is no confusion as to which one is the latest instance.

Nikos

13th February 2008, 01:50

Thanks Sagekilla for the answer, but my wonder remain.
If i want more denoise or less denoise than default, which parameters i must change?

Sagekilla

13th February 2008, 01:58

If you're using my Temporal Degrain, a very rudimentary way of adjusting the strength is by using MVDegrain with 1, 2, or 3 frames backwards/forwards. Less frames means less (and faster) filtering, more frames means more (and slower) filtering. That's the most direct way of changing filtering strength, but not the best. I advise you to play around with the thSAD2 and thSAD1 (more so the thSAD2) parameters to see how much iltering you get out of it. In the mean time, I'll play around with my own function (which I still don't know the breadth of it's functionality) to give you a better answer.

If you're talking about the actual MVDegrain on it's own, that would be (as above) the thSAD parameter. To quote the MVTools documentation: "Low values can result in staggered denoising, large values can rezult in ghosting and artefactes." In other words, low thSAD is less denoise, high thSAD is more denoise.

Nikos

13th February 2008, 02:14

Thanks again for the answer. I had read the mvtools documentation but i don't understand what mean exactly the word staggered :)
My native language it's not english.

I am happy with your function, the results are satisfactory!!!
I experiment with HD movies from moderate quality Blu-ray with a lot of nasty grain.

Sagekilla

13th February 2008, 02:34

Staggered means that the denoising will be.. "jumpy" that is, it will not be constant denoising. Some frames will be denoised, while others will not. The following line is an example of a "staggered" result, where x means it was denoised properly and y means it wasn't touched at all: xxxyxyyxyxy. What we want is a sequence like xxxxxxx, not xxyxyyxy.

Also, big credit goes to Didee for giving me a starting point.

Nikos

13th February 2008, 02:52

Also, big credit goes to Didee for giving me a starting point.
Sure, i am a Didee fan to.

Adub

13th February 2008, 06:55

@Sagekilla
I will be adding your script to the Avisynth wiki soon. Just letting you know. Feel free to edit the page when I finish. I will post a link to it when I am finished (probably tomorrow).

Jawed

13th February 2008, 16:27

Instead of "staggered" I'd use the word "patchy". e.g. in the sky you might see areas where the denoising is strong and other areas where there is more noise.

At the other extreme, when the denoising is too strong this causes areas of the picture to move around for no apparent reason.

Also you will find that moving parts of the picture will have a ghost, following them around. So, when someone moves from left to right you might see a faint version of that person following just behind them.

It's worth experimenting, but you need to use a variety of clips to see these problems. One clip might show patchy denoising while another clip is better to see ghosting.

Jawed

Nikos

13th February 2008, 17:34

Thanks Jawed for further explanation for "staggered".

Sagekilla in your TemporalDegrain function why you put the HQDn3D(2,1,6,1) after Contra-sharpening and not before?

Also any idea for other "spat" filter.

Sagekilla

13th February 2008, 19:08

To be perfectly honest, I still don't even know what half of the function does (Most of it was made by Didee, who is a far better scripter than I am) Person you should be asking what could be used for spat should be Didee -- But I'll take a look at this and experiment to change things around.

Also, the idea behind putting HQDn3D there was simply to kill off any dancing grain or noise that was left since it's working in almost purely temporal fashion. I put it there after I found that it did this fairly well, but I haven't gotten around to testing where it should be. I'll take a look at it later on today in regards to where the best place to apply it would be (Before or after the sharpening, that is)

@Jawed: Thanks for the correct explanation :)

Edit: I placed HQDn3D before the contra sharpening now (Thanks, Nikos) and lowered the strength since in the context of TD, it was too strong. (The first time I tried this, using a rather simple filter chain it needed the higher settings, but here not as much) Updated copy in post #116 now.

Adub

13th February 2008, 20:06

Added TemporalDegrain to the Avisynth Wiki.
Link:
http://avisynth.org/mediawiki/Temporal_Degrain

Sagekilla

13th February 2008, 20:31

Thanks Merlin7777. Is there any way for me to link the most recent copy of the script to the page? I just uploaded v1.17 that had a few important changes, but I can't figure out how to link the download Temporal Degrain to it.

Nikos

13th February 2008, 21:18

Sagekilla i think that you must restrict the overlap up to blksize/2.

From Fizick post:
There is no "filtering strength" parameter in MVDegrain.
It uses "simple" (i.e. very complex) temporal averaging.
The more frames, the more averaging.
But you can get more strong filtering with "overlap" option (up to half of block size).

For other functions, overlap may be simply lesser block size.
For mvdegrain: ... like FFT3DFilter, overlap value up to blksize/2
Any overlap is summation. Any summation is averaging. i.e. partial denoising.

Amefurashi

13th February 2008, 21:25

I noticed a little problem on a scenechange using TemporalDegrain. Here are previous and next frame using

mpeg2source("...")
Spline36Resize(640,336,0,12,720,552).subtitle("source")

http://img165.imageshack.us/img165/811/source1np1.png
http://img292.imageshack.us/img292/181/source2lh5.png

...but applying the function at its defaults, video ends up like this:

mpeg2source("...")
Spline36Resize(640,336,0,12,720,552).subtitle("filtered")
TemporalDegrain()

http://img502.imageshack.us/img502/2240/filtered1oz9.png
http://xs224.xs.to/xs224/08073/filtered_2869.png

There's a slight ghost of MJF's jeans near the right shoulder of the bald guy. Could this be caused by high FFT's sigma of the denoised clip? I tried to lower the value, but that spot is still noticeable.

:confused:

Sagekilla

13th February 2008, 21:35

It could be the sigma; What value did you try afterwards? A more likely issue would be thSAD, so try tweaking thSAD1 and thSAD2 too, those two can have a ghosting effect if set too high.

@Nikos: I'll patch TD to limit to 1/2 of blksize. It defaults to blksize of 8 anyway, and the default overlap of 4 is 1/2 that. But, I'll add blksize param and adjust overlap so it doesn't go above 1/2 blksize.

Edit: It's patched now so overlap max is blksize/2. Values over this should default to half block size. The default overlap is now 0 also, to make it faster without impacting quality too much.

Nikos

13th February 2008, 22:09

You may also add and the limit parameter :)

limit: maximal change of pixel (like DeGrainMedian plugin to prevent some artefactes). Default is 255 (no limit).

Change the:
blksize = default( blksize, 8 ) # Larger is weaker and faster, smaller is stronger and slower.
to
blksize = default( blksize, 8 ) # 4 or 8 or 16, larger is weaker and faster, smaller is stronger and slower.

Sagekilla

13th February 2008, 23:07

See the Avisynth documentation (http://avisynth.org/mediawiki/Temporal_Degrain#Description) for better explanation of the parameters. The comments were meant mostly for people who wanted to tweak the script, since default settings worked perfectly fine 99% of the time. I've removed most of the information, now just providing a small blurb on what each parameter does (You should look up what each parameter does for the used function tbh). Anyone looking for proper syntax should look at the wiki now, until I can provide proper documentation within the script.

Also, thanks once again for the suggestion Nikos. I've updated the script to make use of limit as well as fixed a small issue where blksize was irrelevant. Try the new version Amefurashi with defaults, and tell me if it fixes anything. If not, lower limit from 255 to see if it fixes things.

Zanejin

13th February 2008, 23:55

Wait, I see some contradictions regarding blksize. While the Avisynth documentation on Temporal Degrain asserts that "higher values are faster, less accurate, and degrain less", one of Didée's posts (https://forum.doom9.org/showpost.php?p=1070187&postcount=71) states the opposite.

Terranigma

14th February 2008, 00:08

Blocksize 8 would be the most sufficient blocksize. With blocksize 4, you run the risk of actually having a frame or frames being skipped over by the analysis process, but as far as the actual denoising, it's more sufficient than 8 as it's more accurate and more sensitive to noise. Blocksize 16 is the least sensitive and fastest, but it's the safest to use as it's more than likely never to skip any frames (although I haven't seen any frames being skipped with a blocksize of 8 either).

Nikos

14th February 2008, 00:17

From mvtools doc:
blksize : Size of a block (horizontal). It's either 4, 8 or 16 ( default is 8 ). Larger blocks are less sensitive to noise, are faster, but also less accurate.

I am a little confuse!!!
Didée help us please.......

Edit:
Thanks Terranigma for the explain.

Terranigma

14th February 2008, 00:23

From mvtools doc:

I am a little confuse!!!
Didée help us please.......

The docs' correct.
Think of the blocksize also as a detection threshold, where higher values would pick up more frames in the detection process.

Blocksize 4 = the ultimate for denoising, but weakest for detection (may run the risk of skipping frames, leaving the frame untouched.)

Blocksize 8 = medium threshold detection, medium denoising.

Blocksize 16 = low denoising, highest detection.

Don't know how else to explain it. :P

Sagekilla

14th February 2008, 00:23

Well, I was a bit ambiguous there I guess. Blksize 4 in relation to Blksize 16 -- Blksize 4 is slower, and tends to denoise more strongly. Blksize 16 is faster, but doesn't denoise as strongly.

How's this? "MVAnalyse block size. Valid values are 4,8,16. Higher values are faster, more accurate in detection, and degrain less. Lower is the opposite, while blksize=8 is a happy medium between both."

Edit: I think it might be easier if I just said low values are slow and strong, while higher ones are faster but weaker.

Nikos

14th February 2008, 00:34

Now, with the Terranigma explain, we are all happy :)
Thanks again.

Zanejin

14th February 2008, 00:37

I still don't understand. Didée's post, referenced in my previous post, says,

With a blocksize of 4, the denoising is rather poor.
This is because with such a small blocksize, the ME engine is able to (partially) compensate the grain, which results in much less effective denoising.

How can blksize = 16 then offer the lowest denoising? There are even samples in his post that show blksize = 16 stabilizes and removes grain most effectively in comparison to blksize = 4 and blksize = 8.

Terranigma

14th February 2008, 00:40

I still don't understand. Didée's post, referenced in my previous post, says that "with a blocksize of 4, the denoising is rather poor.
This is because with such a small blocksize, the ME engine is able to (partially) compensate the grain, which results in much less effective denoising." How can blksize = 16 then offer the lowest denoising?
lowest as in, weakest in strength. Didée may be referring to the detection threshold as I was talking about. If you do some tests yourself between 16, 8, and 4, you'd see 4 being stronger than it's larger blocksize kin. Examine around edges, or in dark areas, that's where blocksize 16 and 8 tends to perform poorly. You win some, and lose some with whatever blocksize you choose. I stick to 8.

__
If i'm wrong on this (which I doubt from self-experience), then Fizick would need to update his doc. :D

Sagekilla

14th February 2008, 01:21

lowest as in, weakest in strength. Didée may be referring to the detection threshold as I was talking about. If you do some tests yourself between 16, 8, and 4, you'd see 4 being stronger than it's larger blocksize kin. Examine around edges, or in dark areas, that's where blocksize 16 and 8 tends to perform poorly. You win some, and lose some with whatever blocksize you choose. I stick to 8.

__
If i'm wrong on this (which I doubt from self-experience), then Fizick would need to update his doc. :D

I think it would solve a lot of problems if I just removed blksize all together and got rid of potential confusion, since 8 seems to be the "one size fits all"

That would go against giving you enough rope to hang yourself though ;)

Nikos

14th February 2008, 20:32

Sagekilla i thing that in post #116 you must change the red idx from 2 to 3.
# Second MV-denoising stage. We use MVDegrain2.
NR2 = (degrain==3) ? NR1x.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD2,idx=2,limit=limit) :
\ (degrain==2) ? o.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD1,idx=2,limit=limit) :
\ o.MVDegrain1(b1vec,f1vec,thSAD=SAD1,idx=2,limit=limit)

Also may i replace the slow FFT3DFilter with the very fast RemoveGrain(mode=4) or for the prefiltered clip?

Terranigma

14th February 2008, 21:06

Sagekilla i thing that in post #116 you must change the red idx from 2 to 3.

No, that's correct; what he's doing there, is using the data from mvdegrain2 and then merging it with mvdegrain1 to create mvdegrain 3. If he wanted, he can even create mvdegrain 6, but only a crazed person would ever use it.

Also may i replace the slow FFT3DFilter with the very fast RemoveGrain(mode=4) or for the prefiltered clip?

You could, but he shouldn't; fft3d would be better than rg4. Don't have him change up the script unless he figures out good values for dfttest and use that instead. :D

Sounds like you're trying to turn this into what mc_spuds already is. :)

Nikos

14th February 2008, 21:23

Terranigma i am not an experienced user but in post #61 from Didée's script:
b3vec1 = fft.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)
b2vec1 = fft.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
b1vec1 = fft.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f1vec1 = fft.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=2, idx = 1)
f2vec1 = fft.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=2, idx = 1)
f3vec1 = fft.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=4, sharp=2, idx = 1)

NR1 = o .MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=2)
NR1D = mt_makediff(o,NR1)

DD = mt_lutxy(fftD,NR1D,"x 128 - abs y 128 - abs < x y ?")
NR1x = o.mt_makediff(DD,U=2,V=2)

NR2 = NR1x.MVDegrain3(b1vec1,f1vec1,b2vec1,f2vec1,b3vec1,f3vec1,thSAD=300,idx=3)

s = NR2.minblur(1,1)
allD = mt_makediff(o,NR2)
ssD = mt_makediff(s,s.removegrain(11,-1))
ssDD = ssD.repair(allD,1) .mt_lutxy(ssD,"x 128 - abs y 128 - abs < x y ?")

NR2.mt_adddiff(ssDD,U=2,V=2)

return(last)

Also from post #74:
vec = clip1.MVAnalyse( ..., idx = _idx1 )
foo = clip2.MVToolsFunction( vec,.., idx = _idx2 )

As long as clip1 == clip2 (identical), you can (and should) use identical values for _idx1 and _idx2.

As soon as clip1 != clip2 (not identical), you have to use different values for _idx1 and _idx2.

The vectors stored in 'vec' stay valid as long as clip1 and clip2 are of same size, and are in sync. (E.g. If one of both clips got trim()'ed, then you need new vectors, obviously.)

Final look at post #148
Until Sagekilla comes around for cleaning, here's the corrected script:
.......
# Second MV-denoising stage. We use MVDegrain2.
NR2 = (degrain==3) ? NR1x.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD2,idx=3) :
\ NR1x.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD2,idx=3)
The dfttest i thing is slow, any other fast filter for prefiltering?
Because we don't want quality but speed in prefiltering stage.

I have not read the mc_spuds until now, but i will give a try :)

Terranigma

14th February 2008, 21:33

Terranigma i am not an experienced user but in post #61 from Didée's script:

Actually, take a look @ post #70 to see how and what the script does; Didée breaks it down and tells you how it works.

Now about the same idx thing, take a look at this (http://forum.doom9.org/showthread.php?t=132310&page=7) post and scroll down a bit to see where using the same idx comes from. :)

Now, I like dfttest and fft3d for pre-filtering, because it lets you adjust all frequencies from a source with a given float value, whereas removegrain(#) might just operate on one frequencies, but always at the exact same strength; quality matters for pre-filtering too to a degree. ;)

Sagekilla

14th February 2008, 21:36

So is FFT3DFilter -- In fact, the way it was set up by Didee (bt=5, bw=16, bh=16, ow=8, oh=8) is EXTREMELY slow, but very high quality prefiltering. And yes, you do want quality in prefiltering. That's why I went a step further to add in a (optional) HQDn3D pass after FFT3DFilter to clean it up more. If you read the comments, ideally you want a very clean clip (no noise) clip so you can get better motion vectors, since there won't be any noise moving around to screw it up.

I'll test dfttest and FFT3DFilter to see the speed comparison, and play with the settings to see how good I can get dfttest to work. Also, if you want speed for prefiltering I suggest using FFT3DGPU in place of the CPU version, it can run in near realtime if you have a GPU (I'll add support for using GPU mode instead soon)

Results from testing dfttest:

Higher sigma means slower processing (at least it seemed to be much slower)
sigma=3 and tbsize=3 in the chain is half the speed of FFT3D (!) for the same quality.

Will work on other combinations, perhaps increasing tbsize a lot isn't the solution.

Adub

14th February 2008, 22:14

Yeah, you should be able to follow the link I posted, look to your left and find the "Upload File" Section. Under the Destination File name type "TemporalDegrain.avs" and select your TemporalDegrain.avs file using the browse button. It should say, "A file already exists with this filename, do you want to overwrite?" Just say, save or something like that, and double check on the main page that it is the correct version. Then, change the version number in the Function header on the main page.

Terranigma

14th February 2008, 22:18

Results from testing dfttest:

Higher sigma means slower processing (at least it seemed to be much slower)
sigma=3 and tbsize=3 in the chain is half the speed of FFT3D (!) for the same quality.

Will work on other combinations, perhaps increasing tbsize a lot isn't the solution.

Atm, the temporal operation of this filter (tbsize>1) is quite a bit slower than it needs to be since I don't cache the 2d transforms on each frame. The upside of the current method is that it uses a lot less memory (especially for small windows with large overlaps). If I get the time I will add optional caching.

If you think the quality's the same, then try changing the window method and increasing the overlap size. Unlike fft3d, the blocksize doesn't have to be blocksize/2, you can do something like this:
sbsize=8,sosize=6.
..and if you use subtract, you can see a big difference between overlap 4 and 6. :)

Nikos

14th February 2008, 22:35

Terranigma i read your suggestion, the script on post #116 and the script on post #148.
Now i thing that there are two more mistakes in post 116 (red color):
# Limit NR1 to not do more than what "spat" would do.
DD = mt_lutxy(spatD,NR1D,"x 128 - abs y 128 - abs < x y ?")
NR1x = o.mt_makediff(DD,U=2,V=2)

# Second MV-denoising stage. We use MVDegrain2.
NR2 = (degrain==3) ? NR1x.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD2,idx=2,limit=limit) :
\ (degrain==2) ? o.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD1,idx=2,limit=limit) :
\ o.MVDegrain1(b1vec,f1vec,thSAD=SAD1,idx=2,limit=limit)
o???

Look at post #148 Didée's opinion:
# Limit NR1 to not do more than what "spat" would do.
DD = mt_lutxy(spatD,NR1D,"x 128 - abs y 128 - abs < x y ?")
NR1x = o.mt_makediff(DD,U=2,V=2)

# Second MV-denoising stage. We use MVDegrain2.
NR2 = (degrain==3) ? NR1x.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,thSAD=SAD2,idx=3) :
\ NR1x.MVDegrain2(b1vec,f1vec,b2vec,f2vec,thSAD=SAD2,idx=3)
If i am wrong forgive me.
Didée help, please.

Sagekilla

14th February 2008, 22:39

Thank you for pointing that out nikos, that is indeed an error. I'll upload a fixed version shortly.

In regards to dfttest vs FFT3DFilter: I've found dfttest(sigma=2.5,tbsize=1,sbsize=8,sosize=6) works very well. It seems to retain a smidge more detail and handles the classic "grain and snow to soup" scene in 300 very well. Plus, in the two tests I've run it was faster than FFT3DFilter -- 2:08 vs 2:17 and 0:56 vs 1:25 (m:s, dft vs fft)

Edit: After this string of extremely bad syntax errors on my part, I'll take some time today to comb over my code and make sure no more like that arise.

Sagekilla

14th February 2008, 23:11

Alright, I've fixed a number of things and added a new parameter (for now) called ppass. If you use ppass="dft", dfttest will be used. Likewise, ppass="fft" will utilize FFT3DFilter.

Please test it on a number of scripts and tell me if there are any significant differences in quality and speed. I'd like to see if FFT3DFilter can be replaced by dfttest. Here's (http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs)the new version

Also, feel free to tweak the parameters of the dfttest call to see if you can improve it. Download the dfttest package from here (http://web.missouri.edu/~kes25c/) to get the documentation, or here (http://web.missouri.edu/~kes25c/dfttest.zip) for a direct link.

Terranigma

15th February 2008, 00:00

See, told you dfttest would be better. :P
I just wish the temporal operation was cached. If tritical takes request, then i'd only request for this to be fixed, and i'd like to be able to filter each frequency separately like with fft3d; That'd be very nice, but I think it might be better just to post this in the dfttest thread i've started.
Sage, could you try using the rectangular window instead of hanning (which is the default)? That's what i've found to be the better window type for denoising.

Also, for even faster processing, you can disable filtering the chroma planes, and just filter the luma like with fft3d by adding
Y=true, U=false, V=false to the filter. I've done a lot of tests with this filter, but one thing I still don't understand, is how to use cfile correctly; tritical would need to explain that a bit more or show some examples.
tritical, :script: :D

Sagekilla

15th February 2008, 00:03

Will do, I'll update dfttest to a rectangular window, disable chroma filtering and post results in a little bit.

Edit: New dft call takes 1:14 vs 1:17 for the old one. Quality differences may not be directly obvious though. Here's (http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs) the link to an updated TD

Sasovics

15th February 2008, 01:44

I have a problem playing back my avs script using the latest TemporalDegrain.avs v1.18

The clip plays, but the screen is completely black! What am I doing wrong ??

Here is my avs script:

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\dfttest.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\FFT3DFilter.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MVtools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\HQdn3D.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrain.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\Repair.dll")
Import("C:\Program Files\AviSynth 2.5\plugins\TemporalDegrain.avs")

DirectShowSource("Source.grf", fps=23.976, framecount=165876, audio=false)
Crop(0,144,0,-136)
Spline36resize(1280,528)
Trim(0,5000)
TemporalDegrain()

The clip plays fine if I remove "TemporalDegrain()" line from my avs script...

Any idea guys ???

EDIT: @Sagekilla: Can you please post back the 1.17 version as that one was working fine for me, unfortunately I have overwritten it with this new one :(

Terranigma

15th February 2008, 01:55

add info() to your script, see what colorspace your source is. if it's anything other than YV12, then after directshowsource, add
ConvertToYV12()

___
It could be due to the changes he made; maybe he b0rk something, but i'm sure he'll have it fixed. :)

Sasovics

15th February 2008, 02:01

ColorSpace is YV12

Sagekilla

15th February 2008, 02:50

Very odd indeed -- Simply running TemporalDegrain() works fine for me. I'll go make sure the uploaded copy is identical to my local copy. Where did you download the script from? Avisynth wiki or from this thread?

Here's (http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs) a (slightly) updated copy. It may or may not fix your problem -- I'm not 100% sure.

On a side note, I really to start keeping copies of older versions.

Sasovics

15th February 2008, 02:57

Very odd indeed -- Simply running TemporalDegrain() works fine for me. I'll go make sure the uploaded copy is identical to my local copy.

Where did you download the script from? Avisynth wiki or from this thread?

I've downloaded it from here:

http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs

Sagekilla

15th February 2008, 03:04

I've downloaded it from here:

http://avisynth.org/mediawiki/upload/6/69/TemporalDegrain.avs

Hmm.. Did you try the copy that I just uploaded now?

Sasovics

15th February 2008, 03:08

Yes, still same issue :(

I have really no idea what might be going on ...

I have downloaded all the plugins as stated in your avs file,
except the fftw3.dll, that I had to download separately after my avs script complained about the missing DLL.

I have downloaded the fftw3.dll from here: http://forum.doom9.org/showthread.php?p=573156#post573156

EDIT: It works while encoding, but for some reason it does not work when I simply try to play my avs script in Windows Media Player or Media Player Classic.
also the x264 encoding is extremely slow! I am getting around 1fps in average... Is this normal ???

EDIT2: @Sagekilla: To avoid any version confusion, would you mind please to zip all your plugins used in this script (including your MT avisynth.dll) and upload it to RapidShare or MegaUpload ?
Many Thanks in advance!

Sagekilla

15th February 2008, 03:43

Yes, it's very normal for the encoding to run at 1 or 2 fps -- That's how slow the script runs. If you want it to run faster, try using TemporalDegrain(degrain=1,ov=2,pel=1,hq=2)

Also, I'll go zip the plugins used to mediafire in a moment for you. link (http://www.mediafire.com/?bdsfm4m2tzp)

Sasovics

15th February 2008, 03:45

What about loosing the quality using the above settings ? Is it noticable by naked eye ??

I just tried to encode couple of frames from Transformers HDDVD source and it gave me excellent results!

Sagekilla

15th February 2008, 03:47

No, there will be no loss of quality -- Only loss in degraining strength. MVDegrain2 (sometimes 3) is what I use on very heavily grained or noisy sources like 300. On the others I use MVDegrain1 because it's weaker, and much faster.

Sasovics

15th February 2008, 03:50

Great! Thx for the plugins.

One more question I have though ;)

What about the fftw3.dll ? Wasn't your avs script complainig about it ? I did not find it along with your archive.

Are you using the same version as I ? Downloaded from: http://forum.doom9.org/showthread.php?p=573156#post573156

Sagekilla

15th February 2008, 03:52

Sorry, forgot to include that.. You have to put that in your C:/Windows/System32/ folder. And yes, I run the same version.

thetoof

15th February 2008, 03:58

I don't know if it'll be of any help (and maybe you've already solved your problem), but here are a few things I can suggest you:

1 - Make sure fftw3 is in your system32 folder
2 - put all the plugins in avisynth's autoload plugin folder
3 - rename TemporalDegrain as "TemporalDegrain.avsi" and put it in avisynth's plugins folder
4 - Use a script with TemporalDegrain(whatever you like)

That's what I use and it works perfectly (you can still tweak some parameters in the .avsi if you want, but most sources will be handled very well), a simple script without any "loadplugin" or "import"... I have some other filters in my script, but it basically goes like this:

*Source("yourfilepathhere")
TemporalDegrain()

thetoof

15th February 2008, 04:04

@ Sagekilla

What is the difference in the corrected version you just uploaded? The only thing I can see is that "dft" and "fft" were switched in those lines. What's the effect of that tweak? I tried both and I can't see any visual difference...

filter = (ppass=="dft") ? filter.fft3dfilter(ncpu=ncpu,sigma=sigma,sigma2=s2,sigma3=s3,sigma4=s4,bt=5,bw=bw,bh=bh,ow=ow,oh=oh) : filter
filter = (ppass=="fft") ? filter.dfttest(sigma=2.5,tbsize=1,sbsize=8,sosize=6,u=false,v=false,swin=7,twin=7) : filter

Sagekilla

15th February 2008, 04:10

In my old script, the first line calls fft3dfilter IF prepass setting is "dft," while dfttest is called if prepass is "fft." It should be the other way around: fft calls fft3dfiler, and dft calls dfttest. It's a minor fix, but I also wen around making sure I had no syntax errors. I simply uploaded a new copy to be absolutely sure of this, so there may not be any other differences.

I'll try removing the dfttest filter and upload a new copy of Temporal Degrain labeled "experimental" that has this, while the standard one features the regular fft3dfilter call. I have a feeling that the problem is related to how I called fft3dfilter and dfttest.

Sasovics

15th February 2008, 12:19

Folks,

I've just encoded another 15000 frames from Transformers (h.264 1080p source - > x264 720p destination) and got more then excellent results!

AVInaptic reported VERY HIGH DRF quality when used Sagekilla's TemporalDegrain filter compared to MEDIUM DRF quality without the filter! Nice work Sagekilla!

The only backdraw is the speed.. At 2fps it would take almost 48h for me to encode the entire movie :( ... but that's the price paid for this quality boost

Adub

15th February 2008, 12:50

Just out of curiosity, were you using MT?

Sasovics

15th February 2008, 12:54

Actually no...

I have downloaded the MT version of the avisynth and have put this line into my avs script: SetMTmode(2), but for some reason
my encoding is even slower, and I have no idea why :(

fyi - I am running Intel Core 2 Duo E6700 2.6GHz

EDIT: Well, according to this (http://forum.doom9.org/showthread.php?p=852813#post852813) post, using MT when you already have 100%CPU usage (which I obviously have as x264 is running), will slow-down encoding even more...

Sagekilla

15th February 2008, 19:27

Thanks for the praise, but it should be directed towards Didee; He wrote the core functionality for TD. If you want, you can try TemporalDegrain(HQ=2,ov=2,Degrain=1) for a bit more speed. It doesn't degrain as strongly, but that's the offset of using MVDegrain1 over MVDegrain2.

I also have an extremely simple script that cleaned up 300 fairly well at about 6-8 fps. It's inherently multithreaded because I call MT() for the filter chain, so no need to use SetMTMode(). I'll send it to you if you're interested, but to be honest it's nothing special. Still, it did a fairly good job on degraining 300.

Sasovics

15th February 2008, 20:18

I am interested in that simplified script, please upload it to mediafire and I'll post back my feedback!

Thanks in advance!

Sagekilla

15th February 2008, 21:05

Here's the script, I couldn't upload it earlier because I was in school still. There should be a noticeable difference between Temporal Degrain and the Fast Degrain script, as well as a difference in sharpness since TD has Contra Sharpening.

Feel free to adjust any settings if you feel it isn't working for you, or you see room for improvement. Just ask that you send me a PM detailing any useful changes that I can add to this :) Only setting I recommend you be careful of is blksize, as sometimes you might getting blocking at 0 (I noticed this while testing on 300) If this is the case, raise it to 2.

###################################################################
# Fast Degrain by Sagekilla #
# #
# Nothing special, just removes noise and grain very quickly and #
# sharpens the image a bit. Runs at about 8 fps on my machine. #
# Tweak to your tastes, but defaults perform perfectly fine. #
# #
# Required plugins: HQDn3d.dll / LimitedSharpenFaster.avs #
# MT.dll / mt_masktools.dll / MVTools.dll #
# #
###################################################################

# Fast Degrain Syntax
#
# threads = Number of threads for MT -- Speeds up the program on multicores.
# degrain = Uses MVDegrain 1, 2, or 3. Each is progressively stronger and slower.
# thSAD = Affects overall degraining strength. Default works fine.
# limit = Limits maximum change from MVDegrain. Lower from 255 if you experience artifacts.
# pel = Subpixel accuracy for MVAnalyse. Increasing it raises quality of MVs and lowers speed.
# ov =

function FastDegrain( clip input, int "threads", int "degrain", int "thSAD", int "limit", int "pel",
\ int "blksize", bool "sharp", bool "post", int "str", float "ss", int "sft", int "oshot" )
{
threads = default( threads, 0 ) # Threads to use for MT
degrain = default( degrain, 2 ) # Degraining method
thSAD = default( thSAD, 350 ) # MVDegrain thSAD
limit = default( limit, 255 ) # MVDegrain limit
pel = default( pel, 1 ) # MVAnalyse pel
ov = default( ov, 0 ) # MVAnalyse block size
sharp = default( sharp, true ) # Toggles LSF
post = default( post, true ) # Toggles postprocessing
str = default( str, 150 ) # LSF strength
ss = default( ss, 1.5 ) # LSF supersampling
sft = default( sft, 40 ) # LSF soft
oshot = default( oshot, 0 ) # LSF overshoot
Return(input)
global idx1 = 50

MT("""
idx1 = idx1 + 1
f = last
o = f

# Search for motion vectors. No prefiltered clips because it slows things down too much.
b3vec = (degrain>=3) ? o.MVAnalyse(isb=true, delta=3,idx=idx1,pel=pel,ov=ov) : BlankClip
b2vec = (degrain>=2) ? o.MVAnalyse(isb=true, delta=2,idx=idx1,pel=pel,ov=ov) : BlankClip
b1vec = (degrain>=1) ? o.MVAnalyse(isb=true, delta=1,idx=idx1,pel=pel,ov=ov) : BlankClip
f1vec = (degrain>=1) ? o.MVAnalyse(isb=false,delta=1,idx=idx1,pel=pel,ov=ov) : BlankClip
f2vec = (degrain>=2) ? o.MVAnalyse(isb=false,delta=2,idx=idx1,pel=pel,ov=ov) : BlankClip
f3vec = (degrain>=3) ? o.MVAnalyse(isb=false,delta=3,idx=idx1,pel=pel,ov=ov) : BlankClip

# Degraining the video using MVDegrain. Nothing special here.
f = (degrain==3) ? f.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=idx1) : f
f = (degrain==2) ? f.MVDegrain2(b1vec,f1vec,b2vec,f2vec,idx=idx1) : f
f = (degrain==1) ? f.MVDegrain1(b1vec,f1vec,idx=idx1) : f

# Sharpen the video a bit to counter the slight loss of detail and texture.
# Follow this up by post processing to remove stray dancing pixels.
f = (sharp==true) ? f.LimitedSharpenFaster(strength=str,ss_x=ss,ss_y=ss,soft=sft,overshoot=oshot) : f
f = (post==true) ? f.HQDn3D(2,1,6,1) : f

return(f)
""",threads,2)
}

Enjoy.

Adub

15th February 2008, 21:59

Want me to add it to the wiki?

Sasovics

15th February 2008, 22:14

Where do I get the LimitedSharpenFaster.avs script ?

Adub

15th February 2008, 22:15

1. Using search.
2. Here:
http://avisynth.org/mediawiki/LimitedSharpen

Sagekilla

15th February 2008, 22:20

Want me to add it to the wiki?

You can stick it under the TemporalDegrain one as an alternative, faster degraining method. It uses pretty much the same syntax as TD does.

Adub

15th February 2008, 22:27

Cool, will do.
Edit: Done.

Sagekilla

15th February 2008, 22:50

Also, I just got my hands on a new Blu-Ray drive so I can finally rip and play with 300 in HD! I'll see if I can do a before and after using 1080p frames to show how well it works, and help me do testing to improve it. If I have enough time, I might even encode it twice to show the bitrate reduction possible.

Edit: How odd, I tried changing the idx on the NR2 MVDegrain from idx=2 to idx=3 and wanna know what my results were? idx=2 (same idx as the last MVdegrain) was more detailed and looked better. It was only MARGINALLY better though. You have to look VERY closely to see if there was any change.

Results from no TD (first one) vs with TD
G:\Movies\300_HD>x264_aq --crf 18 --ref 5 --mixed-refs --no-fast-pskip --bframes
16 --bime --weightb --b-pyramid --b-rdo --8x8dct --subme 7 --me umh --trellis 1
--aq-strength 0.3 --threads auto --progress "source.avs" --output "Grainy.264"
--pass 1 --stats "Grainy.log"
avis [info]: 1920x800 @ 23.98 fps (360 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
x264 [info]: slice I:2 Avg QP:15.80 size:402956 PSNR Mean Y:47.30 U:51.04
V:51.57 Avg:48.26 Global:48.26
x264 [info]: slice P:181 Avg QP:18.05 size:224610 PSNR Mean Y:44.65 U:49.72
V:50.04 Avg:45.80 Global:45.78
x264 [info]: slice B:177 Avg QP:20.15 size:152771 PSNR Mean Y:42.90 U:49.27
V:49.64 Avg:44.20 Global:44.18
x264 [info]: mb I I16..4: 29.0% 45.7% 25.3%
x264 [info]: mb P I16..4: 29.5% 16.7% 12.0% P16..4: 18.4% 17.3% 5.1% 0.0% 0
.0% skip: 0.9%
x264 [info]: mb B I16..4: 13.4% 7.8% 7.2% B16..8: 38.1% 6.1% 6.6% direct:
14.4% skip: 6.4%
x264 [info]: 8x8 transform intra:28.5% inter:17.4%
x264 [info]: ref P 75.9% 12.5% 6.4% 3.2% 2.1%
x264 [info]: ref B 74.2% 19.5% 4.4% 2.0%
x264 [info]: SSIM Mean Y:0.9813726
x264 [info]: PSNR Mean Y:43.801 U:49.506 V:49.853 Avg:45.025 Global:44.928 kb/s:
36497.25

encoded 360 frames, 0.68 fps, 36497.60 kb/s

G:\Movies\300_HD>pause
Press any key to continue . . .

G:\Movies\300_HD>pause
Press any key to continue . . .

G:\Movies\300_HD>x264_aq --crf 18 --ref 5 --mixed-refs --no-fast-pskip --bframes
16 --bime --weightb --b-pyramid --b-rdo --8x8dct --subme 7 --me umh --trellis 1
--aq-strength 0.3 --threads auto --progress "source.avs" --output "NotGrainy.26
4" --pass 1 --stats "NotGrainy.log"
avis [info]: 1920x800 @ 23.98 fps (360 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
x264 [info]: slice I:2 Avg QP:15.45 size:278436 PSNR Mean Y:47.03 U:51.37
V:51.57 Avg:48.07 Global:48.07
x264 [info]: slice P:136 Avg QP:17.75 size:108867 PSNR Mean Y:44.63 U:50.04
V:50.26 Avg:45.81 Global:45.79
x264 [info]: slice B:222 Avg QP:19.84 size: 32984 PSNR Mean Y:43.42 U:50.00
V:50.23 Avg:44.73 Global:44.71
x264 [info]: mb I I16..4: 21.3% 54.7% 24.0%
x264 [info]: mb P I16..4: 6.4% 12.5% 3.1% P16..4: 34.6% 30.1% 11.2% 0.0% 0
.0% skip: 2.1%
x264 [info]: mb B I16..4: 0.3% 0.7% 0.2% B16..8: 38.1% 3.7% 8.2% direct:
6.2% skip:42.6%
x264 [info]: 8x8 transform intra:57.0% inter:46.0%
x264 [info]: ref P 70.6% 21.3% 3.3% 2.4% 2.3%
x264 [info]: ref B 85.3% 13.8% 0.6% 0.3%
x264 [info]: SSIM Mean Y:0.9810072
x264 [info]: PSNR Mean Y:43.895 U:50.026 V:50.245 Avg:45.159 Global:45.100 kb/s:
12086.75

encoded 360 frames, 0.26 fps, 12087.09 kb/s

G:\Movies\300_HD>pause
Press any key to continue . . .

Sagekilla

17th February 2008, 00:02

Sasovics, did my updated script or the uploaded version work for you at all or do you still have problems?

Sasovics

17th February 2008, 02:06

Post moved to separate topic here (http://forum.doom9.org/showthread.php?t=134917)

Sagekilla

17th February 2008, 02:55

Please don't use my FastDegrain -- It's currently b0rked. Also, Sasovics please don't cross post.

Nikos

17th February 2008, 03:48

Edit: How odd, I tried changing the idx on the NR2 MVDegrain from idx=2 to idx=3 and wanna know what my results were? idx=2 (same idx as the last MVdegrain) was more detailed and looked better. It was only MARGINALLY better though. You have to look VERY closely to see if there was any change.
According to Didée from post 125 for using 2 mvdegrain (mvdegrain2+mvdegrain1):
Without corrected weightings, it will denoise less, not more. (Unless you split the idx'es, then it will denoise more indeed.)

With the word split he mean different idx in each degrainX?
We need a little more teaching from Didée about idx :)

Terranigma

17th February 2008, 04:30

I think the guy "Bobby" who encoded the movie, had to use some kind of combination of avs filters as I am using the very same x264 encoder settings and of course the very same source, US retail HDDVD.

I have tried various avs filters, including Sagekilla's TemporalDegrain, FastDegrain, Dark Shikari's GrainOptimizer,
as well the LimitedSharpenFaster alone and many more.

None of them helped to get to the quality of iLL release :(

Because iLL's like the greatest (real-life source) encoder there is?
They don't use any of these premade scripts, I can tell you that for sure. :)

Sasovics

17th February 2008, 04:33

Because iLL's like the greatest (real-life source) encoder there is?
They don't use any of these premade scripts, I can tell you that for sure. :)

Don't understand what you mean with that "real-life source"
.. if they don't use these scripts, what are they using ? How can you tell ?

Terranigma

17th February 2008, 04:42

Don't understand what you mean with that "real-life source"

Real Life source, as in, non-toon sources (like this movie 300 for instance).

.. if they don't use these scripts, what are they using ? How can you tell ?
I can tell because they've been encoding way before temporaldegrain, mc_spuds, or this thread started, so that shouldn't be so hard to figure out.:cool:
(btw, lets leave out encoders or groups for that matter, as it's against the rules per se.)

Lets just say that what they use is actually simpler than you think; btw, it's not so hard to write scripts, just look over the syntax document in avisynth's directory, or take examples from scripts like mc_spuds or temporaldegrain for that matter.

Sagekilla

17th February 2008, 05:14

Real Life source, as in, non-toon sources (like this movie 300 for instance).

I can tell because they've been encoding way before temporaldegrain, mc_spuds, or this thread started, so that shouldn't be so hard to figure out.:cool:
(btw, lets leave out encoders or groups for that matter, as it's against the rules per se.)

Lets just say that what they use is actually simpler than you think; btw, it's not so hard to write scripts, just look over the syntax document in avisynth's directory, or take examples from scripts like mc_spuds or temporaldegrain for that matter.

Indeed, TD is fairly simple as far as filter chains go. It doesn't use a lot of complex concepts compared to others imo.

Didée

17th February 2008, 19:03

ATM I've not the energy (a really bad flu', can't concentrate) to cut through all the stuff posted on the last few pages.

Not sure if it's to rate as "tragedy" or "comedy" ... In any case, lots of nonsense has been posted.

There've been really screwed-up findings & correlations about blocksizes, bogus inventions like "detection thresholds", funny alternate filters (dfttest with default tbsize=1 versus fft3dfilter with bt=5 ... hell, you cannot compare that!), instances of non-functional functions, even posted to the wiki (Sagekilla, do you actually try your own stuff? MVAnalyse has no argument "ov", only "overlap", and why is "ov" responsible for "blocksize"), backwards-evolutions of proven concepts (in the longer-ago past, the biggest complain about MVDenoise was blockyness due to not-yet implemented block-overlap modes ... nowadays block overlapping is hardcoded'ly taken away because of performance...welcome in stoneage), and what not else.

Back to sick bed, crying in silence.

Terranigma

17th February 2008, 19:42

Welcome back Didée. Hope you get well soon, and then you can explain to us about some of the nonsense that was posted (I know that i'm responsible for most of it. :D). Honestly though, Fizick would have to update his document if blocksize 4 is weaker than blocksize 8 for denoising. I was thinking that they also functioned like the blockx, blocky arguments in tfm. Again, from comparisons i've done, blocksize 4 seemed to be stronger than 8 and 16 just like how Fizick has it documented, but whatever: you're the expert around these parts. :)

jeffy

17th February 2008, 20:54

Didée,
please get well soon and forget all the nonsense for a while!
:thanks: for everything.

Back to sick bed, crying in silence.

foxyshadis

17th February 2008, 22:22

Zanejin

17th February 2008, 23:32

It's not so much that blocksize 4 is stronger, it's that it has a higher chance of making bad correlations and subsequently denoising places that shouldn't by rights have been affected. Meaning smudgier details and edges in random places. blocksize 8 or 16 with a soft threshold, as Didée's been asking for forever, would be a better improvement.

So for MVAnalyse, based purely on results for MVDegrain, the blksize value that gives the greatest speed also happens to give the strongest and most accurate filtering?

Nikos

18th February 2008, 03:45

Welcome back Didée.
Please explain to me the differents if any between 1 and 2:

1.
source=last
b1_vec = source.MVAnalyse(isb = true, delta = 1, blksize = 8, overlap =4, pel = 2, sharp= 2, idx=1)
f1_vec = source.MVAnalyse(isb = false, delta = 1, blksize = 8, overlap =4, pel = 2, sharp= 2, idx=1)

NR1=source.MVDegrain1(b1_vec, f1_vec, thSAD = 400, idx = 1)
NRa=NR1.MVDegrain1(b1_vec, f1_vec, thSAD = 400, idx = 1)

2.
source=last
b1_vec = source.MVAnalyse(isb = true, delta = 1, blksize =8, overlap = 4, pel = 2, sharp = 2, idx = 1)
f1_vec = source.MVAnalyse(isb = false, delta = 1, blksize =8, overlap = 4, pel = 2, sharp = 2, idx = 1)

NR1=source.MVDegrain1(b1_vec, f1_vec, thSAD = 400, idx = 1)
NRb=NR1.MVDegrain1(b1_vec, f1_vec, thSAD= 400, idx = 2)

And the correlation, if any between the two above with this:
3.
source=last
b2_vec = source.MVAnalyse(isb = true, delta = 2, blksize = 8, overlap = 4, pel = 2, sharp = 2, idx = 1)
b1_vec = source.MVAnalyse(isb = true, delta = 1, blksize = 8, overlap = 4, pel = 2, sharp = 2, idx = 1)
f1_vec = source.MVAnalyse(isb = false, delta = 1, blksize = 8, overlap = 4, pel = 2, sharp = 2, idx = 1)
f2_vec = source.MVAnalyse(isb = false, delta = 2, blksize = 8, overlap = 4, pel = 2, sharp = 2, idx = 1)

NRc=source.MVDegrain2(b1_vec, f1_vec, b2_vec, f2_vec, thSAD = 400, idx = 1)

I know that here (3) we have more frames.

Thank you.

foxyshadis

18th February 2008, 03:58

Strongest and fastest, but least accurate. On the other hand, it can be more accurate on some edges. Using large blocksizes in most areas and progressively smaller ones in occulded areas is the best way, as x264 does, but what can you do at the moment, y'know? This was discussed in the mvtools thread a while back.

Nikos

18th February 2008, 15:17

Thank you foxyshadis for the reply. Yoy mean that 1 and 2 are strongest and fastest but least accurate than 3 in my understanding.

What's the differents between 1 and 2?
Both of them are correct or only one?

foxyshadis

18th February 2008, 19:34

Sorry, that was a reply to Zanejin.

You always have to use a new idx when you use a new source (unless you use pel=1, then idx doesn't offer a speedup). So you have one idx for MV with source, and another idx for MV on NR1.

Nikos

18th February 2008, 20:25

Thank you foxyshadis for the explain.
With simple words the right script is the 2 with idx=2.
2.
source=last
b1_vec = source.MVAnalyse(isb = true, delta = 1, blksize =8, overlap = 4, pel = 2, sharp = 2, idx = 1)
f1_vec = source.MVAnalyse(isb = false, delta = 1, blksize =8, overlap = 4, pel = 2, sharp = 2, idx = 1)

NR1=source.MVDegrain1(b1_vec, f1_vec, thSAD = 400, idx = 1)
NRb=NR1.MVDegrain1(b1_vec, f1_vec, thSAD= 400, idx = 2)

thetoof

19th February 2008, 07:37

@ Didée

From what you said... I guess/hope you'll rewrite the script to correct everything and I was wondering if you could add (or simply explain how to do it) a function to use dfttest and fft3dfilter at the same time. Maybe it's just a bad idea to use 2 denoisers... but the source I have requires additional chroma denoise with specific s2/3/4 values with fft3d to be clean.

I tweaked the parameters of dfttest in the TemporalDegrain.avsi and I got pretty good results, but couldn't find a way to add fft3d... hope you'll be willing to help me.

archaeo

25th February 2008, 00:16

Just tried sagekilla's TemporalDegrain() on a very grainy old film transfer: "I am a Fugitive from a Chain Gang" (1932), and I am very impressed with the results (See attachments). The grain on the original transfer was extremely heavy, and other degrain combinations never got close to the results I got with TD... Slow...YES, (even with an E6700, I only got about 2 fps) but well worth the wait.
I have also tried this on a couple of other older films, with similar results - grain virtually gone, but excellent detail retention. Very nice script!

I only wish there was a way to speed it up a bit with MT :(

Original clip: http://www.mediafire.com/?mi11znznz3r
TD clip: http://www.mediafire.com/?its3m3z9yud

stills:

8141

8142

Nikos

28th February 2008, 02:01

I read an old Didee's post in another forum and i replace the prefilter with this:

soft = hqdn3d(source).bicubicresize(source.width/4/4*4,source.height/4/4*4).bicubicresize(source.width,source.height,1,0)
filter=mt_lutxy( source, soft, "x y = x x x y - abs 1 + 1 2 / ^ x y - x y - abs / * - ?", U=2, V=2 )

The different in rendering speed was respectable, +40% with overlap=4, and +70% with overlap=2.
I use MVDegrain2 and MT(2,2).
The quality in my eyes was the same, but i want an opinion from experienced user.

Any idea for another correct "spat" filter?

Didee help us :)

Didée

28th February 2008, 08:42

Several issues.

1) The string in lutxy is wrong. That syntax was for YV12lutxy() of old MaskTools v1.
For mt_Lutxy of MaskTools v2, the string has to be "x y == ..." (TWO equal signs. Try to retun "filter" with your current syntax, you'll immediately see that something's wrong.)

2) With that order of filters, you're actually nullifying the effect of HQDN3D. In this case, the more reasonable ordering is
soft = source.bicubicresize(source.width/4/4*4,source.height/4/4*4).bicubicresize(source.width,source.height,1,0)
filter=mt_lutxy( source, soft, "x y == x x x y - abs 1 + 1 2 / ^ x y - x y - abs / * - ?", U=2, V=2 ).hqdn3d()

3) Whether pre-denoising is needed at all depends on the stronginess of grain. I see slight danger that this sort of processing now gets thrown at all kind of sources, even those that don't need such a processing method.

4) That combo is a very speedy trick-filter. It might work out for the most part, but there'll be cases where it bites you back. Dumb filters can destroy the motion of rather smooth regions (e.g. close-up of smooth faces + head-movement) strong enough so that MVTools won't reckognize motion anymore.
BTW, HQDN3D is generally not fully safe in this respect.

4) We have about one thousand different denoising filters or -scripts. If source has strong grain, the pre-filtering should be barely strong enough to make static areas calm.
Which filter that is or could be, depends on the source. If you're going to ask about all thousand possibilities, this thread will become long. ;)

Nikos

28th February 2008, 14:52

Thanks Didée for the correction. That syntax was for YV12lutxy(). The reverse polish notation is a little difficult. What's the different beetween the "==" and "="? These days i read your old post to find out solutions for my problems :)
If you want translate in simple maths the function.

I need a speedy prefilter whith acceptable (not high) quality with for High Definition sources with moderate or low noise. The prefilter must be spatial, temporal, or spatiotemporal; I must put the spatial first or the temporal;

The FFT3DGPU is suitable for prefilter?
It's a good idea to write a "magic" script for prefilter in MVDegrain with options for heavy, medium or light denoise :)

Any help.....

Didée

28th February 2008, 16:35

"=" is an assignment, whereas "==" means "is equal to" in logical expressions.

a = 3 # assign the value "3" to the variable "a"

a == 4 # this is "TRUE" if "a" has the value "4", and is "FALSE" if "a" has ar value other than "4".

The syntax used by MaskTools v1 ever was wrong in that respect. MaskTools v2 now has it correct.

The reverse polish notation is a little difficult. No, not really. It's just a matter of practice.

"x y == x x x y - abs 1 + 1 2 / ^ x y - x y - abs / * - ?"

reads in english

IF (x is equal to y)
THEN (use x)
ELSE (apply the square root of (difference between x and y, plus 1) to x)

I need a speedy prefilter whith acceptable (not high) quality with for High Definition sources with moderate or low noise.
For low noise you need exactly no prefiltering at all. Use MVDegrainX directly as stated in MVTools' documentation.

The FFT3DGPU is suitable for prefilter?
When asking questions where the only objective answer is "there is no objective answer", it won't get better if you guys keep asking over and over again.

Nikos

28th February 2008, 17:09

Now with your help i begin to understand the mask tool and the Reverse Polish notation.
Now i am going for practice. I will be back soon with more serious questions :)

Thanks for your time to answer my questions.

jeffy

28th February 2008, 19:23

"x y == x x x y - abs 1 + 1 2 / ^ x y - x y - abs / * - ?"

reads in english

IF (x is equal to y)
THEN (use x)
ELSE (apply the square root of (difference between x and y, plus 1) to x)

Didée, could you please rewrite the lime part in a normal (infix) notation? Thank you.

Didée

28th February 2008, 21:01

In infix notation it is

(x == y) ? x : x - ( sqrt( abs( x - y ) + 1 ) * ( x - y ) / abs( x - y ) )

That's very basic math. Everyone once has used something like

clip1 = last
clip2 = clip1.blur(1)
result = clip1 .merge( clip2, 0.4 )

What is this? It is: apply a filter to your source (here: blur filter), but use only 40% of the result. (Or the resulting effekt). That's trivial, isn't it?

From a slightly different angle, it is this: calculate something, but instead of just using the resulting difference, multiply the difference by 0.4 before using it. That's a linear function: F(diff) = diff * p

Now, what the initial code does is just this: instead of using a linear function to reduce the effect, it uses a square root function: F(diff) = sqrt(diff)

That's all, and hardly worth all the babbling. :)

Lorax2161

28th February 2008, 22:48

Actually, thank you for "babbling." Not everyone is at the same level, and I learned some things from it. A good explanation goes a long way to helping people open doors they thought were locked.

BTW, to further on what archaeo said, I ran TemporalDegrain() on a somewhat noisy cable tv capture and the results were stunning. (I didn't know how noisy it was until after it was cleaned.) I only get 1.8fps on my dual core machine, but I haven't seen anything at any speed that comes close to that quality, especially true if I follow it with LSF. So to you and sagekilla I say thanks.

Nikos

28th February 2008, 22:48

To help a little.
( x - y ) / abs( x - y ) = sign(x-y)

In masktools Round(1.5)=? and Round(-1.5)=?
I suppose 2 and -1, but i am not sure.

Terranigma

28th February 2008, 23:22

I think you guys may want to split this thread into a new one, because it's now getting way offtopic :)

NathanX

3rd March 2008, 10:22

Please don't use my FastDegrain -- It's currently b0rked. Also, Sasovics please don't cross post.

Your FastDegrain scripts sounds interesting to me, is it still in development?
Thank you!

ChrisW77

3rd March 2008, 15:55

Sagekilla, Thats one amazing script that works extremely well on SD material, and heck, even on old VHS it does wonders.

So thanks to both you and Didee :)

I'm currently using Temporal Degrain V1.18 (Feb 14, 2008), but cannot seem to get any joy from MT, CPU doesn't go above 60% usage, no matter where I put SetMTmode(2) in a simple script.

For instance

SetMemoryMax(512)
LoadPlugin("C:\Program Files\AviSynth\plugins\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth\plugins\mpasource.dll")
Import("C:\Program Files\AviSynth\plugins\TemporalDegrain2.avs")

SetMTmode(2)
video = mpeg2source("D:\DVB-T\test1.d2v", cpu=4, iPP=true, idct=3)
audio = MPASource("D:\DVB-T\test1 T01 DELAY 0ms.mpa", normalize = false)
AudioDub(video, audio)
ConvertToYV12(interlaced=true)

AssumeTFF()
SeparateFields()
TemporalDegrain()
Weave()
Crop(8,8,-8,-8,align=true).Addborders(8,8,8,8)

This is just a simple DVB-T capture test, keeping interlaced full frame, and on my Core2duo E6300 I get around 3 fps with or without SetMTmode(2).

One thing I have tried, as I have a powerful GPU (8800GT), that gained me 13fps from 3fps to 16fps with out any perceived loss in quality, is to modify your function as follows

Change all FFT3D entries to FFT3dGPU, changing BT=5 to BT=4, as the GPU version doesn't support 5, and blksize from 8 to 16. Huge speedup, and I couldn't see any difference in quality.

Many thanks for this function, it's amazing. :D

archaeo

3rd March 2008, 19:09

I'm currently using Temporal Degrain V1.18 (Feb 14, 2008), but cannot seem to get any joy from MT, CPU doesn't go above 60% usage, no matter where I put SetMTmode(2) in a simple script.

Try MT("TemporalDegrain()").
It worked well for me - I am seeing 90% plus usage on my Core2

Boulder

3rd March 2008, 19:20

I wonder if MVAnalyse/MVDegrain plays nice with MT..nobody ever tested it IIRC.

ChrisW77

3rd March 2008, 20:17

Try MT("TemporalDegrain()").
It worked well for me - I am seeing 90% plus usage on my Core2

Thanks, I'll give that a try.

Terranigma

3rd March 2008, 20:21

I wonder if MVAnalyse/MVDegrain plays nice with MT..nobody ever tested it IIRC.

I don't know what this (http://forum.doom9.org/showthread.php?p=1056510#post1056510) is exactly, but I stumbled across it in the MT thread. :P

maxisvk

3rd March 2008, 20:44

Thanks, I'll give that a try.

This is my test on Core 2 Duo with TemporalDegrain()
SetMTMode(2,0) , 50% Cpu
SetMTMode(2,3) , 65% Cpu
SetMTMode(2,4) , 90/100% Cpu

on Q6600 is the same, only if i use SetMTMode(2,8) it work at 100%

ChrisW77

3rd March 2008, 21:01

SetMTMode(2,4) , 90/100% Cpu

Yes, yes, now that worked well, getting 95% continuous. Cheers :) Never thought of using 4 threads.

A strange thing I found with MVTools was this

SetMemoryMax(512)
LoadPlugin("C:\Program Files\AviSynth\plugins\RemoveGrainSSE2.dll")
LoadPlugin("C:\Program Files\AviSynth\plugins\MVTools.dll")
LoadPlugin("C:\Program Files\AviSynth\plugins\DeGrainMedian.dll")
LoadPlugin("C:\Program Files\AviSynth\plugins\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth\plugins\mpasource.dll")

SetMTmode(2)
video = mpeg2source("D:\VHS\90sadverts.d2v", cpu=6, iPP=true, idct=3)
audio = MPASource("D:\VHS\90sadverts T01 DELAY 0ms.mpa.d2a", normalize = false)
AudioDub(video, audio)

source=ConvertToYV12(interlaced=true).Crop(10,4,-10,-10,align=true).Addborders(10,7,10,7)
fields=source.AssumeTFF().SeparateFields().DeGrainMedian(mode=0,interlaced=false).RemoveGrain(mode=2)

lbda=512
blk=16
ol=8
sch=2
pel=1

backward_vec2 = fields.MVAnalyse(isb=true, search=sch, truemotion=true, lambda=lbda, delta=2, pel=pel, blksize=blk, overlap=ol, sharp=1, idx=1)
backward_vec1 = fields.MVAnalyse(isb=true, search=sch, truemotion=true, lambda=lbda, delta=1, pel=pel, blksize=blk, overlap=ol, sharp=1, idx=1)
forward_vec1 = fields.MVAnalyse(isb=false, search=sch, truemotion=true, lambda=lbda, delta=1, pel=pel, blksize=blk, overlap=ol, sharp=1, idx=1)
forward_vec2 = fields.MVAnalyse(isb=false, search=sch, truemotion=true, lambda=lbda, delta=2, pel=pel, blksize=blk, overlap=ol, sharp=1, idx=1)
fields.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=800,idx=1).MVDenoise(backward_vec2,backward_vec1,forward_vec1,forward_vec2,tht=10,thSAD=800)
Weave()

That script ran well and fast, constantly at 100%, until it finished. Yet, add anything after weave, such as LimitedSharpenFaster, or even Tweak, and it kind of broke MT, and you were left with a script running 55%.

Cheers to maxisvk, that worked well.
Next, to look at a cheap quad core upgrade :D

Didée

3rd March 2008, 21:13

That script ran well and fast, constantly at 100%, ...
... and the result was 100% garbage.

source=ConvertToYV12(interlaced=true).Crop(...).Addborders(10,7,10,7)
Progressive YV12 shouldn't be cropped or add-border'ed by odd numbers vertically .
For interlaced YV12, that is MUST NOT. Never, never, never ever. If you do, you're changing chroma phase, i.e. luma and chroma are no more temporally aligned.

ChrisW77

3rd March 2008, 21:41

... and the result was 100% garbage.

Looked good enough to MY eyes ;)

Progressive YV12 shouldn't be cropped or add-border'ed by odd numbers vertically .
For interlaced YV12, that is MUST NOT. Never, never, never ever. If you do, you're changing chroma phase, i.e. luma and chroma are no more temporally aligned.

Then suggest something then, rather than just spouting off one.
How would one, by Didee's standards, crop off the shite on a Interlaced VHS cap.
I'm listening, o Great one :D

thetoof

4th March 2008, 08:10

Basic rule of MT : Look at the time it takes, not the CPU usage!
Also, I think setmtmode(2) for MVtools would be better since:
1- In the guide, there is this info: # Note: SetMTMode(2) mode of multithreaded AviSynth is also supported since MVTools v.1.8.4.1 (beta testing)
2-MT("filter()") splits the frames in multiple parts (depending on the # of threads)... and unless you use a HUGE overlap, the motion vectors won't be as accurate as if you had used the complete frame (which is done by setmtmode(2))

If you didn't know, setmtmode(2) separates the frames temporally (so it's always the complete frame that is processed), while MT() separates them spatially.

maxisvk

4th March 2008, 13:43

Basic rule of MT : Look at the time it takes, not the CPU usage!

ok, obviously, but in my test:

SetMTMode(2,0) , 50% Cpu
-> encoded 120 frames, 1.61 fps, 855.64 kb/s

SetMTMode(2,3) , 65% Cpu
-> encoded 120 frames, 1.64 fps, 855.64 kb/s

SetMTMode(2,4) , 90/100% Cpu
-> encoded 120 frames, 2.15 fps, 855.64 kb/s

i also noticed that using only Mvdegrain and not TemporalDegrain best result are stuck with SetMTMode(2,3), Why?..., I really did not know!

thetoof

4th March 2008, 22:35

Because Temporaldegrain uses a predenoised reference clip for motion vector search... so it takes more computer ressources and it's very possible your hard drive disk can't handle the high number of reads and writes. That's why there's a peak with speed. You can "solve" that by doing the reference clip yourself with FFT3Dfilter.

If you only want to denoise, use this:

1 - Create a simple script to create your reference clip, it doesn't really matter if you lose some details and it looks a tad overdenoise since it's only a clip used for motion vector search:

whateversource("yoursource")
FFT3DFilter(your favorite parameters... check the documentation for more info)

2 - Process through Direct Stream Copy in virtualdubmod. If you have another HDD, save it on this one. The file'll be HUGE.

3 - create another script with temporaldegrain using the source clip that is on the other HDD

source = whateversource("youroriginalclip")
denoised = avisource("thereferenceclip")
temporaldegrain(source, denoised)

About your speedtest... it's OBVIOUS that using more threads will increase the speed. SetMTmode(2) is always the best choice since it'll set the number of threads to the # of available processors.

When I say to look at speed instead of CPU usage, it's with the same # of CPUs. The thing is, when you have a more complex script, MT may not help (I have a script that runs @ 1fpm with 750MB of RAM and 25% CPU usage (100% of 1 processor on my Quad-core) and it's a LOT slower with MT and uses 3GB of RAM).

foxyshadis

5th March 2008, 07:32

Eh, no matter how slow a script is, writing part of it to disk and reading it back will always be slower. Whether you're going to make another lossless encode from the final output, or use it in a one-pass encoding, by the time you're done you'll have put much more effort into it and it will have taken longer overall. Memory overflow and disk swapping is about the only way that partial scripting can be faster. TemporalDegrain can't even remotely cause a hard drive bottleneck anyway, even with uncompressed sources it takes about a hundred times as long to filter as read.

On the other hand, if you have a second computer handy, running fft3dfilter on that and using TCPSource can really speed things up, as long as the second computer's fast enough to keep up.

I'd also say that your conclusion that SetMTmode(2) is best is mistaken; after all, you just said more threads was faster, and speed is all that matters, as long as the final encoder's thread is included rather than just the avisynth script measured. In some scripts 4 threads will be faster, others 1, though I suppose yours might be swapping like crazy once it gets there. Always measure though, never take a forum poster's word. :p

thetoof

5th March 2008, 08:39

Oh well, seems like I was lucky on my first try using the method I described before... I ran some other tests to show how effective it was, but everything I got looked like crap.
Dunno why it worked once (and there were actually great speed improvement by outputting the reference clip on another HDD and then call it in the script using temporalgrain as "denoise", from 53 mins total (complete script) to 13 mins total (split script) for the same amount of frames) and I'm sorry for posting it before running more tests... but heh, I'm learning!

Also, about my statement regarding setmtmode(2), I had in mind that it was regarding MVtools usage (and from what I understood from its documentation, it's the most appropriate mode). My bad for not being clear.

Zep

6th March 2008, 20:46

Eh, no matter how slow a script is, writing part of it to disk and reading it back will always be slower. Whether you're going to make another lossless encode from the final output, or use it in a one-pass encoding, by the time you're done you'll have put much more effort into it and it will have taken longer overall. Memory overflow and disk swapping is about the only way that partial scripting can be faster. TemporalDegrain can't even remotely cause a hard drive bottleneck anyway, even with uncompressed sources it takes about a hundred times as long to filter as read.

yup 1 pass encodes it would not help but 2 pass encoding is much faster when I do twriteavi() on the first pass of slow encode due to scripts like the stuff in this thread.

If you are only getting 2 FPS like me you for sure want to save out a lossless during the first pass else you are stuck doing it all again on the second pass. resize, decimation, MVtools, fft3dfilter, etc... I go from 2 FPS on the first pass to 14 FPS on the second pass and this is now with the real encoding being done also. (it would be only about .75 FPS on pass 2 if I didn't do this) huge time savings on 2 pass encodes.

no I would not do it like thetoof did it since you want the lossless (I use VBLE cause it is fast and thus little CPU overhead) made the same time as first pass stats are being made :)

g-force

7th March 2008, 07:49

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!

# GTemporalDegrainFaster ver.1.00 6MAR08
# Function by G-force,"Limited" Concept by Didee
# Requires FFT3DFilter.dll, mt_masktools, MVtools.dll, RemoveGrain.dll

function GTemporalDegrainFaster (clip input,int "threads",int "sigma")
{
source = input
ncpu = default(threads,1) #max number of CPU threads to use in FFT calculation (int>0, default=1)
sigma = default(sigma, 16) #turn down for more limited denoising
s2 = floor (sigma * 0.625)
s3 = floor (sigma * 0.375)
s4 = floor (sigma * 0.250)

filter = source.fft3dfilter(ncpu=ncpu,sigma=sigma,sigma2=s2,sigma3=s3,sigma4=s4,bt=5,bw=16,bh=16,ow=8,oh=8)
filterD = mt_makediff(source,filter)

backward_vec1= filter.MVAnalyse(isb=true, delta=1,pel=2,overlap=4,sharp=1,idx=1)
forward_vec1 = filter.MVAnalyse(isb=false,delta=1,pel=2,overlap=4,sharp=1,idx=1)
bw1 = source.MVCompensate(backward_vec1,idx = 2) #idx = 2 since working on a different clip than MVAnalyse
fw1 = source.MVCompensate(forward_vec1, idx = 2)

#nice thing about this approach is that it doesn't necessarily use any pixels from current frame
#this gets rid of a lot more dirt, scratches etc. (things that last only one frame)
nr = Interleave(bw1,source,fw1).Clense().SelectEvery(3,1)

# Limit "nr" to not do more than what "filter" would do. -Didee
nrD = mt_makediff(source,nr)
DD = mt_lutxy(filterD,nrD,"x 128 - abs y 128 - abs < x y ?")
source.mt_makediff(DD,U=2,V=2)

output = last
return(output)
}

-G

Didée

8th March 2008, 20:43

... and the result was 100% garbage.
Looked good enough to MY eyes ;)

I don't know your eyes, so I can't tell what seems good enough to them and what not.

With your sequence of crop+addborders, this is what happens to an interlaced YV12 source:

http://img401.imageshack.us/img401/5262/yv12iwrongua9.th.png (http://img401.imageshack.us/my.php?image=yv12iwrongua9.png)

In contrast, with correct treatment you get:

http://img401.imageshack.us/img401/967/yv12icorrectkt7.th.png (http://img401.imageshack.us/my.php?image=yv12icorrectkt7.png)

Then suggest something then, rather than just spouting off one.
How would one, by Didee's standards, crop off the shite on a Interlaced VHS cap.
I'm listening, o Great one :D

It's a basic technical requirement that the top border of interlaced YV12i may only be altered in mod4 steps.
This has nothing-at-all to do with "my standards".

-----

Generating script: (yeah, it's not elegant):p

base = blankclip(width=704,height=576,pixel_type="YV12",fps=50.000,color=$408080)

base = base.subtitle("This is some scrolling text ...",size=40,x=128,y=480)

interleave( base, base.crop(0,16*1,-0,-0).addborders(0,0,0,16*1,color=$408080),
\ base.crop(0,16*2,-0,-0).addborders(0,0,0,16*2,color=$408080),
\ base.crop(0,16*3,-0,-0).addborders(0,0,0,16*3,color=$408080),
\ base.crop(0,16*4,-0,-0).addborders(0,0,0,16*4,color=$408080),
\ base.crop(0,16*5,-0,-0).addborders(0,0,0,16*5,color=$408080),
\ base.crop(0,16*6,-0,-0).addborders(0,0,0,16*6,color=$408080),
\ base.crop(0,16*7,-0,-0).addborders(0,0,0,16*7,color=$408080),
\ base.crop(0,16*8,-0,-0).addborders(0,0,0,16*8,color=$408080),
\ base.crop(0,16*9,-0,-0).addborders(0,0,0,16*9,color=$408080),
\ base.crop(0,16*10,-0,-0).addborders(0,0,0,16*10,color=$408080),
\ base.crop(0,16*11,-0,-0).addborders(0,0,0,16*11,color=$408080),
\ base.crop(0,16*12,-0,-0).addborders(0,0,0,16*12,color=$408080),
\ base.crop(0,16*13,-0,-0).addborders(0,0,0,16*13,color=$408080),
\ base.crop(0,16*14,-0,-0).addborders(0,0,0,16*14,color=$408080),
\ base.crop(0,16*15,-0,-0).addborders(0,0,0,16*15,color=$408080) )

vid_50p = last

vid_50i = assumeTFF().SeparateFields().SelectEvery(4,0,3).Weave()

# the wrong way:
#---------------
vid_50i
crop(0,4,-0,-10)
addborders(0,7,0,7)

wrong = last

# the better way:
#---------------
vid_50i
crop(0,4,-0,-12)
addborders(0,8,0,8)

better = last

result_wrong = stackhorizontal( wrong.subtitle("interlaced after non-MOD4 cropping or addborders",y=20),
\ stackvertical( wrong.SeparateFields().selecteven().subtitle("--> top field",y=20),
\ wrong.SeparateFields().SelectOdd().Subtitle("--> bottom field",y=20) ) )

result_better = stackhorizontal( better.subtitle("interlaced after correct (MOD4) cropping or addborders",y=20),
\ stackvertical(better.SeparateFields().selecteven().subtitle("--> top field",y=20),
\ better.SeparateFields().SelectOdd().Subtitle("--> bottom field",y=20) ) )

result_wrong
#result_better

return( last )

ChrisW77

8th March 2008, 23:10

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

9th March 2008, 20:27

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

10th March 2008, 17:51

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

21st April 2008, 23:55

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

22nd April 2008, 12:06

@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

22nd April 2008, 14:13

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

23rd April 2008, 12:14

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

23rd April 2008, 15:09

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

30th April 2008, 07:21

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

11th October 2009, 07:46

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

11th October 2009, 15:00

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

11th October 2009, 19:30

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

26th June 2010, 17:45

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

26th June 2010, 20:38

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

26th June 2010, 22:22

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

13th January 2011, 15:56

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

13th January 2011, 16:36

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

14th January 2011, 08:13

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

14th January 2011, 13:30

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

14th January 2011, 14:08

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

16th January 2011, 16:48

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

16th January 2011, 17:28

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

16th January 2011, 17:45

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

16th January 2011, 18:25

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

17th January 2011, 19:24

Please port that AVS to x64 aware version ;)

Didée

17th January 2011, 19:47

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

SilaSurfer

19th January 2011, 13:20

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

19th January 2011, 14:01

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

19th January 2011, 14:17

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

19th January 2011, 14:46

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

19th January 2011, 15:03

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

SilaSurfer

23rd January 2011, 17:37

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

24th January 2011, 21:42

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

24th January 2011, 22:09

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

24th January 2011, 22:17

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

25th January 2011, 14:55

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

25th January 2011, 15:49

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)
}