PDA

View Full Version : Recommendations for cleaning this TV capture


Boulder
12th January 2006, 07:16
Hi there. Recently I've been trying to find a good denoiser for my TV captures. My problem is that after encoding for DVD usage, flat areas tend to have swimming blocks, which can sometimes be really annoying. Then again, it's way too easy to oversmooth everything for example with FFT3DFilter. Avg bitrates are around 3500-4000kbps, I've tried different low and high bitrate matrices as well without any better results

What I've mostly used is the LRemoveDust(17,x) x=1-3 and FFT3DGPU(plane=1,sigma=3) combo but this still leaves the swimming blocks problem.

Here's a short sample in ffdshow MJPEG (~13MB), the noise you see is very common on all the analog channels : http://rapidshare.de/files/10889783/menbehavingbadly.avi.html

Does anybody have any recommendations? I'd like to try the LTSMC framework version but as Didée says it's not nearly ready, I'd rather not bother yet.

Revgen
12th January 2006, 08:40
Although I've never tried it...Have you ever tried MVDenoise or other MVTools based denoisers?

It might be useful for this since the noise seems to be related to bad frequencies and not grain or dirt.

Boulder
12th January 2006, 09:52
Not yet.. I was thinking about experimenting with DeFreq but I've never managed to get the settings correct.

It does look like interference noise for which DeFreq and similar filters should be able to fix.

BruceL
12th January 2006, 12:34
I have been using a combination of DeFreq and VagueDenoiser lately with good results. Took me a while to get Defreq adjusted and understood (I think :D ). Been meaning to experiment with Didée's sharpening scripts, but have not had time. I'll post my script if you like.

Boulder
12th January 2006, 12:49
Sure, go ahead. There's always something new to learn :)

BruceL
12th January 2006, 13:29
Here you go.
I usually have to play around with window sizes and positions for Defreq and threshold for VagueDenoiser. Occasionally have two instances of Defreq if the four windows are not enough.
Hope this helps. :)

#Capture AVS
#
# PLUGINS
#LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\plugin.dll")
#
# SOURCE
AVISource("H:\AVI_Capture\Capture\Capture.avi")
assumetff()
Tdeint(mode=1)
DeFreq(fx=18, fy=23, dx=1.5, dy=6, Sharp=-100, fx2=18, fy2=-78, dx2=1.5, dy2=6, sharp2=-100, fx3=79, fy3=34, dx3=10, dy3=3, sharp3=-100, fx4=77.5, fy4=-66, dx4=9, dy4=3, sharp4=-100, Show=false, Info=false)
VagueDenoiser(threshold=3,method=1,nsteps=6,chromaT=0.8,interlaced=false)
#VagueDenoiser(threshold=0.8,method=1,nsteps=6,chromaT=0.8,interlaced=false)
assumetff() #set the fieldorder again (the same as above!)
separatefields()
selectevery(4,0,3)
weave()
#info()

Didée
12th January 2006, 13:48
Perhaps give a try on MCNR_simple (http://forum.doom9.org/showthread.php?p=752196#post752196).

Without any tweaking (mustnot do that now...), a straightforward bob + MCNR + reinterlace gives

http://img68.imageshack.us/img68/3853/mcnr2boulder0xx.th.png (http://img68.imageshack.us/my.php?image=mcnr2boulder0xx.png)

Filter settings were MCNR_simple2(frames=3,removdirt=true,LPrad=2.0). (Perhaps it might need some slight additional stabilisation for static parts, can't check that from your sample.)

This is *very* slow (MC denoising on a bobbed! clip) ... but then, directly deinterlacing such a noisy source is problematic, too.

BTW, swimming blocks is what you get when
a) noise is not removed, but only reduced, /and/
b) the noise is not "sharp", but soft instead (sharp noise is cancelled much more easily, whereas "soft" noise due to its low-frequency characteristics very easily gets misinterpreted as "motion")

