Need Suggestions for VERY GRAINY source

[Zep]

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]

file not avaiable

BHH

[DeathAngelBR]

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]

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]

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]

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]

file not avaiable

BHH

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


hmmm...

[Zep]

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.


I will give that a go thanks!

[Zep]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[Pookie]

"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]

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]

@ 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]

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


download the original clip it is in a link above

[Zep]

@ 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]

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]

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]

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]

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]

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]

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]

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

[Sagekilla]

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]

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

[Zep]

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]

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]

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]

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.

[Sagekilla]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

In the case of 300 though, us DVD users pretty much get screwed over considering how poor our source quality is to begin with. Oh, what I would do for a Blu-ray player for my computer..

[Pookie]

Looks like Kassandro has chimed in on this topic-

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

[Didée]

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]

[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]

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]

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]

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]

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]

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]

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]

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.

[Terranigma]

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]

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]

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]

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]

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]

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]

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

[Didée]

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]

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.

What really annoys me is that they ADDED the grain in post production on purpose. The I-MAX version has NO GRAIN.

[Sagekilla]

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]

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]

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]

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]

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]

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]

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]

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]

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]



I'm downloading the example now. Will check it out shortly.

Please delete some stuff in your inbox so I can reply to your PM.
I wrote back but am unable to send it to you as I get a "Can not send inbox is full error" :)

note I did not temporal really. mine was spatial removable mostly.

the single frames look good though that you did now to see if
the dancing is gone :P

[Zep]

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]

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]

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]

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]

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]

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]

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

[Zep]

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]

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]

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]

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]

@ 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]

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]

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]

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]

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.

[Sagekilla]

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]

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]

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?

[Zep]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Sagekilla]

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]

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]

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

[Sagekilla]

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]

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]

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]

@ 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]

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


Without corrected weightings, it will denoise less, not more. (Unless you split the idx'es, then it will denoise more indeed.)
---

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

Oh ok, so I did another test , and now I see what you mean.

MVDeGrain2:
http://img206.imageshack.us/img206/2051/mvd2origlr5.png

MVDegrain1 x 2:
http://img258.imageshack.us/img258/6622/mvd2nc4.png

The small nuances between the 2 must be what you mean by rounding differences. :)

[Didée]

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

[Terranigma]

@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]

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]

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]

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

[Terranigma]

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]

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]

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

[Zep]

@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]

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.



Didée have you compared frames from the MVdedrain3 to this scripted version? I ask because at least here on my LCD the scripted version is not as sharp and seems to have slightly less detail. Perhaps TTempSmooth is the cause? I'll mess with TTempSmooth settings to tomorrow it is late and I need sleep.

The good news is none of the MVdegrain3 missed areas you showed later on in this thread so I like the scripted version better over all I just want to tweak it a little so that TTempSmooth is not so strong (I think TTempSmooth . like I said willl mess with it tomorrow)


Thanks

Zep

[ankurs]

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]

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]

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]

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

[ankurs]

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]

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]

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

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

[Sagekilla]

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.

[jokin]

@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]

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]

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]

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]

^

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]

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]

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

[Terranigma]

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]

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]

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]

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

[Didée]

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]

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]

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]

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]

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]

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]

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]

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]

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]

That little script doesnt load.

[Didée]

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]

What versions of Masktools and MVtools do you have?

[Sagekilla]

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.

Fixed everything, thanks for that Didee. Very bad with syntax today it seems.

[Dreassica]

Still getting a syntax error from that line.

[Didée]

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

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

would seem logical.

[Sagekilla]

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]

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]

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

[Sagekilla]

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]

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

[Boulder]

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

[Dreassica]

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

[Sagekilla]

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]

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)

[Sagekilla]

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]

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

[Sagekilla]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Adub]

@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]

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]

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]

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]

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

[Sagekilla]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Zanejin]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

ColorSpace is YV12

[Sagekilla]

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]

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]

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]

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]

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]

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]

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]

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]

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

[thetoof]

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]

@ 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]

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]

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]

Just out of curiosity, were you using MT?

[Sasovics]

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]

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]

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

Thanks in advance!

[Sagekilla]

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]

Want me to add it to the wiki?

[Sasovics]

Where do I get the LimitedSharpenFaster.avs script ?

[Adub]

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

[Sagekilla]

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.