Need Suggestions for VERY GRAINY source

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