xara
12th January 2006, 14:01
I couldnt download the sample, but talking about "swimming blocks" reminds me a issue times ago.

I get a solution setting the "Backlight Comp" to ZERO (0) in the menu source of my TV capture software. I'm in a PAL land, if this helps, with a S-Video input.

Hope this help you too, because the post processing solution is very hard and time consuming.

EDIT: If your "swimming blocks" are those in the Didee sample, then I'm talking about another thing.

Boulder
12th January 2006, 14:05
Thank you, everyone, I shall give all those suggestions a go as soon as time permits playing with the video :)

Boulder
12th January 2006, 14:14
Hm, could someone upload a working version of Fizick's MVTools somewhere? It seems that he's removed all the versions from his webspace.

Didée
12th January 2006, 14:39
Hmm ... Makes me think about deleting my posted functions & references ... anyone remembering the "Bach effect" ?

Every now and then, look into my online stuff (http://home.arcor.de/dhanselmann/_stuff/) directory. (Small, isn't it?)

Boulder
12th January 2006, 14:45
Hmm ... Makes me think about deleting my posted functions & references ... anyone remembering the "Bach effect" ?

Was it poor Wilbert who had to reconstruct several discussions because of that?

Every now and then, look into my online stuff (http://home.arcor.de/dhanselmann/_stuff/) directory. (Small, isn't it?)
Thanks, should have remembered it;)

Chainmax
12th January 2006, 15:26
Boulder: nothing too constructive to add here other than recommend you not to use LRemoveDust. I use the YUY2/YV12 version you posted a while ago and after many tests I feel like it does remove almost all noise, but wipes out too much detail (even for animated content). I'd recommend strong DeGranMedian, FFT3DFilter or VagueDenoise settings instead.

Boulder
12th January 2006, 15:39
Didée's function seems to work very well and it isn't too slow for 30-min episodes:)

I just can't convert it properly for MaskTools 2.0a usage. These two spots don't work:

function LPprotect( clip NR, clip orig, float rad, int low, int high )
{
ox = NR.width()
oy = NR.height()
HI = string(256.0/high)
LO = string(256.0/high*low)
ML = string(float(high)/(float(high)-low))
diff = yv12lutxy(orig,NR,"x y - 128 +","y","y",U=3,V=3)
diffLP = repair(diff,diff.removegrain(4,-1).bicubicresize(m4(ox/rad),m4(oy/rad)).bicubicresize(ox,oy,1,0),1,0)
diff = mt_lutxy(diff,diffLP,"x 128 - y 128 - * 0 < 128 x y 128 - - ?",U=2,V=2)
MyMoMask = logic( mt_lutxy(NR,NR.deleteframe(0), "x y - abs "+HI+" * "+LO+" - "+ML+" *"),
\ mt_lutxy(NR,NR.duplicateframe(0),"x y - abs "+HI+" * "+LO+" - "+ML+" *"), "max")
mt_merge(NR,yv12lutxy(orig,diff,"x y 128 - -","y","y",U=3,V=3),MyMoMask.fity2uv(),U=3,V=3)
#MyMoMask.greyscale
return( last )
}

The first one makes chroma artifacts and the second one looks like some sort of motion map or something like that when yv12lutxy is replaced by mt_lutxy.

Didée
12th January 2006, 16:05
Try using "full" syntax - if not explicitely assigned with Y/U/Vexpr="..", mt_lut/xy takes the first string as default for all three planes.
function LPprotect( clip NR, clip orig, float rad, int low, int high )
{
ox = NR.width()
oy = NR.height()
HI = string(256.0/high)
LO = string(256.0/high*low)
ML = string(float(high)/(float(high)-low))
diff = mt_lutxy(orig,NR,yexpr="x y - 128 +",uexpr="y",vexpr="y",Y=3,U=3,V=3)
diffLP = repair(diff,diff.removegrain(4,-1).bicubicresize(m4(ox/rad),m4(oy/rad)).bicubicresize(ox,oy,1,0),1,0)
diff = mt_lutxy(diff,diffLP,yexpr="x 128 - y 128 - * 0 < 128 x y 128 - - ?",uexpr="x",vexpr="x",Y=3,U=2,V=2)
MyMoMask = mt_logic( mt_lutxy(NR,NR.deleteframe(0), "x y - abs "+HI+" * "+LO+" - "+ML+" *"),
\ mt_lutxy(NR,NR.duplicateframe(0),"x y - abs "+HI+" * "+LO+" - "+ML+" *"), "max",Y=3,U=1,V=1)
mt_merge(NR,mt_lutxy(orig,diff,yexpr="x y 128 - -",uexpr="y",vexpr="y",Y=3,U=3,V=3),MyMoMask.fity2uv(),Y=3,U=3,V=3)
#MyMoMask.greyscale
return( last )
}

Note: just typed, not tested ... may contain nuts. (And you still have to load old Masktools 1.5.x, because of FitY2UV() ;) )

Edit: Oh, and this is one more case where Clouded's LimitedSupport.dll would fit *perfectly* ... :o

Boulder
12th January 2006, 16:57
Edit: Oh, and this is one more case where Clouded's LimitedSupport.dll would fit *perfectly* ... :o
Who oh who might do something about it?

:D

Richard Berg
12th January 2006, 19:13
FFT3DGPU(plane=1,sigma=3)
You know that this is only processing the U plane, right?

mg262
12th January 2006, 19:22
Boulder,

I am an awful awful scripter and make lots of careless slips. But it looks to me like this:

diff = mt_lutxy(orig,NR,yexpr="x y - 128 +",uexpr="y",vexpr="y",Y=3,U=3,V=3)

Could be replaced by

diff = AddDiff(orig, NR, chroma = "copy second")

And this:

mt_lutxy(orig,diff,yexpr="x y 128 - -",uexpr="y",vexpr="y",Y=3,U=3,V=3)

by

SubtractDiff(orig, diff, chroma = "copy second")

Are you actually processing the chroma in the function at all, or is it just passing through chroma values for convenience? (Untangling scripts isn't something I'm great at either :o.) If not, there's a more efficient way to do this...

Edit: I got MaskTools modes 2 and 3 confused... Edit: no I didn't, there was a u ="y" confusing me into thinking I was confused.

Boulder
12th January 2006, 20:12
You know that this is only processing the U plane, right?
Yep. I use FFT3DGPU for chroma processing as it's fast and effective. It's very good for DV->DVD stuff. The GPU version always processes both chroma planes if you use plane=1,2,3 or 4.

mg262: Didée's function does process chroma as well. The denoiser appears to be either TemporalSoften or TTempSmooth depending on certain parameters. Thank you for the optimizations, even if the current encode runs at 0.15RT in CCE, speed gain is always appreciated :)

Here's the whole lot of it (Didée's and your fixes not yet there):

global idx_counter = 10

function MCNR_simple2( clip clp, int "frames", int "thY", int "thC", int "thY2", int "thC2",
\ int "blocksize", bool "chroME", bool "repairME", bool "removdirt",
\ float "LPrad", int "LPlosens", int "LPhisens")
{
frames = default( frames, 2 ) # number of temporal neighbors to use for motion compensation & temporal filtering
thY = default( thY, 8 ) # upper thresh for pixel differences to include into temporal filtering
thC = default( thC, 6 ) # ditto, for chroma
thY2 = default( thY2, -1 ) # lower diff. thresh, for TTempSmooth (= -1 --> use TemporalSoften, not TTempSmooth)
thC2 = default( thC2, -1 ) # ditto, for chroma
blocksize = default( blocksize, 16 ) # blocksize for motion search & compensation
removdirt = default( removdirt,false) # additionally use RemoveDirt? (tip: for strong noise - true, else false. Requires frames>1)
chroME = default( chroME, false) # include chroma planes into motion search?
repairME = default( repairME, true ) # simple repairing of MC/ME errors (good when using bigger thresh's).
LPrad = default( LPrad, 0.0 ) # Lowpass protection: radius for gaussian blur
LPlosens = default( LPlosens, 1 ) # LP protection: lower thresh for motion recognition
LPhisens = default( LPhisens, 5 ) # LP protection: upper thresh for motion recognition

frames = (frames<1) ? 1 : (frames>4) ? 4 : frames
removdirt = (frames==1) ? false : removdirt
LPhisens = (LPhisens>LPlosens) ? LPhisens : LPlosens+1

dummy = blankclip(clp,width=64,height=32)

global idx_counter = idx_counter + 1

bw4 = (frames<4) ? dummy : clp.SrchCmpRp(blocksize,true, 4,chroME,repairME)
bw3 = (frames<3) ? dummy : clp.SrchCmpRp(blocksize,true, 3,chroME,repairME)
bw2 = (frames<2) ? dummy : clp.SrchCmpRp(blocksize,true, 2,chroME,repairME)
bw1 = clp.SrchCmpRp(blocksize,true, 1,chroME,repairME)
fw1 = clp.SrchCmpRp(blocksize,false,1,chroME,repairME)
fw2 = (frames<2) ? dummy : clp.SrchCmpRp(blocksize,false,2,chroME,repairME)
fw3 = (frames<3) ? dummy : clp.SrchCmpRp(blocksize,false,3,chroME,repairME)
fw4 = (frames<4) ? dummy : clp.SrchCmpRp(blocksize,false,4,chroME,repairME)

frames == 1 ? interleave( bw1,clp,fw1 ) : \
frames == 2 ? interleave( bw2,bw1,clp,fw1,fw2 ) : \
frames == 3 ? interleave( bw3,bw2,bw1,clp,fw1,fw2,fw3 ) : \
interleave( bw4,bw3,bw2,bw1,clp,fw1,fw2,fw3,fw4 )

removdirt ? removedirt() : last

(thY2 < 0) || (thC2 < 0) ? temporalsoften(frames,thY,thC,32,2)
\ : ttempsmooth(frames,thY,thC,thY2,thC2,5,24)

selectevery(frames*2+1,frames)

LPrad < 1.01 ? last : LPprotect(last,clp,LPrad,LPlosens,LPhisens)

return( last )
}

# --------------------------------

function SrchCmpRp( clip clp, int _blksize, bool _isb, int _delta, bool _chroME, bool _repair)
{
vec = clp.mvanalyse(truemotion=true,pel=2,blksize=_blksize,chroma=_chroME,isb=_isb,delta=_delta,idx=idx_counter)
comp = clp.mvflow(vec,idx=idx_counter)
# vec = clp.mvanalyse(pel=2,blksize=_blksize,chroma=_chroME,isb=_isb,delta=_delta,idx=idx_counter)
# comp = clp.mvcompensate(vec,idx=idx_counter)
_repair ? repair(comp,clp,1,3) : comp
return( last )
}

# --------------------------------

function LPprotect( clip NR, clip orig, float rad, int low, int high )
{
ox = NR.width()
oy = NR.height()
HI = string(256.0/high)
LO = string(256.0/high*low)
ML = string(float(high)/(float(high)-low))
diff = yv12lutxy(orig,NR,"x y - 128 +","y","y",U=3,V=3)
diffLP = repair(diff,diff.removegrain(4,-1).bicubicresize(m4(ox/rad),m4(oy/rad)).bicubicresize(ox,oy,1,0),1,0)
diff = mt_lutxy(diff,diffLP,"x 128 - y 128 - * 0 < 128 x y 128 - - ?",U=2,V=2)
MyMoMask = logic( mt_lutxy(NR,NR.deleteframe(0), "x y - abs "+HI+" * "+LO+" - "+ML+" *"),
\ mt_lutxy(NR,NR.duplicateframe(0),"x y - abs "+HI+" * "+LO+" - "+ML+" *"), "max")
mt_merge(NR,yv12lutxy(orig,diff,"x y 128 - -","y","y",U=3,V=3),MyMoMask.fity2uv(),U=3,V=3)
#MyMoMask.greyscale
return( last )
}

# --------------------------------

function m4(float x) {return( x<16?16:int(round(x/4.0)*4)) }

mg262
12th January 2006, 20:30
I know that MCNR_simple as a whole processes chroma... but I'm not sure about this function we are working on.
Thank you for the optimizations, even if the current encode runs at 0.15RT in CCE, speed gain is always appreciated
Well, we might as well get the fastest version of this for future reference (hope it's not too OT in this thread)...

Here's what I came up with:
diff = mt_lutxy(orig,NR,yexpr="x y - 128 +",uexpr="y",vexpr="y",Y=3,U=3,V=3)
diff chroma copied from NR.

diff = mt_lutxy(diff,diffLP,yexpr="x 128 - y 128 - * 0 < 128 x y 128 - - ?",uexpr="x",vexpr="x",Y=3,U=2,V=2)
diff chroma copied from first argument, so still comes from NR.

mt_lutxy(orig,diff,yexpr="x y 128 - -",uexpr="y",vexpr="y",Y=3,U=3,V=3),
output chroma is copied from the second argument, i.e. diff, so is ultimately copied from NR.

(Someone with more ability with scripts than the average turnip please check that... Now if it is right: )

This last line is replaced with SubtractDiff. That function has the option to copy chroma from any source... like NR. So we can do this:

1) diff = mt_lutxy(orig,NR,yexpr="x y - 128 +",uexpr="y",vexpr="y",Y=3,U=3,V=3)

Could be replaced by

diff = AddDiff(orig, NR) #trashes chroma

2) mt_lutxy(diff,diffLP,yexpr="x 128 - y 128 - * 0 < 128 x y 128 - - ?",uexpr="x",vexpr="x",Y=3,U=2,V=2)

by

mt_lutxy(diff,diffLP,yexpr="x 128 - y 128 - * 0 < 128 x y 128 - - ?",Y=3,U=1,V=1)

And

3) mt_lutxy(orig,diff,yexpr="x y 128 - -",uexpr="y",vexpr="y",Y=3,U=3,V=3)

by

SubtractDiff(orig, diff, chroma = NR)

... and it doesn't hurt the overall readability any, either.

Edit: I think I've got something wrong somewhere; those changes would give you a script with:
mt_merge(NR,SubtractDiff(orig, diff, chroma = NR),MyMoMask.fity2uv(),Y=3,U=3,V=3)
in which you are merging the chroma of two things with the same chroma. AAARGH...

Boulder
13th January 2006, 07:58
Uh, let's hope the master of the scripts will doublecheck things..I'm quite confused as well :D

eb
13th January 2006, 11:50
Here is your sample after delogo, cropping, deinterlacing, a little denoising in VDM filters
sample (ftp://www.eb.enterpol.pl:eb@www.eb.enterpol.pl/cdc+.avi) 834kB right click and save

http://img205.imageshack.us/img205/6060/pict333xo.jpg (http://imageshack.us)

EDIT: oops it is AviSynth thread, Mod please remove this post if needed

Mug Funky
13th January 2006, 11:56
needs less warpsharp. it looks like an "impressionist" filter...

Boulder
13th January 2006, 11:57
Way too blurry for my taste, not much details left ;)

As I'm encoding for DVD, I don't need to deinterlace and also VD filters are a no-no due to an extra colorspace conversion they require. Thanks for your contribution in any case :)

Didée's function is working very well, the swimming blocks problem is much less apparent and probably unnoticable when viewed on the TV.

eb
13th January 2006, 12:23
Even for DVD I prefer progressive rather...
http://img203.imageshack.us/img203/918/pict339pb.th.jpg (http://img203.imageshack.us/my.php?image=pict339pb.jpg)

Boulder
13th January 2006, 12:28
Um, what do you mean? I don't want to lose the smooth motion and the video is also clearer when encoded as it is. If you watch stuff on the PC, that's another story.

Chainmax
13th January 2006, 13:36
I'm surprised you haven't tried BlockBuster for swimming blocks coverup. On a recent encode I'm doing, I didn't want to filter too much since the source had little detail on it, but that left some noticeable movng blocks in some spots. With AddGrain(2,0,0), almost all instances of that were completely covered up, and since such a low setting was used it's quite difficult to notice the grain which fakes extra detail quite effectively to boot. I recall you prefer BlockBuster, so try that at low settings and see if it works for you.

mg262
13th January 2006, 13:38
Have we mentioned Deblock_QED? (Or are we talking about some other kind of block?)

Boulder
13th January 2006, 15:23
The blocking isn't in the source but appears when the remaining noise is quantized and the reason is most likely what Didée said earlier in this thread. The noise is very soft, not the kind of sharp noise for example DV clips have. In addition to this, there's some horizontal stripes that are probably interference noise.

I could try Blockbuster as well though it might not be enough as the amount of the soft noise is quite big.

Revgen
13th January 2006, 17:47
Have you tried Timedenoise (http://forum.doom9.org/showthread.php?p=621343#post621343)?

It's a very slow function that uses MvTools and other filters to denoise.

Boulder
13th January 2006, 19:26
Unfortunately it looks like that'll be too slow for regular encodes :(

mg262
13th January 2006, 19:54
I haven't tried it (and my PC's in a 24-hour job right now) but I'm inclined to be wary of functions that apply three denoisers successively! Also, IMO if you are taking the time to motion compensate it makes more sense to motion compensate whatever main denoiser you're using than to chain it with mvdenoise.

Didée
13th January 2006, 23:51
... and back again.

I think I've got something wrong somewhere; those changes would give you a script [...] in which you are merging the chroma of two things with the same chroma. AAARGH...
Uh, let's hope the master of the scripts will doublecheck things..I'm quite confused as well :D
Well ... congratulations, you catched the "master of the scripts" (humm) in doing something as silly as serving the original chroma through several clips, and finally copying back the served-through original chroma onto the first clip with a masked merge. Yummy! :D (Did I mention that script was developped during lunchbreaks only?)
Intention probably was to LP protect chroma, too ... but it seems one day the bell had rung too early ;) And it's not even sure if that protection is needed for the chroma planes: in worst case there'll be some loss of saturation in moving parts - and that's how it is, as of now. I'll change that soon, perhaps with an option for an additional calm-down of "static" areas.

Regarding TimeDenoise: I've tried it on some occasions, but had my issues with it: with light settings for low-noise sources, it was way too slow to justify its usage (comparable results could be achieved with X-times faster filters or filterchains). With medium settings the results were rather good, though it removed a tad too much of detail. And with strong settings (sometimes with medium, too), I found quite some scenes where the blocky errors of motion compensation were presented in all their beautyness. However this should be easy to cure by using Fizick's MVFlow. IF we're still allowed to use the last v1.0.3 version, that is.

Wilbert
13th January 2006, 23:57
IF we're still allowed to use the last v1.0.3 version, that is.
Of course we do. It still is GPL.

Btw, v1.1 should also be GPL when the binary will be available to some people (namely the ones who pay something), since Manao is the original developer (unless Fizick got permission from Manao to change the license). This means the source should also be available by that time. (MVTools, VagueDenoiser, Despot)

Boulder
14th January 2006, 08:07
I'll change that soon, perhaps with an option for an additional calm-down of "static" areas.

Would it be possible to have an option to process luma only? It would (?) be faster and there are some good and fast options for chroma denoising, such as FFT3DGPU that I mentioned earlier in this thread.

livingfruitvirus
17th January 2006, 05:26
Here you go.
I usually have to play around with window sizes and positions for Defreq and threshold for VagueDenoiser. Occasionally have two instances of Defreq if the four windows are not enough.
Hope this helps. :)

#Capture AVS
#
# PLUGINS
#LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\plugin.dll")
#
# SOURCE
AVISource("H:\AVI_Capture\Capture\Capture.avi")
assumetff()
Tdeint(mode=1)
DeFreq(fx=18, fy=23, dx=1.5, dy=6, Sharp=-100, fx2=18, fy2=-78, dx2=1.5, dy2=6, sharp2=-100, fx3=79, fy3=34, dx3=10, dy3=3, sharp3=-100, fx4=77.5, fy4=-66, dx4=9, dy4=3, sharp4=-100, Show=false, Info=false)
VagueDenoiser(threshold=3,method=1,nsteps=6,chromaT=0.8,interlaced=false)
#VagueDenoiser(threshold=0.8,method=1,nsteps=6,chromaT=0.8,interlaced=false)
assumetff() #set the fieldorder again (the same as above!)
separatefields()
selectevery(4,0,3)
weave()
#info()

Would you happen to know where I could find TDeint? The site that most links point to is now a 404 Not Found page.

foxyshadis
17th January 2006, 06:08
You can always find his stuff on his page: http://bengal.missouri.edu/~kes25c/

Boulder
21st January 2006, 17:10
Intention probably was to LP protect chroma, too ... but it seems one day the bell had rung too early ;) And it's not even sure if that protection is needed for the chroma planes: in worst case there'll be some loss of saturation in moving parts - and that's how it is, as of now. I'll change that soon, perhaps with an option for an additional calm-down of "static" areas.

Have you had the chance to look at this yet?

Boulder
26th January 2006, 15:26
OK, I finally got the time to experiment with MVTools' motion compensated stuff. This portion deals with the noise quite nicely:

analysis=TemporalSoften(2,5,5,8,2)
vbw1=analysis.MVAnalyse(isb = true, truemotion=true, delta = 1, pel = 2, chroma = false, blksize = 16)
vbw2=analysis.MVAnalyse(isb = true, truemotion=true, delta = 2, pel = 2, chroma = false, blksize = 16)
vbw3=analysis.MVAnalyse(isb = true, truemotion=true, delta = 3, pel = 2, chroma = false, blksize = 16)
vfw1=analysis.MVAnalyse(isb = false, truemotion=true, delta = 1, pel = 2, chroma = false, blksize = 16)
vfw2=analysis.MVAnalyse(isb = false, truemotion=true, delta = 2, pel = 2, chroma = false, blksize = 16)
vfw3=analysis.MVAnalyse(isb = false, truemotion=true, delta = 3, pel = 2, chroma = false, blksize = 16)
bw1=MVCompensate(last,vbw1,thscd1=500)
bw2=MVCompensate(last,vbw2,thscd1=500)
bw3=MVCompensate(last,vbw3,thscd1=500)
fw1=MVCompensate(last,vfw1,thscd1=500)
fw2=MVCompensate(last,vfw2,thscd1=500)
fw3=MVCompensate(last,vfw3,thscd1=500)
Interleave(bw3,bw2,bw1,last,fw1,fw2,fw3)
MT("TemporalSoften(3,10,10,15,2)",2)
SelectEvery(7,3)

It probably could be tweaked in a thousand ways but it'll have to do for now;)

By the way, is there a way to make TemporalSoften work only on the center frame which is the one that's output after SelectEvery? Shouldn't that be faster as the compensated frames are processed even though it's not necessary.

Didée
26th January 2006, 15:46
By the way, is there a way to make TemporalSoften work only on the center frame which is the one that's output after SelectEvery? Shouldn't that be faster as the compensated frames are processed even though it's not necessary.
Well, they *are* not processed. (Processing chain is build up backwards, so TemporalSoften applies only to the SelectEvery()'ed frames anyways.

What makes your script slololoow is the not-using of the "idx" parameter ... if you had copied-over Fizick's example (MVT docu) more carefully, it would run faster. ;)

Boulder
26th January 2006, 15:49
Well, they *are* not processed. (Processing chain is build up backwards, so TemporalSoften applies only to the SelectEvery()'ed frames anyways.

Ah, something new to learn each day :) I thought the flow goes from top to the bottom.

What makes your script slololoow is the not-using of the "idx" parameter ... if you had copied-over Fizick's example (MVT docu) more carefully, it would run faster. ;)
Like I said, tweak it in a thousand ways;) Thanks, I'll add the parameter. Isn't it idx=1 in every instance of MVAnalyse and MVCompensate?

Chainmax
26th January 2006, 15:55
Have you tried including hqdn3d(0,0,3,3) in your filterchain? Soulhunter said it was good for temporal stabilizing IIRC.

Didée
26th January 2006, 16:19
Pre-cleaning for ME probably often is better with spatio-temporal smoothing, indeed. FFT3DFilter deals pretty good, too ... :D

Like I said, tweak it in a thousand ways;)
Already done. The name is MVNR_simple.

(Well, except for ME pre-cleaning, which was kept out for reasons of speed and simplicity.)
(The not-speedy and not-simple version meanwhile is growing.)

Thanks, I'll add the parameter. Isn't it idx=1 in every instance of MVAnalyse and MVCompensate?
No. Per default it's "-1", meaning that for *every* single MVAnalyze() command and for *every* single MVCompensate/Flow/whatever() command, a *separate* interpolation has to be computed, and that for *every* single one of those interpolations a 10-frame (AFAIK) buffer is created and hold in memory ...

So, you should use "idx=a_certain_value" for all MVAnalyze() commands, and "idx=anOTHER_certain_value" for the compensation commands.

Boulder
26th January 2006, 16:32
Thank you again. If you ever come to Finland, make sure you let me know and I'll get you a beer keg :)

foxyshadis
27th January 2006, 02:42
(The not-speedy and not-simple version meanwhile is growing.)
I feel... a dark, unfathomable disturbance... as if a thousand frames and a thousand processors were crying out in unison. :p

Alain2
16th February 2006, 18:41
Well, they *are* not processed. (Processing chain is build up backwards, so TemporalSoften applies only to the SelectEvery()'ed frames anyways.
Can you detail this a bit or send me to a page with some details about the way scripts are read by avisynth ? I made some scripts in the past using the conditionalFilter environment, and I always thought the way it was working was (on Boulder script) avisynth request frame # -> selectevery request frames -> temporalsoften requests frames -> interleave request frames from clips bw3 etc... ?

Livesms
24th November 2007, 23:18
I'm looking for a good denoise script for my TV capture before 2pass reencode Xvid.
There is a light noise (cable TV) in my capture and I tried

SetMTmode(2)
AviSource("Video.avi").killaudio()
AssumeTFF()
MVDegrain2i(4,0,1)
TomsMoComp(-1,15,1)
Lanczos4Resize(512,384)
FadeIO(25)
####################################################################################
function MVDegrain2i(clip "source", int "overlap", int "dct", int "idx")
{
overlap=default(overlap,0)
dct=default(dct,0)
idx=default(idx,1)
fields=source.SeparateFields()
backward_vec2 = fields.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=overlap, idx = idx,dct=dct)
forward_vec2 = fields.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=overlap, idx = idx,dct=dct)
backward_vec4 = fields.MVAnalyse(isb = true, delta = 4, pel = 2, overlap=overlap, idx = idx,dct=dct)
forward_vec4 = fields.MVAnalyse(isb = false, delta = 4, pel = 2, overlap=overlap, idx = idx,dct=dct)
fields.MVDegrain2(backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400,idx=idx)
Weave()
}


The result is rather finу but too slow.
Is there any recomendation for denoise script?