exist any filter specially done for (deinterlace) flicker

[Terka83]

after deinterlace (even with mv/mcbob) some parts are flickering.
when small (mostly horizontal shape) areas appears in clip, the flickering is much visible.
these areas (after deinterlace) needs some deflicker.
look at
http://www.pate15.de/entrelacement/entrelacement_7.htm
http://www.pate15.de/entrelacement/page_5/anim/stockholm-mvbobmod.avi

[Mug Funky]

maybe try Repair, in Kassandro's removegrain package.

that might calm down the bobby bits.

i'd love to see a perfect bob, but it's one of those intractable "holy grail" problems - pulling detail out that simply isn't there, and doing it in a way that a human wont notice (computers as yet can't "watch" video in the same way we do, and most of the problems we have processing video stem from this fact).

[g_aleph_r]

I find Yadifmod: Perfect!!
I use this script:
interpe = clip.separatefields().selecteven().nnedi(field=1,dh=true)
interpo = clip.separatefields().selectodd()turn180().nnedi(field=1,dh=true).turn180()
interp = interleave(interpe,interpo)
yadifmod(clip,mode=1,edeint=interp)

Perfect! (I had to deinterlace real interlaced clip)

[2Bdecided]

Is that really better than mcbob with NNEDI? It's probably faster, but less safe/intelligent. Useful though, thanks!

Cheers,
David.

[WorBry]

I find Yadifmod: Perfect!!
I use this script:
interpe = clip.separatefields().selecteven().nnedi(field=1,dh=true)
interpo = clip.separatefields().selectodd()turn180().nnedi(field=1,dh=true).turn180()
interp = interleave(interpe,interpo)
yadifmod(clip,mode=1,edeint=interp)

Perfect! (I had to deinterlace real interlaced clip)

Sorry to revive an old thread (I've been accused of necromancing before ), but what is the logic behind rotating the separated top fields before NNEDI in relation to reducing vertical flicker (shimmering or over-bobbing, as I'd call it)?

[WorBry]

Here’s an example of the type of deinterlace situation I’m grappling with – resolving striped patterns with minimal shimmering.

DV Source (50i, 16.9 anamorphic)

http://rapidshare.com/files/115223308/Source_DV_Type_2_50i_16.9_anamorphic.avi.html

Deinterlaced 50p outputs:
(Decoder: Cedocida YV12, MPEG2 interlaced. Encoder: FFDShow HuffYuv-YV12)

yadifmod(order=0, mode=1, edeint=nnedi(field=-2))

http://rapidshare.com/files/115223974/YadifMod_NNEDI_HuffYuv-YV12.avi.html

interpe = separatefields().selecteven().nnedi(field=1, dh=true)
interpo = separatefields().selectodd().turn180().nnedi(field=1, dh=true).turn180()
interp = interleave(interpe,interpo)
yadifmod(order=0,mode=1,edeint=interp)

http://rapidshare.com/files/115224482/YadifMod_NNEDIturned_HuffYuv-YV12.avi.html

MCBob 0.3u

http://rapidshare.com/files/115224997/MCBob_0.3u_HuffYuv-YV12.avi.html

Actually, yadifmod-NNEDI does a pretty decent job, but rotating the odd (top) fields before NNEDI, if anything, generates more misalignment and flicker/shimmering.

Any suggestions for improvement?

[2Bdecided]

The first thing to say is that, in interlaced video, there is complete confusion between high vertical spatial frequencies (fine detail) and vertical motion of approx 1 video line per field. The two cannot be resolved, theoretically. Even if you watch such footage on an interlaced CRT, what you see can sometimes look a little strange.

What to do? Well, this probably won't help, but IMO when there are problems like this, then the best visual result is a dumb bob to 50fps, and correct playback of that 50fps result. The eye does a much better job of selectively averaging the two fields than any of these tools, at the expensive of perceived vertical resolution of course. Try it (if your 50fps playback works well on your system) - you might be surprised how good it can look.


Alternatively, for a similar perceived effect but written into the video itself, you can add an aggressive temporal soften. the problem is this will mess up other parts of the image. If you could do this selectively to the problem areas, it would be a great solution. Look at the strips after a simple bob(0.0,1.0).temporalsoften(1,255,255,mode=2) - I'm guessing that's what you want to happen? Shame about the other parts of the frame!


If you only want 25fps, then a dumb approach won't give bobbing, but aliasing. You could try blending to 25fps, if that's what you want.


None of these suggestions give you anything as sharp as what you've tried, but they dramatically reduce the artefacts.

FWIW I'm using mcbob 0.3c, and it make a real mess of those stripes!

Cheers,
David.

[map1742]

Having similar prolems with some of my videos so I just tried combining the suggestions from 2Bdecided's post; dumb bob to 50fps, removing the vertical motion, and correct playback of that 50fps result (by reinterlacing and then deinterlacing the result with yadifmod or mcbob). Vertical resolution appears to be preserved, the majority of artifacts are removed and the use of mcbob may be acceptable. A long temporal filter is required to minimise the residual flicker.

#Resize to 1:1 aspect ratio
Spline36Resize(1024,height)
# Dumb bob then motion stabilise
bob(0.0, 1.0)
i=last
mdata = DePanEstimate(i)
DePanStabilize(i, data=mdata)
#Reinterlace
AssumeFrameBased().SeparateFields().SelectEvery(4,0,3).assumefieldbased().weave()
#Deinterlace
yadifmod(order=0, mode=1, edeint=nnedi(field=-2))
#Long temporal fileter to minimise residual flicker
Scripted_MVDegrain5Filter()

[Didée]

Yay, the old prob of not knowing what's in those missing lines ... we've been there before, haven't we?

EDI interpolators too are struggling (and failing) often times with those high-contrast patterns. And when you start right out with EDI interpolation, then you can throw MVStuff at it afterwards as much as you like ... it will mostly just follow & compensate the flicker, and there your effort goes down the drain. Unless the effort is big enough to blurrr the crap out of it and to hammer everything flaaat ...


@ WorBry: What're your expectations?

Perhaps like so (http://www.mediafire.com/?td3hxey1gdy) ?

[WorBry]

My expectations? Well I wasnt expecting miracles, bearing in mind also the limitations of line resolution coming from a consumer-level SD DV camcorder, in this case a Panasonic NV-GS400, which is about as good as it gets for interlaced DV. Granted the clip was shot under artificial light so there's some discrimination of noise and detail to deal with there also.

So my best hope was to reduce the shimmering to a level that is not so visually distracting with as little loss of definition as possible...pretty much along the lines of what your TGB treatment achieves.

I was thinking that Vinverse or one of the SangNom anti-aliasing routines (e.g. SAA) might help but wasnt sure how to apply these in this context.....on the fields, before or after NNEDI interp?

Sooooo...are you going to reveal how the TGB trick is done or do I first need to join the Magic Circle and make a solemn oath? :)

[Didée]

Well, joining the Magic Circle surely is an option.:D Waiting for me making a clean script is anther one (you won't believe how knotty and non-understandable my scripts can get after an hour of toying around!). Though I can't foresee if it'll work correctly under all possible circumstances; most probably it won't. Whatever approach one takes, there will always be compromises to be made at some point.

Thing is, you can't really fight this flickering with spatial filters, Vinverse, AntiAliasing & Co. are out of the game. Using temporal filtering works wonders in static areas, and catastrophic in motion areas. Keeping both apart is difficult when not using motion compensation. And with motion compensation - as already said - the flicker tends to get "motion" compensated too, so that the temporal sword loses its sharpness. It's like Mug Funky concluded in post#2, a machine doesn't see the real problem. It tends to choose the "closest" solution, where man's brain wishes to have the solution that's only after the third corner, or even farther.
Or: to find a solution that satisfies a neural network (->brain), you need a neural network to find that solution. Simple pixel compairing mechanics will always fall short, sooner or later. It's the *interpretation* of the actual content that is needed, and that is beyond cheap scripting ...

[roozhou]

#Resize to 1:1 aspect ratio
Spline36Resize(1024,height)
# Dumb bob then motion stabilise
bob(0.0, 1.0)
i=last
mdata = DePanEstimate(i)
DePanStabilize(i, data=mdata)
#Reinterlace
AssumeFrameBased().SeparateFields().SelectEvery(4,0,3).assumefieldbased().weave()
#Deinterlace
yadifmod(order=0, mode=1, edeint=nnedi(field=-2))
#Long temporal fileter to minimise residual flicker
Scripted_MVDegrain5Filter()

Is it safe to resize before deinterlacing?

[Didée]

When resizing only horizontally and NOT vertically, then it's safe, yes.

The script I had used, cleaned up, a bit generalized & put into a function for convenience:

Edit 2008-05-20 : corrected gaussian weightings !
Edit 2008-05-23 : new version - improved speed and results
Edit 2008-05-24 : new version - more parameters allow more speedy processing

Edit 2008-05-27 : fixed bugs for "tr0=1" and "tr2=3"
# needed: MVTools, RemoveGrain/Repair, MaskTools v2, NNEDI, plus EEDI2 & Yadif for the fast modes

function TempGaussMC_alpha3(clip clp, int "tr0", int "tr1", int "tr2", float "sharpness", bool "rep0", bool "rep1", int "border", int "blocksize", int "overlap", string "EdiMode", int "draft")
{
tr0 = default( tr0, 2 ) # temporal radius for temporal Gauss before motion compensation (1 or 2)
tr1 = default( tr1, 2 ) # temporal radius for temporal Gauss with motion compensation (1 or 2)
tr2 = default( tr2, 1 ) # temporal radius for final MVDegrain (1, 2 or 3)
rep0 = default( rep0, true ) # repair temporalsoften-defects for searchclip
rep1 = default( rep1, true ) # repair MVDegrain-defects for output
border = default( border, 1 ) # 1 = padd borders internally to catch "half scanlines" at top + bottom (broadcast material)
bs = default( blocksize,8) # Blocksize for motion search
ovlp = default( overlap,bs/2) # Overlap size for ME blocks
sharpness = default( sharpness, 0.25+(tr1+tr2)/8.) # "inloop" sharpening to counteract softening, 0.0 to 1.0, or more if you like
EdiMode = default( EdiMode, "NNEDI") # interpolator to use: "NNEDI", "EEDI2" or "Yadif"
draft = default( draft, 0 ) # '1' outputs a quick draft, and '2' is even more draft'ier :p

trmax = (tr1 > tr2) ? tr1 : tr2
nullclip = blankclip(clp,width=16,height=16)

clp = (border==0) ? clp
\ : clp.pointresize(clp.width(),clp.height()+8, 0,-4,-0,clp.height()+8.001 )

edi = (EdiMode=="NNEDI") ? clp.nnedi(field=-2)
\ : (EdiMode=="EEDI2") ? clp.SeparateFields().EEDI2(field=-2, maxd=8)
\ : clp.Yadif(mode=1)
dbob = clp.bob()

t1 = dbob.temporalsoften(1,255,255,32,2)
t2 = dbob.temporalsoften(2,255,255,32,2)

t = (tr0==0) ? dbob
\ : (tr0==1) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)

tD = mt_makediff(dbob,t,U=3,V=3)
tD1 = tD.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2 = tD.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD = tD.mt_lutxy(tD1,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)
t2 = (rep0==true) ? t.mt_adddiff(tDD,U=3,V=3)
\ : t

searchclip = t2.removegrain(11).removegrain(11)
searchclip = (rep0==true) ? searchclip
\ : searchclip.mt_lutxy(edi,"x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",U=3,V=3)

#bs = 16
#ovlp = 4
tm = false
pel = 2
shrp = 2

bvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=true, delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=true, delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec1 = searchclip.MVAnalyse(isb=true, delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec1 = searchclip.MVAnalyse(isb=false,delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=false,delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
fvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=false,delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip

mvdg1 = edi.MVDegrain1(bvec1,fvec1, thSAD=800,idx=7)
mvdg2 = (tr1>1) ? edi.MVDegrain1( bvec2,fvec2,thSAD=800,idx=7) : nullclip

stage1 = (tr1==0) ? edi
\ : (tr1==1) ? mvdg1.merge(edi,0.25)
\ : mvdg1.merge(mvdg2,0.2).merge(edi,0.0625)

stage1a = stage1.mt_lutxy(stage1.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)
stage1b = (sharpness==0.0) ? stage1 : stage1a.repair(stage1a.repair(edi,12),1)

stage2 = (tr2==0) ? stage1b
\ : (tr2==1) ? stage1b.MVDegrain1(bvec1,fvec1, thSAD=400,idx=8)
\ : (tr2==2) ? stage1b.MVDegrain2(bvec1,fvec1,bvec2,fvec2, thSAD=400,idx=8)
\ : stage1b.MVDegrain3(bvec1,fvec1,bvec2,fvec2,bvec3,fvec3,thSAD=400,idx=8)

tD_2 = mt_makediff(dbob,stage2,U=3,V=3)
tD1_2 = tD_2.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2_2 = tD_2.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD_2 = tD_2.mt_lutxy(tD1_2,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2_2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)

stage3 = (draft==2) ? t .subtitle("Draft 2")
\ : (draft==1) ? t2 .subtitle("Draft 1")
\ : (rep1==true) ? stage2.mt_adddiff(tDD_2,U=3,V=3)
\ : stage2

(border==0) ? stage3
\ : stage3.crop(0,4,-0,-4)

return( last )
}

[WorBry]

Wow, thats quite amazing...."slow as a migrating glacier" (to quote Leak :D) of course, but very impressive and true-to-life (i.e. non-video-looking). Even my wife (our resident subjective video critic) will notice the difference...she's the one with a penchant for dressing the kids in striped tee-shirts.

So there's life in the 'old bob' yet ! Does a pretty good denoising job in the process also.

Thanks alot.

[Didée]

You're welcome. A little more "speed" (*cough*) is possible by using lower temporal radii. Sure this will also reduce the flicker reduction a bit, you've to try & see. With tr0=2 / tr1=1 / tr2=2 it's still quite stable, and you'll probably save a few hours on a complete project.

And a *denoiser* is all that this script is, indeed. A denoiser that also "denoises" bob flickering. ;)

[scharfis_brain]

@roozhou:
your scirpt is somehow weird:

1) resize the video to 16x9 and bob the video
2) stabilize motion
3) re-interlace it
4) bob-deinterlace it

this is a very lossy process since 1) already avoids temporal and spatial data being catched.


it is better to use this kind of script:


# Dumb bob then motion stabilise
yadifmod(order=0, mode=1, edeint=nnedi(field=-2))
i=last
mdata = DePanEstimate(i, pixaspect=1.454)
DePanStabilize(i, data=mdata, pixaspect=1.454)
#Long temporal fileter to minimise residual flicker
Scripted_MVDegrain5Filter()


It will run faster and it will show a much less blurred image.

[WorBry]

Of course, I'd like to compare this approach with Didee's TempGaussMC.

Where can the Scripted_MVDegrain5 filter be found ?

[jeffy]

Of course, I'd like to compare this approach with Didee's TempGaussMC.

Where can the Scripted_MVDegrain5 filter be found ?

I'm afraid nowhere. You would have to script it on your own.
:)

[Didée]

Exactly. The result could look similar to this:

Edit 2008-05-20 : corrected vectors for distances 4 & 5 ...
function Scripted_MVDegrain5(clip clp, bool "truemotion", int "pel", int "blksize", int "overlap", int "sharp", int "thSAD", int "idx")
{

tm = default( truemotion, true )
pel = default( pel, 2 )
bs = default( blksize, 8 )
ovlp = default( overlap, 0 )
shrp = default( sharp, 1 )
thSAD = default( thSAD, 400 )
idx = default( idx, 11 )

bvec5 = clp.MVAnalyse(isb=true, delta=5,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)
bvec4 = clp.MVAnalyse(isb=true, delta=4,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)
bvec3 = clp.MVAnalyse(isb=true, delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)
bvec2 = clp.MVAnalyse(isb=true, delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)
bvec1 = clp.MVAnalyse(isb=true, delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)
fvec1 = clp.MVAnalyse(isb=false,delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)
fvec2 = clp.MVAnalyse(isb=false,delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)
fvec3 = clp.MVAnalyse(isb=false,delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)
fvec4 = clp.MVAnalyse(isb=false,delta=4,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)
fvec5 = clp.MVAnalyse(isb=false,delta=5,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=idx)

mvdg3 = clp.MVDegrain3(bvec1,fvec1,bvec2,fvec2,bvec3,fvec3,thSAD=thSAD,idx=idx)
mvdg5 = mvdg3.MVDegrain2(bvec4,fvec4,bvec5,fvec5,thSAD=thSAD,idx=idx)
\ .Merge(mvdg3, 0.436) # correct weightings (hopefully)

return( mvdg5 )
}

Feel free to implement more MVAnalyse parameters, parameters error checking, etc. pp. by yourself ...

[map1742]

Scharfis_brain,

For this example “smart“ deinterlacers are unable to handle the vertical motion between fields without producing artefacts. Mcbob in this case fails spectacularly with patches of double frequency strips appearing. These artefacts are not being filtered with MVtools, either they have a high contrast and thus a high SAD or the block based MVtools is following the artefacts and reinforcing them.

Didee described this beautifully in post #9 above.

Just using a dumb bob and then temporal filtering to reduce the flicker losses the advantages of “smart“ deinterlacers such EDI interpolation and increased vertical resolution on static areas.

Hence this experiment with global motion-compensate before using a smart deinterlacer. The global estimation to follow the content and not the flicker. A dumb bob followed by re-interlacing should be lossless if there is no movement and if there is movement then the vertical low-passed filtered dumb bob output is exactly what we need to avoid aliasing.

A common problem with content from hand held video camera content. I see it with my own footage and it is compounded by sharpening halos on horizontal edges. I now remove these halos on each field before smart deinterlacing and will try adding global motion compensation as well.

[WorBry]

I haven’t had opportunity to test TempGaussMC with other ‘shimmery’ scenes as yet, but with the ‘striped tee-shirt’ clip I posted above I cannot see that either the script posted by Map1742 or that suggested by Scharfis offer an improvement on YadifMod.NNEDI alone, in this context

Here are the results:

Spline36Resize(1024,height)
bob(0.0, 1.0)
i=last
mdata = DePanEstimate(i)
DePanStabilize(i, data=mdata)
AssumeFrameBased().SeparateFields().SelectEvery(4,0,3).assumefieldbased().weave()
yadifmod(order=0, mode=1, edeint=nnedi(field=-2))
Scripted_MVDegrain5() # as posted by Didee

http://rapidshare.com/files/115662713/Resize_Bob_Depan_Reint_YadifMod_NNEDI_MVGrain5_HuffYuv-YV12.avi.html


yadifmod(order=0, mode=1, edeint=nnedi(field=-2))
i=last
mdata = DePanEstimate(I, pixaspect=1.454)
DePanStabilize(i, data=mdata, , pixaspect=1.454)
Scripted_MVDegrain5() # as posted by Didee

http://rapidshare.com/files/115663551/YadifMod_NNEDI_Depan_MVGrain5_HuffYuv-YV12.avi.html

Compare with the results for yadifmod(order=0, mode=1, edeint=nnedi(field=-2)) alone and for TempGaussMC, as posted above (post # 9)

I might add that the clip was shot with OIS (Optical Image Stabilization) on. Whilst OIS theoretically degrades ‘image quality’ (assumed resolution) by around 10% (according to Panasonic), this is a vast improvement on Electronic Image Stabilization, which for those Panasonic cams that use it, is reckoned to degrade quality by as much as 30-40%. As you can see (from the Depan borders), even in my shaky little mits, the clip is reasonably steady for a hand-held shot. I should maybe include some shots with OIS off (hand-held and tripod) in my further tests.

@Map1742, I agree aliasing is a problem with consumer-level DV cams, and the GS400 is quite prone to it - probably a by-product of the 3CCD pixel-shift technology. There’s some evident in this clip on the wall beading. One thing I do note is that your routine removes this quite effectively, but so does YadifMod.NNEDI plus MVDegrain5 alone. Delete the MVDegrain5 step from your script and the aliasing comes back. So the reasonable conclusion would be…….

Perhaps you could provide some clips that demonstrate the benefits of your pre-deinterlace processing.

[Didée]

Well, I tested a little around, too, and it has been interesting. Examined DV sequences were this one of yours, WorBry, and the one that Terka once peddled with. Then I looked at some of the notorious VQEG Test Sequences (http://media.xiph.org/vqeg/TestSeqences/ThumbNails/).

With map1742's script, there wasn't much noticeable improvement, the usual flicker just keeps being there. That's what I had expected. Flicker reduction only gets better when 'thSAD' for MVDegrain is cranked up to *very* high values, but then you start getting artefacts on moving objects.
Also I'm having an issue with DePanStabilize producing a green stripe beneath the right frame border, can't tell why. (Never used it before.)

The interesting part was testing TempGaussMC. I had expected all kinds of issues when throwing such a rather primitive brute-force processor at difficult content, but ... there are no serious ones! Just a slight loss of detail/shadings (and noise as well), but apart from that, it's very promising. In those parts where MCBob shines, it's quite close. And in those parts where MCBob fails, it's pretty good instead ...

This little plantlet must be cultivated. With some STT fertilizer and a few twists, it could become a strong one. :D

[WorBry]

Ah, the VQEG test sequences, we are knowing them well ;) I see they've added a few more and fancified the index....probably due to the notoriety.

Just a query about the 'sharpness' param in TempGaussMC. What are the intervals/limits, or more specifically, is the (default) 11.66 denominator in the calc a constant value (i.e. sharpness is modulated purely by the tr0, tr1, tr2 values) or a variable that can be tweaked? Not that I'm planning on much tweaking at this point

[Didée]

Well, the sharpness thingy is 100% arbitrary. It's just a "sharpen(x)" (plus repair-limiting) thrown between the two MVDegrain calls, to counteract softening that might come from the temporal averaging. The 11.66 denomoinator was chosen arbitrarily to end up with a default of sharpen(0.6) when all temporal radii are maxed out. The possible range for setting it manually is 0.0~1.0, because that's what sharpen() allows.

[WorBry]

OK, thanks.

[Didée]

Bugfix for TempGaussMC:

I was thinking too easy and managed to use incorrect weightings in Merge() to create the gauss.

The function in post#13 is correct now.

That was an embarrassing bug. I feel ashamed. :o

[yup]

Didée!
Please explain why need calculating fv4,fv5, bv4,bv5 vectors? Value this vector not use MVDegrainx. It is feature MVTools?
With kind regards yup.

[Didée]

Oh, indeed. There was an error in Scripted_MVDegrain5, too ... I fed the 2nd MVDegrain with the wrong vectors.
The script has been corrected. Thank you for noting!

[yup]

May be for noisy source usefull other approach. We use only MVDegrain1 but using mask which calculate ME error and use previous, current and next frame or previous -2 previous current or current next next +2. This very good for my VHS capture source. Also we can use multipass. I think about this more time but can not formalizing. Also we need care luma value for dark scene we need degrease THSad.
yup.

[WorBry]

OK I’ve had a little time for some testing. Dug around a bit in my home video DV archives and frankly I’ve been hard pressed to find scenes that TempGaussMC doesn’t cope with completely. Put together a little collage that you might want to look at in your tweaking. This one is all 4:3 DV.

http://rapidshare.com/files/116293372/Shimmer_Test_Mix_DV_4.3.avi.html


Scene 1. More electrified stripy tee-shirts. Some residual shimmer on the finer-line red one.

Scene 2. On the Farm. Some reduction in the shimmering of the vertical slats on the barn wall, relative to MCBob. Maybe too much to expect that this can be eliminated completely without excessive distortion/ blurring – more of a camera resolution limitation issue?

Scene 3. Safari Sofa. Nigh-on perfect calming of the shimmer on the cushion patterns.

Scene 4. Toy car mat. Again excellent calming of shimmers on the car mat pattern and edges of the cupboards. Just some very slight aliasing in places

Scene 5. Jumpy ride. Threw this one in just to see how well it copes with a very jerky motion scene, and it does so very well. Just a little more distortion of the wire mesh than MCBob, but it’s very close.

I won’t upload the Huff-YV12 outputs for TempGaussMC and MCBob as they are too large.

Cheers.

Edit: PS - I used the bug fixed version.

[Didée]

@ yup: If you want to discuss about a new denoising strategy, that's fine, but please open a new thread for that. This thread is mainly about deinterlacing flicker.
(Also, you don't need to speak in Oxford English or something, really.;) But try to be a bit more verbose on what is the new point in your idea, and why it would/should work better than existing solutions.)

That said, I don't claim that MVDegrain5 (or -7 or -10 or -25) is very useful. It's just that map1742 posted a script that used such a function, and most people couldn't try it out because MVDegrain5 wasn't posted somewhere. That's why I made it.

[Didée]

@ WorBry: Thanks for the clip. I'll definetly keep it for testing.

One thing to note about TempGaussMC is that it does a much "easier" (say: sloppy) job than any bob filter: a true bob filter has to keep the original fields unchanged, i.e. with xyzBob().SelectEvery(4,0,3).Weave() one should get back the original interlaced input, pixel-identical.
TempGaussMC doesn't care about that, it processes both the interpolated and the original fields. That's most probably okay for the usual application where one often does some denoising etc. after bobbing anyway. Still, this behaviour disqualifies that approach as being a "clinic" bob filter.
(And MCBob also produces less shimmering when the need to keep original fields untouched is removed ... it's MCBob's internal clip "repaired".)

[WorBry]

with xyzBob().SelectEvery(4,0,3).Weave() one should get back the original interlaced input, pixel-identical.

Surely SeparateFields before the SelectEvery....? ;)

Yeah, for the helluvit, I re-interlaced just to see what it would look like on a typical software player that uses simple bob & weave (like PowerDVD). Doesnt look bad but edges tend to be wavy in parts.

[Didée]

Rrrrrrrrr .... yes, definetly with SeparateFields before the SelectEvery. <swears>

There'll be another update to TempGaussMC today or tomorrow. A little tweaking here, a little addition there, and it handles practically everything that I've tried in a visually satisfying way. Much better on shaky motion, but still stable on static or slowly moving areas. Your clip seems fine, VQEG sequences ToyTrain, Musicians, Rugby and Formula-1 are fine. (The only funbreaker is "Scrolling Text", but that one is almost impossible anyway [the green letters!].)

[Terka]

sounds interesting..

[Didée]

New version up in post#13.

Major change:
- repairing of temporalsoften-ghosting for 'searchlip' (parameter "rep0") results in better motion estimation. Together with "rep1" (similar repairing on the end result) this gives better results in high-motion areas.

Minors:
- defaults for temporal radii reduced to (2,2,1). For most things, (2,1,1) should give reasonable stable output. If you need even more, use (2,2,2).
- sharpening now can be bigger than 1.0
- "border=1" makes sure that half-scanlines at top & bottom also don't flicker. (clip internally padded, since some filters don't process 1st & last line of their input)

It's still not a "lossless" bob filter, since the original fields are changed by the filter chain. But the results IMHO are pretty nice visually. If visual quality is more important than PSNR / SSIM scores, give it a go. ;)

[WorBry]

Very nice and definitely faster :) I'm surprised folks over in the 'film-look' thread havent twigged onto this. Maybe I'll give them a nudge ;)

Note:

Minors:
- defaults for temporal radii reduced to 2,1,1. Should give reasonable stable output for most things. If you need even more, use 2,2,2.

The defaults in the script are 2,2,1, not 2,1,1. I'm assuming the former is correct?

[Didée]

Oops, a typo.:D The default is (2,2,1) just because it's in the middle between the even faster (2,1,1) and the even calmer (2,2,2). Post above corrected.

Here's another example of a source that drove me nuts in the past:

http://img170.imageshack.us/img170/1878/bobexampleoz8.th.png (http://img170.imageshack.us/my.php?image=bobexampleoz8.png)

Sample (http://www.mediafire.com/?3jwwj2nclnz) (Mediafire.com)

Left: YadifMod(mode=1,edeint=NNEDI()) -- Right: TempGaussMC(2,2,2). Not uber-perfect, but way beyond all past results.

[WorBry]

....Not uber-perfect, but way beyond all past results.

Definitely

[Terka]

The example looks really good! Good work!

[2Bdecided]

It has some "nice" softening and denoising characteristics. If you want those (which I do) it's seems a more stable choice than mcbob (and that only rarely gives me trouble).

My naïve hopes for it being quite fast have been dashed though!

Cheers,
David.

[Terka]

tested on dogs (psi.avi).
imo:its much slower (didnot test properly), and visible better than mv/mcbob/mvbobmod
when psi.avi encoded h264 q28 its cca 30% smaller than mv/mcbob.
If compressed on smaller size with same quant. -it would be playable on less powerfull PC or more postprocessings are aplicable on powerfull PCs.

[Didée]

Well, "much slower than MCBob" I can't reproduce ... with default settings it's about MCBob's speed, actually a tad faster.

But I agree that it's rather slow. A quick'n dirty test gave the following rough figures:
MCBob: 1.05 fps
TempGauss: 1.10 fps
YadifMod(NNEDI): 2.55 fps
MVBobFaster: 2.55 fps
NNEDI(field=-2): 2.60 fps (Yes, my PC is a slow one.)

One reason for the low speed is that NNEDI is used as base for building the output, and NNEDI on it's own isn't exactly fast to begin with. Add to that all the additional MC stuff and error correction, and the result isn't a big surprise.

Now, for a little more fun, I've put up a new version. :)
It exposes MVAnalyse's blocksize & overlap as parameters, and allows to use either "NNEDI", "EEDI2" or "Yadif" as interpolators. Using this version with some fast settings, the table looks like this:
MCBob: 1.05 fps
TempGaussMC(): 1.10 fps
YadifMod(NNEDI): 2.55 fps
MVBobFaster: 2.55 fps
NNEDI(field=-2): 2.60 fps
TempGaussMC (#1): 2.86 fps
TempGaussMC (#2): 3.60 fps
TempGaussMC (#3): 5.60 fps

---------------------------------
#1 : (2,1,1,true,false,EEDI,16/4)
#2 : (2,2,2,true,true,Yadif,16/4)
#3 : (2,1,1,true,false,Yadif,16/4)

If that's still not fast enough, you can specify "draft=1" (or 2) to get exactly that: a draft. (But hey, it's fast!:p )

Edit: and by now, EdiMode="EEDI2" is actually working *cough* ... (forgot to put SeparateFields from the 'devel' into the 'clean' of my local scripts, oh well)

..... and now also the case that "overlap" isn't explicitely specified, see below. Thanks.

[WorBry]

Very nice :)

BTW - line 12, as is, throws an error. Should be:
ovlp = default( overlap, bs/2)

Edit: Interesting; to my eyes, using Yadif as interpolator gives an instrinsically sharper but marginally less stable result than NNEDI, all other parameters being equal. EEDI2 crashes on me.

[Terka]

i have to reinstal my pc to test the speed. tried only on my "work" notebook about 0.04fps :( -you see my is slower :P. thats why it looks slow for me. ill compare it to mvbobmod too.

[Didée]

With Yadif it might appear a bit sharper, but it's often more artificial than real. From VQEG's "Mobile" sequence:

TempGaussMC(Yadif): http://img144.imageshack.us/img144/9272/yadiftgmcjw8.th.png (http://img144.imageshack.us/my.php?image=yadiftgmcjw8.png) - TempGaussMC(EEDI2): http://img412.imageshack.us/img412/7277/eedi2tgmcxk0.th.png (http://img412.imageshack.us/my.php?image=eedi2tgmcxk0.png) - TempGaussMC(NNEDI): http://img144.imageshack.us/img144/7714/nneditgmcir4.th.png (http://img144.imageshack.us/my.php?image=nneditgmcir4.png)

If you switch between them, it's quite obvious that Yadif's speed comes at a price, and that NNEDI spends its time quite well.

Now that's an extreme example, it's possible that you won't see much of that on the "average content". It's just when using this script *always* with Yadif, and you're occasionally experiencing those artefacts, remember that it's not the script's fault, but your choice of having more speed. ;)

BTW, I like EEDI2 pretty much in this script. Not quite as good as NNEDI, but pretty close. When dealing with interlaced content a lot, the small differences to NNEDI could be very well worth the speed gain.

[WorBry]

Yes, its funny how the human eye can get used to perceiving artifact as detail. I remember when AVC/H264 encoding first became available to the masses how some people commented that it lacked definition and looked more 'artificial' than MPEG-4 & 2

Thanks for the fixes.

[thetoof]

Awesome script! It is even possible to bob a mix of progressive and interlaced without getting any jaggies, which was impossible to do with tdeint and mcbob. Thanks! *adding this to AnimeIVTC()*

[WorBry]

I have a query that’s sort of related.

The Panasonic GS400 DV camcorder that I shoot most of my home video stuff on also has a pseudo-progressive Frame Mode, which I use from time to time. The accepted understanding (Panasonic have never fully disclosed how it is done) is that the camera captures both fields at the same instant and combines them (possibly with some further electronic manipulation) to produce a frame that is technically interlaced but visually progressive (pseudo-25p). As one might expect, the frames are free from combing, but there tend to be quite conspicuous aliasing artifacts on high contrast edges, possibly arising from the pixel shift and line-pair summation.

I’ve tried various anti-aliasing filters, including the SangNom-based functions, but without satisfactory results; Soulhunter’s SAA script proved the most effective, but at the expense of too much blurring.

One thing I’ve noted about TempGauss MC, is its remarkable capacity to eliminate not only flickering (‘inter-line twitter’, I learn is the technical term in broadcast engineering) but other aliasing artifacts in the process. So, I thought why not test it with some Frame Mode clips also. Of course, I recognized that bobbing a 'progressive' source will (in theory) give dupes (although in practice not entirely identical due to imperfect complementary field interpolation) and so merged the output even and odd frames, like so:

TempGaussMC()
Merge(SelectEven(), SelectOdd(), 0.5)

Actually, the results are really quite good, with no aliasing (well maybe a tad) and far less blur than SAA.

So I’m wondering if Didee might consider looking at adapting the 'motion-compensated temp gauss' concept as a general purpose anti-aliasing function applicable to progressive sources as well. :):):)

Here’s the ‘frame mode’ test clip I used (anamorphic 16.9 DV)

http://rapidshare.com/files/117409243/Test_Mix_Frame_Mode_16.9_DV_Type_2.avi.html

[LaTo]

I’ve tried various anti-aliasing filters, including the SangNom-based functions, but without satisfactory results; Soulhunter’s SAA script proved the most effective, but at the expense of too much blurring.


### LaTo Antialiasing Script v2
### Need: asharp.dll & sangnom.dll
function LAA(clip input, int "strength", int "threshold", bool "sharp", float "ss") {

strength = default(strength, 96)
threshold = default(threshold, 10)
sharp = default(sharp, true)
ss = default(ss, 2.0)
aastr = int(strength) /2
asthr = float(strength) /100
ox = input.width
oy = input.height
ox2 = round(ox*ss/8)*8
oy2 = round(oy*ss/8)*8

process = input.spline36resize(ox2,oy2).turnleft().sangnom(aastr).turnright().sangnom(aastr)
process = ( sharp == true ) ? process.asharp(asthr,0,0).spline36resize(ox,oy) : process.spline36resize(ox,oy)
mask = mt_average(input,process,u=1,v=1).mt_edge(thy1=threshold,thy2=threshold,u=1,v=1)
output = mt_merge(input,process,mask,u=2,v=2)

return ( output )
}
###

Like this: LAA(last, 96, 10, true, 2.0) :)

[Terka]

mcbob 1.1fps
TempGaussMC(): 0.3 fps
some of my plugins is old :(
it was masktools, now got
TempGaussMC(): 1.6 fps

[WorBry]

Like this: LAA(last, 96, 10, true, 2.0) :)

Thanks. Not bad, but pretty much the same result as 'Anti-aliasing' script:

http://avisynth.org/mediawiki/AntiAliasing

Note the residual 'hatching' on the white base-board and red pole in the last scene of the DV sample I put up.

Didnt really want to turn this into an 'anti-aliasing' thread per se. Was more interested in the potential application of TempGaussMC in this area.

Edit: PS - I note that this also works quite well on the aliasing:

SeparateFields()
merge(SelectEven().EEDI2(),SelectOdd().EEDI2(),0.5)

But then you start to see more disruption and shimmering of high contrast line patterns (e.g. the striped red shirt in the last scene), and even more so with NNEDI:

SeparateFields()
merge(SelectEven().nnEDI(dh=true,field=1),SelectOdd().nnEDI(dh=true,field=0),0.5)

Hence the notion that this might be resolved by applying similar temporal treatments to those employed by TempGaussMC.

[Terka]

did some tests on TempGaussMC and its really good! :thanks:
Have some questions:
1.

is the (tr0==0) correct? (default is 2, so default will end with t1.merge(t2,0.357).merge(dbob,0.125))

t = (tr0==0) ? dbob
\ : (tr0==0) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)


2. if i understand the behaviour correctly, TempGaussMC is mostly denoiser which is suited for deinterlace. Didee feed it with yadif or "nnedi deinterlacer"... . If feeded with mv/mcbob will be the fesults even better?

3. Scharfi sugested to put some stabilization into. If this to do, where in the chain to put into?
bob-stabilize-TempGaussMC
or
bob-TempGaussMC-stabilize?
thank you!

[Didée]

It's amazing how much small bugs sneak into my posted scripts ...

1. No, of course that's not correct. The 2nd condition has to be "tr0==1".
Moreover there was a bug that causes an error for TGMC(tr2=3) ... a stupid syntax thingy.

Both bugs have been corrected, the function in post#13 is bugfree now. (Hopefully.)

I've another update pending. It'll cover an adapted sharpen mode (stronger in vertical direction, since that direction gets blurred more), and an option for rep1 acting a bit better.


2. Some improvements may be possible that way, but most probably it'll be minor improvements with major effort. TempGaussMC will average away much of the benefits that any motion-compensate bob will feed it with.
The other way round would be much better: Make a motion-compensated bob that uses TempGaussMC as basis for vector search, comparisons, etc. (Subsequently, this poses a pile of questions again, can't dive into that right now...)


3. Can't say much to that, for some reason DepanStabilize doesn't even work correctly for me. Besides, scharfis_brain didn't suggest stabilization. It was in the script posted by map1742, scharfis_brain just talked about the order of steps in that script.

[Terka]

Didee,
thank you for explanation.

[WorBry]

Any thoughts on my query about applying the temp gauss to progressive material? :(

Although applying Merge(SelectEven(), SelectOdd(), 0.5) to the output gives quite good results, I realize that the gauss itself has been applied over (near identical) dupe frames which will have disrupted the motion flow.

Tried tinkering myself, using merged dupes from the dbob and edi, or replacing dbob with the source clp itself, but I suspect this is screws up the temp gauss and mask tuning etc. I’m wondering if applying the gauss to the masked difference between the dupe frames and then adding this back to the merged dupes, might be a better approach, but am unsure how to set this up and what would be the better source for the dupes, a dbob or edi?

Do you think this would be a valid approach or am I completely off whack?

Cheers.

[Didée]

Well, I'm not sure what to say about that. Applying it to progressive material, the effect can be denominated as ...

a) (pragmatic version) ... a mix of spatial softening and temporal smoothing. :rolleyes:

b) (PR department version) ... spatio-temporal super-resolution filter. :cool:


Mixing in the way of

AnyBobFilter()
Merge( SelectEven(), SelectOdd() )

is the (mostly) spatial part. The motion-compensated parts of the script will partly consolidate the spatial part (one temporal neighbor is in fact the other spatial field), the rest will manipulate the spatial resolution by temporal processing after motion compensation.

So what to say? It does something, not necessarily something bad, but neither tuned to do something particularily good.

The funny thing about your progressive sample is that there's aliasing in some places, but not everywhere. The aliasing seems to happen mostly in high-contrast areas, but then again, not in all high-contrast areas. For that reason it's hard to find something that acts on only the aliased parts ... the problem is how to identify them.

Somewhen, somewhere, there was a thread by Chainmax about removing aliasing, where I had extracted the averaged-EEDI2-with-contrasharpening-method out of MCBob into a standalone script. Might be worth a try, too.

[thetoof]

If this (http://forum.doom9.org/showthread.php?t=118784) is the thread you're talking about, the AA script would be this, right?
c=last
dbl = mt_average(c.nnedi(field=1),c.nnedi(field=0),U=3,V=3)
dblD = mt_makediff(c,dbl,U=3,V=3)
shrpD = mt_makediff(dbl,dbl.removegrain(11),U=3,V=3)
DD = shrpD.repair(dblD,13)
dbl.mt_adddiff(DD,U=3,V=3)

[WorBry]

Yes, I assume thats the one also, or for EEDI2 and BFF clip:

o=last
AssumeBFF().SeparateFields()
dbl = mt_Average( SelectEven().EEDI2(field=0, maxd=4),
\ SelectOdd() .EEDI2(field=1, maxd=4), U=3,V=3 )
dblD = mt_MakeDiff(o,dbl,U=3,V=3)
shrpD = mt_MakeDiff(dbl,dbl.RemoveGrain(11),U=3,V=3)
DD = shrpD.Repair(dblD,13)
dbl.mt_AddDiff(DD,U=3,V=3)

Problem there is that even with the EEDI2 maxd set down to 4, there is still some disruption of high contrast line patterns (like on the striped shirt in scene 3 of the clip). Dropping to maxd=2 helps to avoid this but then the anti-aliasing is less effective. Maxd=3 seems to offer a reasonable compromise.

The NNEDI version looks better in some areas (e.g. a bit less shimmering of figures on wall posters in scene 2, although more than in the original clip), but there appears to be more degradation of fine line patterns (e.g. striped shirt).

[WorBry]

@Didee,

Tinkered a bit with the AA script above; found that applying the RemoveGrain (11) kernel blur diff to the unmerged EEDI2 bob and using a DumbBob (rather than the source clip itself) as the reference for the repair, before finally merging the even and odd output frames, helped to reduce the flickering/shimmering of objects (like the figures on the wall posters in scene 2) that were quite stable in the original clip. Seemed a valid approach since the treatment is primarily spatial i.e. no temporal component to be confused by dupes.

AVISource("E:\... \Test Mix Frame Mode 16.9 DV Type 2.avi")
o=last.AssumeBFF()
dbob=o.Bob()
edibob=o.SeparateFields().EEDI2(field=-2, maxd=3)
ediD = mt_MakeDiff(dbob,edibob,U=3,V=3)
shrpD = mt_MakeDiff(edibob,edibob.RemoveGrain(11),U=3,V=3)
DD = shrpD.Repair(ediD,13)
AddDD = edibob.mt_AddDiff(DD,U=3,V=3)
Mrgeo = merge(AddDD.SelectEven(),AddDD.SelectOdd(),0.5)
return( Mrgeo )

It also helped to smooth out the more stubborn aliasing (like the ‘quilting’ on the white base boards in scene 3). Predictably however, the mod resulted in slight increase in blurring.

Having seen what TempGaussMC can do, can’t get away from this (maybe misplaced) notion that a modified version (or the guts of it) that uses the merged (averaged) even and odd frames from the dumbbob (as source for the 'pre-mc' temp gauss) and likewise for the edi-bob (for the mo-comp/interp etc part), would provide anything other than an improved result (i.e. effective anti-aliasing whilst avoiding by-product flickering of 'stable' objects) for progressive DV sources such as this, even if inconsistencies in the appearance of aliasing and 'line-twitter' (love that phrase) make it more difficult to tune precisely.

Any chance you could put the usual (greyed-out) brief explanation of what each segment of the script does in the next TempGaussMC update; maybe I could get my head around it enough to have a stab (in the dark) at it? :rolleyes:

Unless of course you do have a ‘spatio-temporal super-resolution filter’ up your magician's sleeve? ;)

BTW - I'm continuing to get consistently excellent results with TempGaussMC as I test more interlaced material. Really is a superb processor.

Edit: In the routine for preparing the searchclp for the mo-comp, what added effect does RemoveGrain(11).RemoveGrain(11) as compared to single RemoveGrain(11)? I'm assuming more sharpening, which in the context of the mt_diff will mean more blurring and so smoothing of the mv's...correct?

[Terka]

Some idea, maybee worth maybee not.
o=original lines
b=bobbed (computed) lines
t=original tempgaussed
T=bobbed tempgaussed
-=no lines

orig:
o-o
-o-

bobbed:
obo
bob

bobbed tempgaused:
tTt
TtT

to do (is easy):
oTo
ToT

n=new way of using TG
to do:
ono
non

Lets use the TempGausMC usual way for deinterlace:
Use the original lines & the deinterlaced-TempGaussed.
So because TGMC changes original lines too, after
joining o with bt will improve sharpness, but increase flicker.
So let the TG more change the b, not the o.
Ive seen somewhere that for mcdenoisig is used some duplication of frames,
to increase their weight.It was something like:
ooobOOO , o=(1.frame ),O=(2.frame)
so the b=bobbed one will be changed more than the o=O=original.

[WorBry]

@Terka, Cant say I fully understand what you are suggesting…..assuming it was directed to me.

Basically, this is what I was thinking of as a working basis for progressive sources (noting disclaimer at end of post):

Either this
function TempGaussMC_mod(clip clp, int "tr0", int "tr1", int "tr2", float "sharpness", bool "rep0", bool "rep1", int "border", int "blocksize", int "overlap", string "EdiMode", int "draft")
{
tr0 = default( tr0, 2 ) # temporal radius for temporal Gauss before motion compensation (1 or 2)
tr1 = default( tr1, 2 ) # temporal radius for temporal Gauss with motion compensation (1 or 2)
tr2 = default( tr2, 1 ) # temporal radius for final MVDegrain (1, 2 or 3)
rep0 = default( rep0, true ) # repair temporalsoften-defects for searchclip
rep1 = default( rep1, true ) # repair MVDegrain-defects for output
border = default( border, 1 ) # 1 = padd borders internally to catch "half scanlines" at top + bottom (broadcast material)
bs = default( blocksize,8) # Blocksize for motion search
ovlp = default( overlap,bs/2) # Overlap size for ME blocks
sharpness = default( sharpness, 0.25+(tr1+tr2)/8.) # "inloop" sharpening to counteract softening, 0.0 to 1.0, or more if you like
EdiMode = default( EdiMode, "NNEDI") # interpolator to use: "NNEDI", "EEDI2"
draft = default( draft, 0 ) # '1' outputs a quick draft, and '2' is even more draft'ier :p

trmax = (tr1 > tr2) ? tr1 : tr2
nullclip = blankclip(clp,width=16,height=16)

clpo = (border==0) ? clp
\ : clp.pointresize(clp.width(),clp.height()+8, 0,-4,-0,clp.height()+8.001 )

clps = clpo.AssumeBFF().SeparateFields()

eeddbl = mt_Average(clps.SelectEven().EEDI2(field=0, maxd=4),
\ clps.SelectOdd().EEDI2(field=1, maxd=4), U=3,V=3 )

nnedbl = mt_average(clpo.nnedi(field=0),clpo.nnedi(field=1),U=3,V=3)

edidbl = (EdiMode=="NNEDI") ? nnedbl
\ : eeddbl

dbdbl = mt_average(clpo.Bob().SelectEven(),clpo.Bob().SelectOdd(),U=3,V=3)

t1 = dbdbl.temporalsoften(1,255,255,32,2)
t2 = dbdbl.temporalsoften(2,255,255,32,2)

t = (tr0==0) ? dbdbl
\ : (tr0==1) ? t1.merge(dbdbl,0.25)
\ : t1.merge(t2,0.357).merge(dbdbl,0.125)

tD = mt_makediff(dbdbl,t,U=3,V=3)
tD1 = tD.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2 = tD.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD = tD.mt_lutxy(tD1,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)
t2 = (rep0==true) ? t.mt_adddiff(tDD,U=3,V=3)
\ : t

searchclip = t2.removegrain(11).removegrain(11)
searchclip = (rep0==true) ? searchclip
\ : searchclip.mt_lutxy(edidbl,"x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",U=3,V=3)

#bs = 16
#ovlp = 4
tm = false
pel = 2
shrp = 2

bvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=true, delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=true, delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec1 = searchclip.MVAnalyse(isb=true, delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec1 = searchclip.MVAnalyse(isb=false,delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=false,delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
fvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=false,delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip

mvdg1 = edidbl.MVDegrain1(bvec1,fvec1, thSAD=800,idx=7)
mvdg2 = (tr1>1) ? edidbl.MVDegrain1( bvec2,fvec2,thSAD=800,idx=7) : nullclip

stage1 = (tr1==0) ? edidbl
\ : (tr1==1) ? mvdg1.merge(edidbl,0.25)
\ : mvdg1.merge(mvdg2,0.2).merge(edidbl,0.0625)

stage1a = stage1.mt_lutxy(stage1.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)
stage1b = (sharpness==0.0) ? stage1 : stage1a.repair(stage1a.repair(edidbl,12),1)

stage2 = (tr2==0) ? stage1b
\ : (tr2==1) ? stage1b.MVDegrain1(bvec1,fvec1, thSAD=400,idx=8)
\ : (tr2==2) ? stage1b.MVDegrain2(bvec1,fvec1,bvec2,fvec2, thSAD=400,idx=8)
\ : stage1b.MVDegrain3(bvec1,fvec1,bvec2,fvec2,bvec3,fvec3,thSAD=400,idx=8)

tD_2 = mt_makediff(dbdbl,stage2,U=3,V=3)
tD1_2 = tD_2.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2_2 = tD_2.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD_2 = tD_2.mt_lutxy(tD1_2,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2_2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)

stage3 = (draft==2) ? t .subtitle("Draft 2")
\ : (draft==1) ? t2 .subtitle("Draft 1")
\ : (rep1==true) ? stage2.mt_adddiff(tDD_2,U=3,V=3)
\ : stage2

(border==0) ? stage3
\ : stage3.crop(0,4,-0,-4)

return( last )
}

Or maybe this:

function TempGaussMC_mod2(clip clp, int "tr0", int "tr1", int "tr2", float "sharpness", bool "rep0", bool "rep1", int "border", int "blocksize", int "overlap", string "EdiMode", int "draft")
{
tr0 = default( tr0, 2 ) # temporal radius for temporal Gauss before motion compensation (1 or 2)
tr1 = default( tr1, 2 ) # temporal radius for temporal Gauss with motion compensation (1 or 2)
tr2 = default( tr2, 1 ) # temporal radius for final MVDegrain (1, 2 or 3)
rep0 = default( rep0, true ) # repair temporalsoften-defects for searchclip
rep1 = default( rep1, true ) # repair MVDegrain-defects for output
border = default( border, 1 ) # 1 = padd borders internally to catch "half scanlines" at top + bottom (broadcast material)
bs = default( blocksize,8) # Blocksize for motion search
ovlp = default( overlap,bs/2) # Overlap size for ME blocks
sharpness = default( sharpness, 0.25+(tr1+tr2)/8.) # "inloop" sharpening to counteract softening, 0.0 to 1.0, or more if you like
EdiMode = default( EdiMode, "NNEDI") # interpolator to use: "NNEDI", "EEDI2"
draft = default( draft, 0 ) # '1' outputs a quick draft, and '2' is even more draft'ier :p

trmax = (tr1 > tr2) ? tr1 : tr2
nullclip = blankclip(clp,width=16,height=16)

clpo = (border==0) ? clp
\ : clp.pointresize(clp.width(),clp.height()+8, 0,-4,-0,clp.height()+8.001 )

clps = clpo.AssumeBFF().SeparateFields()

eeddbl = mt_Average(clps.SelectEven().EEDI2(field=0, maxd=4),
\ clps.SelectOdd().EEDI2(field=1, maxd=4), U=3,V=3 )

nnedbl = mt_average(clpo.nnedi(field=0),clpo.nnedi(field=1),U=3,V=3)

edidbl = (EdiMode=="NNEDI") ? nnedbl
\ : eeddbl

t1 = clpo.temporalsoften(1,255,255,32,2)
t2 = clpo.temporalsoften(2,255,255,32,2)

t = (tr0==0) ? clpo
\ : (tr0==1) ? t1.merge(clpo,0.25)
\ : t1.merge(t2,0.357).merge(clpo,0.125)

tD = mt_makediff(clpo,t,U=3,V=3)
tD1 = tD.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2 = tD.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD = tD.mt_lutxy(tD1,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)
t2 = (rep0==true) ? t.mt_adddiff(tDD,U=3,V=3)
\ : t

searchclip = t2.removegrain(11).removegrain(11)
searchclip = (rep0==true) ? searchclip
\ : searchclip.mt_lutxy(edidbl,"x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",U=3,V=3)

#bs = 16
#ovlp = 4
tm = false
pel = 2
shrp = 2

bvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=true, delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=true, delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
bvec1 = searchclip.MVAnalyse(isb=true, delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec1 = searchclip.MVAnalyse(isb=false,delta=1,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6)
fvec2 = (trmax>=2) ? searchclip.MVAnalyse(isb=false,delta=2,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip
fvec3 = (trmax>=3) ? searchclip.MVAnalyse(isb=false,delta=3,truemotion=tm,pel=pel,sharp=shrp,blksize=bs,overlap=ovlp,idx=6) : nullclip

mvdg1 = edidbl.MVDegrain1(bvec1,fvec1, thSAD=800,idx=7)
mvdg2 = (tr1>1) ? edidbl.MVDegrain1( bvec2,fvec2,thSAD=800,idx=7) : nullclip

stage1 = (tr1==0) ? edidbl
\ : (tr1==1) ? mvdg1.merge(edidbl,0.25)
\ : mvdg1.merge(mvdg2,0.2).merge(edidbl,0.0625)

stage1a = stage1.mt_lutxy(stage1.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)
stage1b = (sharpness==0.0) ? stage1 : stage1a.repair(stage1a.repair(edidbl,12),1)

stage2 = (tr2==0) ? stage1b
\ : (tr2==1) ? stage1b.MVDegrain1(bvec1,fvec1, thSAD=400,idx=8)
\ : (tr2==2) ? stage1b.MVDegrain2(bvec1,fvec1,bvec2,fvec2, thSAD=400,idx=8)
\ : stage1b.MVDegrain3(bvec1,fvec1,bvec2,fvec2,bvec3,fvec3,thSAD=400,idx=8)

tD_2 = mt_makediff(clpo,stage2,U=3,V=3)
tD1_2 = tD_2.mt_inpand(mode="vertical",U=3,V=3).mt_deflate(U=3,V=3) .mt_expand(U=3,V=3)
tD2_2 = tD_2.mt_expand(mode="vertical",U=3,V=3).mt_inflate(U=3,V=3) .mt_inpand(U=3,V=3)
tDD_2 = tD_2.mt_lutxy(tD1_2,"x 129 < x y 128 < 128 y ? ?",U=3,V=3).mt_lutxy(tD2_2,"x 127 > x y 128 > 128 y ? ?",U=3,V=3)

stage3 = (draft==2) ? t .subtitle("Draft 2")
\ : (draft==1) ? t2 .subtitle("Draft 1")
\ : (rep1==true) ? stage2.mt_adddiff(tDD_2,U=3,V=3)
\ : stage2

(border==0) ? stage3
\ : stage3.crop(0,4,-0,-4)

return( last )
}

In both cases, I knocked off the Yadif option as I would never use it in this context. As they stand (with Tr0=2, Tr1=2, Tr2=2), both give quite decent results. The only problem area appears to in preserving uniform definition and integrity of high contrast line patterns (like the striped shirt in scene 3 of the clip I posted), notably when objects move over them. Again, dropping the EEDI2 maxd (from 8 to 4) seems to help a little.

Can’t see what parameters other than maybe the temp gauss weightings might be open for further tweaking, and I didn’t touch them. Any thoughts Didee? (hopefully other than ‘why are you still blindly screwing around with a script that wasn’t created for this purpose’ )

Writes hasty disclaimer: the above scripts are in no way intended to be taken as accepted modifications of the TempGaussMC function created by Didee for interlaced sources. They merely serve to illustrate possible approaches for applying a similar treatment to progressive/frame-based material that exhibits various forms of aliasing artifact.

[WorBry]

Didee,

After playing around with the first of the two scripts I posted above (“TempGaussMC_Mod") I discovered that setting Tr0=0 (i.e. disabling the pre-mocomp temp gauss) appeared to better preserve the definition and integrity of high contrast line patterns (like the striped shirt in 25p clip I provided), whilst still retaining good anti-aliasing effect and minimal flickering/shimmering of objects that, in the original clip, were fairlystable - more or less the outcome I have been aiming for.

I hadn’t realized that Tr0=0 was possible until I followed the script process path. So, in this case the searchclip that derives the motion vectors for the mocomp gauss becomes entirely modulated by the kernel blur (the contrasharpen bit), which I assume is entirely spatial.; possibly the reason why the edges of the stripes still appeared a bit rough.

So, starting with Tr0=1, I tried decreasing the strength of the pre-mocomp gauss, by incrementally increasing the weighting of the ‘un-softened’ dbdbl from default 0.25 through to 0.95. To my eyes, the optimum seems to be around 0.55 – 0.60.

Changing the EEDI2 maxd value from 4 to 6 (originally 8) also seemed optimal.

Question is:

a) How does one derive the weightings for the tr0=2 gauss? Simple extrapolation would give:

t1 = dbdbl.temporalsoften(1,255,255,32,2)
t2 = dbdbl.temporalsoften(2,255,255,32,2)

t = (tr0==0) ? dbdbl
\ : (tr0==1) ? t1.merge(dbdbl,0.6)
\ : t1.merge(t2,0.8568).merge(dbdbl,0.3)

Would this be correct or is the calc more involved?

b) Is it valid to make such changes without impacting the post-mo-comp gauss weightings, which seem OK as they are?


Thanks a lot.

BTW- how’s the new update coming on? I’m keen to start using TempGaussMC on my interlaced DV stuff, but will hold off if there are going to be further improvements.

[Didée]

@ Terka:

Well, where to start ... [deep breath] ...

What you bring up there is by all means valid. But do you realize that, in last instance, the result is something totally different ... ?
You can't just hop in and "change the o's less, and give more weight to the o's when doing the averaging for the b's". Consequentially, one would have to leave the o's perfectly untouched, and give ALL weights to the o's when doing the averaging for the b's. But then, this is nothing else but putting the compensations of the neighbor frames into the "b" lines of the current frame. And that's basically just what MVBob or MCBob are already doing.

The "strength" of TempGaussMC comes from the fact that changing the original data is allowed. This also allows to handle the problem of "the data missing in this frame is also missing in the neighbor frames" (vertical motion by an odd numer of pixels). For a lossless MV-Bobber this case is problematic, whereas TempGaussMC inherently uses a "prophet-and-mountain" - way to handle this case: if the prohet won't come to the mountain, then the mountain has to come to the prophet.

Also, when using the strict way of giving 100% weight to the compensations, then new problems arise from the side of motion-compensation: you then need to be *very* careful in checking whether the compensation is valid or erroneous; and ideally should also check whether the compensation for the current "b" line actually is delivering an "o" from the neighbor, or just the neighbor's "b" in turn.

In contrast, the way TempGaussMC is working is much more fuzzy, that's why it can get away with much less checking of all those things. And that's the bottom line: TempGaussMC works surprisingly good with a rather simplistic approach, and it should be left that way. Trying to make any improvements to the basic methodology will only result in something that we already have, in shape of MV/MC-Bob.



@ WorBry:

Regarding the weightings, I'm not quite sure ... perhaps the easiest way is to just use the "repeating" way (which is a valid way to get gaussian weightings for arbitrary radii), just with your preferred weighting instead:


t1 = dbdbl.temporalsoften(1,255,255,32,2).merge(dbdbl,0.6) # for gauss, this weight is 0.25
t2 = t1 .temporalsoften(1,255,255,32,2),merge(t1, 0.6) # for gauss, this weight ALSO is 0.25

t = (tr0==0) ? dbdbl
\ : (tr0==1) ? t1
\ : t2
(BTW, note that those merge-weightings in TempGaussMC are not directly related to gaussian weightings, regarding the numbers as such. They just deal to get the gaussian [1-2-1] or [1-4-6-4-1] out of the linear [..-1-1-1-..] of TemporalSoften.)

Still, for your case of AA'ing progressive input this is a try'n'error thing without obvious justification. For the case of bobbing, the temp-gauss'ing deals a very specific and necessary purpose: to average-away the bob jumping. For your case, the effect (if any) is more or less ~random~. What has to be avoided in your case is that the motion search between frames snaps in to the aliasing. And in the case of zero motion, the effect of the initial temporal averaging is exactly zero. When there is motion, then it may or may not help, IMHO that's unpredictable. My guess is that with exhaustive investigation, you might find that a weight of X is ideal for this spot, weight Y is ideal for that spot, weight Z is ideal for other spots ...

Lately I started looking at something else: Let EDI do a self-validation by using a "back-interpolation" instance, in order to judge whether a given EDI interpolation at a given place seems reasonable or not. Method: construct a frame consisting ONLY of EDI-interpolation. From this constructed frame, again construct a frame consisting ONLY of EDI-interpolation. In places where EDI does "good" interpolation, the 2nd interpolation should be reasonably close to the original frame. In places where EDI does "bad" interpolation, the 2nd interpolation can be expected to be fairly different to the original frame.
Quickly knocking together the first part (full interpolation & back-interpolation) and looking at the resulting differences, it seems pretty reasonable, but I've yet to see if one can get a tight enough grip on the problematic areas.

[WorBry]

My guess is that with exhaustive investigation, you might find that a weight of X is ideal for this spot, weight Y is ideal for that spot, weight Z is ideal for other spots ...

Yes, that's pretty much been my experience. Think I've got it down for one test clip and then apply it to another...not quite as good...more tweaking. In addition, whilst I am acheiving (on balance) better 'subjective' results than any other anti-aliasing method I've tried, as I test more material I'm coming across some instances of aliasing ('quilting' in particular') that I just cannot budge....or fudge.

This inconsistent and seemingly erratic pattern of aliasing in frame-mode DV material has been noted by others and some have suggested that it stems from the offset timing of the green CCD in the pixel shift, resulting in some color/hue edges being more affected than others, although how they know this for certain when the process involved in constructing the 'pseudo-progressive' frame has never been fully disclosed (at least for the GS400). A similar explanation has also been offered for a slight loss in chroma resolution observed in frame-mode, compared to normal interlaced.

I was thinking of playing around with chroma thresholds to see if I could get a better result, but, even if this 'green CCD timing' is the source, given the complexities involved in transforming an analogue RGB footprint into a digital YUV image, not to mention all of the other electronic jiggery-pokery going on inside the cam (internal sharpening for one), it seems a bit pointless.

So, thanks for the advice on the gauss weightings; I'll persist a bit more with my tests, more to satisfy my curiosity, but agree that the best outcome will probably be one of a subjective compromise. Probably also what the Panasonic engineers had in mind when they developed the technology, maximum vertical luma resolution and filmic-like motion cadence being the highest priority.

This Edi self-validation concept sounds interesting. Does this mean that you'll likely be holding off on the pending TempGaussMC update that you indicated earlier?

Just going back to the ‘super-resolution’ temporal filter that you eluded to (not sure if the :cool: smiley meant 'cool' or 'yeah, right' :D) ; I see Scharfis_Brain experimented with ‘super-resolution’ for image enhancement some time back and am curious as to whether he or anyone has developed this further. As I recall there is a commercial soft out there (Video Enhancer) that claims to use super-resolution. Looked at it briefly for up-scaling but was not particularly impressed.

[Terka]

Didee,
i think i understand. Thank you for your patience with my "ideas" :)

[Didée]

... (Video Enhancer) that claims to use super-resolution. Looked at it briefly for up-scaling but was not particularly impressed.

Pssst, don't tell anyone, but ... being "not impressed" is exactly what you can expect from it. ;)

Temporal Super-Resolution is a over-hyped concept. Basically it works, but "good" it works only on footage with a very certain characteristic, namely "decimated" resolution. On "blurred" resolution, it works not. The latter case is the usual one, the former is what is hard to find at all, except for one special case: interlacing. And truly, filters like MVBob, MCBob and, in a fuzzy way, TempGaussMC in fact are REAL temporal super-resolution filters.
Put shortly, in "decimated" resolution there is information missing in a frame, like the missing scanlines in interlaced footage, or due to point.sampling in the initial frame scanning process. In this case, it is ~relatively~ easy to pull the missing information from the neighbor frames, and put it into the current frame.
In the case of "blurred" resolution, like e.g. a DVD source or such, there is no information "missing". The original master has had bigger resolution, and by downscaling to the final production resolution you get "blurring", because several pixels of the bigger master are sampled-together to get one pixel of the smaller output.
In this case, it's basically so that the same blurred information is present in consecutive frames, and because of that, there is no "new" or "additional" information in the neighbours that you could put into the current. NB, the presence of compression artefacts (even very small ones) doesn't exactly help on the matter.

And that's why I had put the cool-smiley in that place: just because of "what's in a name". Something might be a TSR operation basically, but that doesn't mean that it's worthwile to name it so. But for reasons of PR and possibly making money, it's clever to have an impressing name for the child .... If you'd try to sell a primitive sharpen filter in the name of "a 3x3 pixel matrix filter", then people are bored. But, if you sell it as "Deconvolution filter, man!", then it goes "Aah!" and "Ooh!" ... ;)

[WorBry]

I've another update pending. It'll cover an adapted sharpen mode (stronger in vertical direction, since that direction gets blurred more), and an option for rep1 acting a bit better.



Any news on the pending update ? :o

[Didée]

I'm fiddling. The new stuff grew more than I had thought, and now there's need to check lots of things.

A small appetizer (http://www.mediafire.com/?wm9mxjlpn2d) of what things will look like. :)
(Interlaced source not included, construct with "source50p.SeparateFields().SelectEvery(4,0,3).Weave()" )

[WorBry]

Nice :)

[Malcolm]

Your 'appetizer' looks great!! :)

[Terka]

In comparsion to before used methods - Hut runter!
For people who want to buy an camcorder, there will be new question 1080@50i or 720@50p when final res. is 1080@50p.

[Didée]

Almost there, it's almost there. It's a pleasure to see what it pulls out of some difficult content. Especially with really sharp & detailed sources, the differences are astounding.

Wanna see some filters trying their luck at Stockholm (http://www.mediafire.com/?mzdzmbyjnmg)? Amazing!
(Sorry, forgot to reset the framerate from RawSource's default of 25fps to the real 59.94fps ... but hey, the slo-mo is good to make the bobbing issues even more obvious);)

Just a bit more twiddling with a few smaller things, and TempGauss should go beta.

[WorBry]

Lookin’ good; hey whilst you’re still fiddling with the new version, why not also give it a shot with the ‘CrowdRun’ HD sequence from:

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/

Plenty of moving detail there plus some conspicuous bob-shimmer (e.g. the tree tops)

I’ve put up matched (1 second) 1080/50i, 1080/50p and 720/50p HuffYuv-YV12 samples:

http://rapidshare.com/files/123222835/ParkRun_1080_50i_YV12.avi.html Note: Top Field First

http://rapidshare.com/files/123226654/ParkRun_720_50p_YV12.avi.html

http://rapidshare.com/files/123230935/ParkRun_1080_50p_YV12.avi.htm

Intrigued by the 'new question' posed in Terka’s last post, I was in the middle of doing a little comparison (purely subjective) of bob-deinterlacing 1080/50i (TempGauss_alpha3, MCBob, YadifMod-NNEDI) versus upsizing 720/50p (NNEDIResize_YV12/LimitedSharpen) to 1080/50p, but if you’re nearly there with alpha4 or a beta, it seems it bit redundant now. Suffice it say that encoding time for TempGaussMC_alpha3 at default (Tr0=2, Tr1=2, Tr2=1, edimode="NNEDI") tipped one hour (for 50 output frames) on my AMD XP2800+, 1GB DDR RAM; that would be more 60 hours for processing 1 minute of 1080/50i footage. Imagine if the source was AVCHD. For HD sources at least, the faster Yadif edi mode (with say Tr0=1, Tr1=1, Tr2=1) would seem a more practical proposition (encoding time 9 min 51 sec). MCBob 0.3u ran at 28 min 47sec and YadifMod-NNEDI 3 min 2 sec (....plus the bob-shimmer). On the upscaling side, NNEDIResize_YV12 plus a simple LanczosResize took 7 min 42 sec; not bad quality but more blurred than the bob-deinterlaced outputs. Hadnt got around to LimitedSharpen (Edit: NNEDIResize_YV12 plus LimitedSharpen (dest_x=1920, dest_y=1080, Smode=1, strength=40) took 8 min 43 sec)

Edit: Ooops, noticed that I'd labelled the uploaded samples ParkRun instead of CrowdRun. Ah well, what's in a name.

Edit2:If anyone’s interested :rolleyes:, here are sample outputs (first 5 frames) from the comparative tests:

http://rapidshare.com/files/123691501/CrowdRun_1080_50i_bob-deinterlace_tests.zip.html

http://rapidshare.com/files/123628340/CrowdRun_720_50p_upscale_tests.zip.html

Since TempGaussMC incorporates MVDegrain (limited to Tr2=1 in these tests), I also tested the other methods with and without MVDegrain1. Maybe folks more experienced with Limited Sharpen, or maybe See-Saw, could improve on the up-scaled outputs.

Edit3: Here also is a small (file size) direct (cropped) comparison of:

Reference 1080 50p
TempGaussMC_alpha3 (221 NNEDI)
MCBob 0.3u
NNEDIResize_YV12 + LimitedSharpen

http://rapidshare.com/files/123702365/CrowdRun_Ref_TGMC_MCBob_NNEDIResizeLS.avi.html

Perhaps not the best example to demonstrate shimmer/flicker supression but it highlights relative preservation of definition.

[2Bdecided]

Wanna see some filters trying their luck at Stockholm (http://www.mediafire.com/?mzdzmbyjnmg)? Amazing!
(Sorry, forgot to reset the framerate from RawSource's default of 25fps to the real 59.94fps ... but hey, the slo-mo is good to make the bobbing issues even more obvious);)I love the steps near the end of that footage - even watching the footage native on an interlaced display they look very "wrong" yet TGmc(full) does a brilliant job of making them look as they should.

Just a bit more twiddling with a few smaller things, and TempGauss should go beta.Looking forward to it! (wish I had a faster machine though! :( ).

Cheers,
David.

[Malcolm]

@Didée,
your sample is absolutely stunning! Really looking forward getting my hands on the beta! :) :)
However, besides removing nearly all the flicker and showing much more detail than the other contenders, there are some minor areas with errors.
Here are 2 frames for illustration:
http://img176.imageshack.us/img176/8955/tempgaussmc1qd0.th.jpg (http://img176.imageshack.us/my.php?image=tempgaussmc1qd0.jpg) http://img253.imageshack.us/img253/4813/tempgaussmc2hs9.th.jpg (http://img253.imageshack.us/my.php?image=tempgaussmc2hs9.jpg)
I hope this will help you to eliminate them.

Greetings,
Malcolm

[LaTo]

@Didée
TempGaussMC is amazing! Thanks a lot for this stuff :thanks:

But I have noticed one problem, TTMC produce some strange lines... It look like residual combing, but it isn't because it's horizontal and... vertical.

Screenshots of my problem:
http://latoninf.free.fr/lines/

Maybe you could fix this, I hope... :cool:

[2Bdecided]

Ouch.

There's no source clip to be sure, but I think this is the inherrant problem with deinterlacing.

Very fine vertial detail can be very fine vertical detail, or fast movement (including a flash of light!). The two cannot be disambiguated.

mcbob errs on one side, ttmc on the other. mcbob messes up very fine detail, ttmc messes up very fast changes.

Still, magician Didée to the rescue! Maybe there's a threshold to tweak or a blur weighting to adjust somewhere...

(A source clip might help)

Cheers,
David.

[Didée]

Those effects are known, and mostly resolved.

Malcom: The detail loss is because too much structure may get lost during the 1st (not MC'ed) gaussian stage. (BTW, it wasn't only the pole ... also much of those little waves on the water were smeared away.)
=> Solved, by giving a bit more bias towards the original.

LaTo/2BDecided: What you're seeing there is MVTools when it actually misses scenechanges. (Light flashes can be considered as such, in this context).
=> Probably solved, by lowering SAD thresholds in some MVTools-filters.

(I hope it'll work out reliably enough ... generally, SAD is only a rough (and relatively poor) measurement: in high detail/high contrast areas, even related blocks can have a rather big SAD, whereas in low detail/low contrast areas, even unrelated blocks may have a rather low SAD. Well, what to do. SAD really is not a versatile measure, still in MVTools it is *THE* decisive element. TempGaussMC actually has to play one or two severe tricks to sail around the darn SAD cliffs...)

[LaTo]

What you're experiencing is MVTools when it actually misses scenechanges. (Light flashes can be considered as such, in this context).
=> Probably solved, by lowering SAD thresholds in some MVTools-filters.

I have made a quick-fix with SAD & SCD settings (attachments).

With TempGaussMC_alpha3M(scd1=100) the lines go out :thanks:

[Didée]

You're turning the wrong knob. Lowering thSAD in MVDegrain is not the preferred solution ... you could lower it to,say, '100' - hooray, no more artefacts!! -- but oh dear, why there's all this bob flickering again? ;)

The culprit is "thSCD1", which defaults to 400, which is way to high for the prepared searchclip ... that one is "flattened" on purpose, and reasonable scenechange values for such a clip are e.g. "thSCD1=175,thSCD2=100". <--Put these into all MVDegrain calls if you can't wait for me posting the beta.

[LaTo]

You're turning the wrong knob. Lowering thSAD in MVDegrain is not the preferred solution ... you could lower it to,say, '100' - hooray, no more artefacts!! -- but oh dear, why there's all this bob flickering again? ;)

The culprit is "thSCD1", which defaults to 400, which is way to high for the prepared searchclip ... that one is "flattened" on purpose, and reasonable scenechange values for such a clip are e.g. "thSCD1=175,thSCD2=100". <--Put these into all MVDegrain calls if you can't wait for me posting the beta.

Previous post updated!

The problem go away with SCD1=100... If >100 the lines is present.

:thanks:

[Didée]

The problem go away with SCD1=100... If >100 the lines is present.

That's bad news. Just figured that on detailed material (CrowdRun), thSCD1=180 (for blocksize=8) resp. thSCD1=240 (for blocksize=16) are good values. If you need a value of 100 for your footage, that means that there's probably no smart handling of that issue in sight. (With '100' there is big danger that some frames won't get filtered at all ... try on 'ParkRun', you'll see....)

Darn SAD. Darn fixed-dumb-thresholded-solutions. The good solutions are those that work without any thresholds. Solutions that essentially rely on thresholds are not solutions, just case-dependent fiddlework ... like almost any filter available for Avisynth. :rolleyes:

[WorBry]

Cmon guys, we've had the appeteasers, now let Chef Didee serve up the main course and then you can pick at the food if you like - my stomach's rumbling :D

[yup]

LaTo & Didée!

May be need try search=3 in MVTools. I am last time try write script for remove pulse noise and found that search=3 give more better result than search=2. Also I try decrease thSAD with search=2 but without result. I agree search=3 decrease speed, but give better quality MV.

yup.

[Didée]

Yeah, exhaustive search, sure. Exhaustive is always the last ressort when everything else fails. Next step beyond exhaustive is: kick all filters to dustbin, and arrange the fields' scanlines manually with PhotoShop. Blargh.
With "light" settings, TempGaussMC can run in range of "half realtime", perhaps full on beefy machines. Exhaustive search doesn't quite fit into the picture.

But BTW ... in MVTools, the "2nd best" motion search (short of "exhaustive") is search=2, "diamond search". OTOH, compare with x264: in x264 there is also "diamond search" available ... but there, it's about the cheapest and lowest-quality ME method you can only choose. Hmh.

Dunno if I'm missing something here, but my feeling is that MVTools is in severe need of some better motion analysis.

[LaTo]

With "light" settings, TempGaussMC can run in range of "half realtime", perhaps full on beefy machines.

ARGH, I bought a E8400 last week... and TempGaussMC run +- 2fps on SD footage :eek:
(with defaults settings)

[WorBry]

So try a "lighter" setting, maybe (tr0=1, tr1=1, tr2=1, EdiMode="EEDI2"). Should at least double the speed, and with EdiMode=Yadif, maybe five-fold.

[Didée]

With defaults, of course. Default is "NNEDI", and NNEDI on its own already is pretty slow. Fast is Yadif, or just plain bicubic interpolation instead of any EDI.
Perhaps the estimate was a bit too optimistic, but ... with my archaic hardware, the usual quick guess is that a higher-end machine is 10 or 20 times faster than mine ... (lately, some suggested x264 settings, running 6-7fps on a Q9450, did run at 0.2-0.25fps for me) ... out of the game, I am.

[Malcolm]

Malcom: ... (BTW, it wasn't only the pole ... also much of those little waves on the water were smeared away.)Oh, i've noticed that as well. But that was _so_ obvious, pointing that out would have been a bit insulting to you, wouldn't it?! ;) :D

[kandrey89]

OK, I'm confused. TempGaussMC is a deinterlacer right? So what stage of development is it in, where can it be obtained?
If it's so good why doesn't it have it's own dev page?

[sidewinder711]

If you are reading this thread carefully from the beginning, you will find out that it is not only a deinterlacer. It's in its "alpha" stage or a bit further... and you can download/copy it from article #13 of this thread.:rolleyes:

[kandrey89]

Saw the code, but I don't know avisynth, and don't know any necessary skills to utilize that code :/
Will have to wait for a plugin for VirtualDub, if that's possible :/

[WorBry]

Saw the code, but I don't know avisynth, and don't know any necessary skills to utilize that code :/

Do yourself a favour. It's not that difficult:

http://avisynth.org/mediawiki/Main_Page

Will have to wait for a plugin for VirtualDub, if that's possible :/

TempGaussMC is a scripted function that utilizes a number of AVISynth plugins (filters) that have no VirtualDub equivalent. I think I can safely say that the possibility of a VirtualDub plugin, or series of plugins, that perform(s) the same function is more than remote.

[Terka]

Dunno if I'm missing something here, but my feeling is that MVTools is in severe need of some better motion analysis.

There are some papers on the net...

[Terranigma]

Would it be possible to use/construct TempGaussMC for deinterlacing only without denoising?

[Terka]

you can join original and computed lines together

[WorBry]

Would it be possible to use/construct TempGaussMC for deinterlacing only without denoising?

Well you could disable the 'post gauss' MVDegrain denoising (Stage 2) by setting Tr2=0, but the mo-comped temporal gauss itself is basically a MVDegrain temporal denoise that has been warped into a gaussian distribution (Stage 1).

As Didee stated earlier:


And a *denoiser* is all that this script is, indeed. A denoiser that also "denoises" bob flickering. ;)

[Didée]

Hi ... there's some technical problem with my ISP, currently I'm without internet connection at home. :|

The noise reduction of TempGaussMC is an inherent property of the used method. Trying to avoid this "feature", you'll open several cans of worms that TempGaussMC so explicitly tries to keep closed ... and in the end you would have it stumbling in the very same pitfalls which the other methods regularly fall in. Better let it levitate over those pitfalls, at the expense of reducing noise.

If you actually enjoy the comfy ambience of those pitfalls, then use something else, but not TempGaussMC. :)


You might try something among the lines of first reducing noise in the interlaced footage, deinterlacing the denoised material, then re-adding the removed noise ... like

interlaced_clip

NR = FFT3DFilter(sigma=plenty,interlaced=true)

TGMC = NR.TempGaussMC()

NRD = mt_makediff(interlaced_clip,NR)

TGMC.mt_adddiff( NRD.doubleweave(), U=2,V=2 ) # or NRD.bob()

, with FFT3DFilter as an example for an interlace-aware denoiser. The results will depend on how properly the denoiser does its job.

[WorBry]

The noise reduction of TempGaussMC is an inherent property of the used method. Trying to avoid this "feature", you'll open several cans of worms that TempGaussMC so explicitly tries to keep closed ... and in the end you would have it stumbling in the very same pitfalls which the other methods regularly fall in. Better let it levitate over those pitfalls, at the expense of reducing noise.


I guess this would be an example of one variety of ‘worm’ that emerges from ‘opening the TGMC can’. Did a little comparison of:

TGMCa3 (Tr0=2, Tr1=2, Tr2=2) # i.e. with ‘internal’ MVdegain2

TGMCa3 (Tr0=2, Tr1=2, Tr0=0) + MVDegrain2 # same MVAnalyze/Degrain parameter settings as ‘internal’

TGMCa3 (Tr0=2, Tr1=2, Tr0=0) + hqdn3d(2) # my hitherto preferred (temp-spatial) denoiser for MV/MC-Bobbed DV sources

TGMCa3 (Tr0=2, Tr1=2, Tr2=2) + RemoveGrain(mode=2) # mild ‘post’ spatial degrain

Here’s the results:

http://rapidshare.com/files/125536164/TGMC_222__vs_TGMC_220_vs_TGMC_220___MVDG2_vs_TGMC_220___hqdn3d2_vs_TGMC_222_RG2.avi.html

Note the relative stabilities of the B&W spotted pattern on the cushion with the red square. With TGMC 222 (i.e. ‘internal’ MVdegrain2) the pattern is well calmed. However, apply the MVDegrain2 after TGMC and some shimmer/vibration starts to appear again. Likewise with hqdn3d, and slightly more so. Apply a light spatial degrain (RemoveGrain mode=2) after TGMC (with internal MVDegrain2) and the ‘worms’ really get wiggling.

So, if I understand the levitation trick correctly, the ‘internal’ MVDegrain avoids regenerating shimmer (one such pitfall) by utilizing the same motion analysis as the denoised feed for mo-comped gauss, but applying a lower thSAD value, so avoiding interference with the directed (high contrast) denoising that has been applied by the gauss. Added to which is an internal repair mechanism that corrects the MVDegrain defects. Correct?

Hope you rectify your connection problem.

Edit: Doh, just noted that merely disabling the internal MVDegrain (Tr2=0) itself results in return of the shimmer. So the internal MVDegrain is actually an integral component of the flicker supression. I guess I should have realized from Didee's comment above :rolleyes:. I've edited the uploaded comparison clip accordingly.

[Mystery Keeper]

Oh my. It connects lines so neatly! I'm not very good at avisynth, so I don't really understand what's happening in the script. For me you guys are wizards ^_^

[WorBry]

My friend, you dont really need to understand whats happening in the script, its a complete function to be used as such and Magician Didee is the sole author.

[Mystery Keeper]

I know. I'm already successfully using it ^_^
By the way, I usually process MPEG2 musical videos and I'm used to low speed. right now I'm encoding one at 0,5 fps ^_^' So don't you guys complain. Quality certainly worth it.

As for anti-aliasing, my choice is still EEDI2().TurnRight().EEDI2().TurnLeft() after cropping and before resizing. As it almost destroys no details, the result is much smoother than the same method with nnedi.

[Mystery Keeper]

Had it screw up large detailed and static frame in anime, over which a strongly interlaced spot was applied. MCBob handled that frame gracefully. Can not give snapshots now, but shall later.

[WorBry]

As for anti-aliasing, my choice is still EEDI2().TurnRight().EEDI2().TurnLeft() after cropping and before resizing. As it almost destroys no details, the result is much smoother than the same method with nnedi.

Tried that, and the NNEDI version, but it doesnt deal very effectively with the type of aliasing (notably 'quilting' or 'moire effect') that I encounter with my pseudo-progressive material.

[Didée]

Beta 1. (http://home.arcor.de/dhanselmann/_stuff/TempGaussMC_beta1.rar)

(Fixing update: BinomialBlur() leaks memory, replaced it with some equivalent filtering.)

[WorBry]

Wow, and just when I thought I'd got my head around the scripting of TempGaussMC_alpha3.

Ran a few tests and needless to say the results are incredible.

Glad you put in EEDI2maxd as an adjustable parameter, as I find the occasional hole in my 'stripey shirt' tests at default maxd=8; adjusting to maxd=6 seems to resolve that.

I see the default sharpness been increased a little i.e from 0.25+(tr1+tr2)/8. to 0.25+(tr1+tr2)/6. which (at default Tr1=2, Tr2=1) represents an increase from 0.625 to 0.75. I know the sharpness can be adjusted to personal taste, but just wondered if there is an empirical reason for the change i.e. more blur that needs to be countered?

[2Bdecided]

It's sharper and faster, but I'm getting slight combing-like artefacts. There are parts that were blurred in the original (either out of focus, or moving) which alpha3 kept blurred. The Beta versions adds little lines or steps within the blur.

Would it help to upload something to show this?

Cheers,
David.

[Didée]

@2Bdecided:
Yes, please. It's probably the "SVthin" thingy (try to set that to 0.0), but checking is better than guessing.
The faster performance is because the blocksize/overlap defaults now are 16/8, before they were 8/4.


@ WorBry:
The default is sharpness=0.75 for the spatial SLmode=1|3, or sharpness=1.5 for the temporal SLmode=2|4.

In theory (i.e. on a "perfect" syntetic showcase), it would need sharpness=4.0 (for Smode=1) or sharpness=2.0 (for Smode=2), in order to completely restore the blur-down of the temporal gauss. So the sharpness defaults are still on the conservative side of things.

[2Bdecided]

SVthin=0.0 dramatically improves it. It's still a little worse than before, but subtle.

See the finger nails on the boy's left hand (i.e. the hand on the red bar)...
http://rapidshare.com/files/126300644/1440x1080i50tgmcb.m2v.html

Cheers,
David.

[Didée]

Seems like it's one of the dangerous downsides of using the mc-compensated neighbors for limiting. The "flattening" of the search-clip makes the reckognition of bad compensations less reliable ... however the flattening is ultimately needed. Without it, MVDegrain would do almost nothing-at-all to the bobbing parts ...

I'll have a look at it. For the moment, here's some justification for why things are like they are in beta-1 :

http://www.hochladen.info/images/upload12/XZuDK47Z5dogwLs/thumb.png (http://www.hochladen.info/image/XZuDK47Z5dogwLs/) ( top: progressive reference | YadifMod(NNEDI) - bottom: TGMC alpha-3 | TGMC beta-1 )

Beta-1 is not only "sharper" ... it really recovers more true detail (detail that is 'not present' in a given field but only in its neighbors can not be recovered by the alpha versions, due to the spatial limiting), and it even is more stable than the previous alphas.


Edit:
With your sample, I can not (or hardly) confirm a problem with the new beta version as such. The artefacts e.g. on the fingernails are just a coincidence: they're worse with EEDI2 (beta's default, faster), and less prominent with NNEDI (alpha's default, slower). Also they're a bit worse with 16/8 (beta's default, faster), and less so with 8/4 (alpha's default, slower).
It seems in this case it's mostly a matter of the changed default settings.

Hmmh ... perhaps I should make make ALL parameters MANDATORY with NO DEFAULT settings, so everyone HAS TO choose his own poison ... :D

[2Bdecided]

That's a great comparison. It's very useful having the progressive source for testing - not something I have the luxury of with HDV (otherwise I wouldn't need TGMC!).

Thanks for taking a look at it Didée. I do like the extra sharpness of beta-1, though my HDV footage rarely has anything pixel sharp in it to start with (other than noise and encoding artefacts!).

Cheers,
David.

[Terranigma]

perhaps I should make make ALL parameters MANDATORY with NO DEFAULT settings, so everyone HAS TO choose his own poison ... :D
Or change the defaults to the most optimal settings and let users be able to alter them for speed over quality.

[Didée]

There is no such thing as "most optimal settings".

Par ex.: "EdiMode".
Yadif is blazingly fast, sometimes it looks okay, sometimes it looks terrible. NNEDI is very slow, often looks good, but I could show you cases where even NNEDI's neural network *fails*, yet the cheapo-quicko Yadif looks brilliant(!) in comparison. EEDI2 is king & pope when it comes to connecting diagonals and thin lines, but it also mis-guesses quite often, and is prone to give the dreadful "oilpaint look" (same as Yadif, but even more so). Ditching e.d.i. completely and just using plain bicubic interpolation will - in many places - look as good as any other setting, but in some places it'll cause aliasing (depending on vertical motion, when neighbor fields happen to not contain the necessary information.)

And now you tell me, which is the "most optimal" setting for EdiMode?

Yeah, exactly. Same goes for all other parameters.

Current defaults should be in reasonable mid-range. And altering the settings for trading speed vs. quality is exactly what the user is supposed to do, anyway. :)

[murrsturr]

Thanks for this great filter Didee. I am presently using it, and it only, on sd digital TV captures with great results.

With all settings default, save for edimode, on a Q9300 with 4 gigs of ram with multi-threading enabled (I am using SetMTMode(2) prior to calling your function) I am getting the following FPS averages:

EED12=4.7+
NNEDI=5.8+
Yadif=8.7+

With the lighter settings WorBry suggested (thanks WorBry) a few posts back I am getting 12.5+ fps with Yadif. So on my setup "mid-range" default EED12 is actually slowest but I am more than happy with the results that Yadif is giving me thus far. I am looking forward messing around with this much more.

Thanks again!

[WorBry]

With my home DV sources, I’m also noticing some ‘edge serration’ and, I’d dare say, a little distortion/erosion in places where objects are moving over objects/ high contrast edges.

Here are two examples from the test clip that put-up in Post #30

http://rapidshare.com/files/126551745/TGMC_NNEDI_222_beta_vs_alpha3.avi.html

Compared were (left to right):

TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI)
TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI, blocksize=8)
TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI, SVThin=0)
TGMC-beta (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI, blocksize=8, SVThin=0)
TGMC-a3 (Tr0=2, Tr1=2, Tr2=2, edimode=NNEDI)

Note the finger as it passes over the railings (frames 8 – 24) and thumb and forefinger in frames 42 – 49.

With TGMC-beta, reducing the block-size from default 16 to 8 definitely helps a little. Not too sure if setting SVThin=0 makes much of a difference, if any, in this case. But of course, without a progressive reference source it is difficult to gauge what represents true detail (or lack of it) from the ‘original’ and so there’s no telling what the slightly more blurred result with TGMC-alpha3 actually masks.

So, I guess it boils down to what one considers the more subjectively appealing….at normal playback speed that is. Generally, from my tests so far I do prefer the overall crisper look of the beta.

[Mystery Keeper]

I suggest this thread renamed "TempGaussMC deinterlacer".

[Didée]

I rather suggest spanking Didée, until he gets off his duff and makes a dedicated thread for it ... :)

(Which is what I'll probably make ... when I've a little more free air again.)

[WorBry]

With my home DV sources, I’m also noticing some ‘edge serration’ and, I’d dare say, a little distortion/erosion in places where objects are moving over objects/ high contrast edges.

Here’s another example (from the test clip I put-up in Post #30).

This time I ran a parallel series with edimode=EEDI2.

http://rapidshare.com/files/126935573/TGMC_EEDI2_222_beta_vs_alpha3_test2.avi.html

The series shows quite marked ‘combing’ on the boy’s hand with TGMC_beta and to a much lesser degree with TGMC-alpha3. Reducing Blocksize= 8 and SVThin=0 together brought a little improvement but not complete resolution. Although not shown in this series, reducing the EEDI2maxd value had no effect.

With edimode=NNEDI, the effect was rather more subtle, but distinct combing is still visible in parts (see Frame 5)

http://rapidshare.com/files/126936026/TGMC_NNEDI_222_beta_vs_alpha3_test2.avi.html

I think anyone looking at the ‘EEDI2’ series in particular would, at face value, assume this to represent residual interlace combing and if it is definitely not, then what is it – interpolation error that slips through the net, aliasing?

More to the point, what other tweaks available in the beta might be applied to avoid it ?

Thanks.

Edit: Seems to be arising somewhere in Stage 1a, as the Stage 1 output looks OK.

[Didée]

The basic problem is that motion compensation can't be successful in such spots. Those twiddling finglers of the little man are too different from one frame to the next, so MC can't do much useful there. At best, MC should do *nothing* in such areas ... but that's one example of where it is highly difficult to separate "the good" from "the bad" ...

1st, lowering blocksize/overlap does help, like you already found. Smaller blocksize can adapt better to such chaotic motion.

2nd, the "rep" reparations play a big role. Those deal for accepting only bob-typical vertical differences from the temporal filters (a bob-typical difference is "thin" in vertical direction). However in the areas you showed, the artefacts from motion compensation do form differences with quite similar characteristics as bob-typical differences do have, that's a problem.
You can try using lower repX values to reduce those artefacts. repX=1 is most aggressive in avoiding artefacts, repX=5 is most relaxed. But OTOH, too aggressive repX values may introduce bob flicker in the output again. It's a trade-off that's also content related. Some average footage may get away with more aggressive repX values; extremely detailed footage like the "Stockholm" panning scene is a nightmare that requires very relaxed reparation.

3rd, SLmode is also related. The old mode (SLmode=1 or 3, spatial) is more safe to avoid motion-related artefacts, but in some places it can inhibit full detail recovery, or even can result in slight flicker re-introduced into the output.
The new mode (SLmode=2 or4, temporal) theoretically are the true thing, since they allow for full detail recovery and maximum stableness in static or low-motion areas. But, in areas where motion compensation wasn't successful, the temporal mode allows that the sharpening expands into wrong pixel values. It's a trade-off.


In the end, there's no holy grail in sight, and trade-offs have to be made. For general denoising and/or motion compensating, the consens is to accept only differences that are "small enough", since using big differences usually introduces artefacts.
However, in the case of "denoising" bob flicker, it is a MUST to accept big local differences, and it's this very fact why TempGaussMC looks as good as it (mostly) does.
In light of the fact that TempGaussMC does exactly that what most other filters are too anxious to do, I'd say that the potential artefacts are rather little.

Besides, I'm not sure if I would note the artefacts of your example when viewing in realtime. Flicker in almost-static areas is so much more obvious than a few stray pixels that are located in funky-motion areas.


For orientation, here's a table with Beta1 defaults, alpha3 defaults, and the corresponding values to make beta1 behave (mostly) like alpha3:


|Default |beta1=> |Default |
Parameter |beta-1 | alpha3 |alpha3 |
----------+--------+--------+--------|
tr0 | 2 | 2 | 2 |
tr1 | 2 | 2 | 2 |
tr2 | 1 | 1 | 1 |
EdiMode | EEDI2 | NNEDI | NNEDI |
rep0 | 4 | 1 | true |
rep1 | 0 | 0 | [true] | <- alpha's "rep1"
rep2 | 4 | 1 | [---] | <- is beta's "rep2"
blocksize | 16 | 8 | 8 |
overlap | 8 | 4 | 4 |
Smode | 2 | 1 | (1) |
SLmode | 2 | 1 | (1) |
SLrad | 1 | 2 | (2) |
SVthin | 1.0 | 0.0 | --- |
Sbb | 1 | 0 | --- |
thSAD1 | 600 | 800 | (800) |
thSAD2 | 300 | 400 | (400) | (MVTools' standard default)
SCth1 | 180 | 400 | (400) | (dto.)
SCth2 | 98 | 130 | (130) | (dto.)

[WorBry]

Thanks for the explanations and the tweak table. In addition to reducing blocksize to 8, disabling (=0) both sbb and SVThin seems to bring about the most noticable improvement.

[Yoshiyuki Blade]

Hmmm, x264 in MeGUI blows up using the beta, unless I do a lossless pass using Vdub first (via lagarith) and encode that. Is that normal?

It might be a huge amount of ram usage or something. I'm testing on a 1080 clip bobbed to 60p. On my 2GB lappy, I can't even complete a lossless pass. Vista complains about low memory and ultimately crashes Vdub.

The results are awesome though :D.

[Didée]

I've never used MeGUI (yes, indeed), so I can't tell. But every now & then, there are reports that seem to indicate that MeGUI sometimes might become instable with complex or ressource hungry scripts.

For me, if something works in VirtualDub, then it works. If it doesn't work in MeGUI, then it's not a problem with the script ... :whistle:

Processing 1080ish HD, otoh, is ultimately beyond what my hardware allows (2.6 GHz singlecore /w microscopic L1/2 Cache, 512MB RAM), so I don't test for that at all ...

[Mystery Keeper]

Being written using .NET MeGUI sucks by definition. It crashes when I'm just trying to add new job with complex script. I only use it for some preparations lately.

[Yoshiyuki Blade]

I've never used MeGUI (yes, indeed), so I can't tell. But every now & then, there are reports that seem to indicate that MeGUI sometimes might become instable with complex or ressource hungry scripts.

For me, if something works in VirtualDub, then it works. If it doesn't work in MeGUI, then it's not a problem with the script ... :whistle:

Processing 1080ish HD, otoh, is ultimately beyond what my hardware allows (2.6 GHz singlecore /w microscopic L1/2 Cache, 512MB RAM), so I don't test for that at all ...

Ah I see. Yeah it might be problematic when working with HD material if you don't have enough RAM. I think the lossless process uses up to 1.6GB, and transcoding the lossless clip to x264 right now is using 1.5 GB :eek:

Being written using .NET MeGUI sucks by definition. It crashes when I'm just trying to add new job with complex script. I only use it for some preparations lately.

Ouch, that kinda sucks for me. I wonder how using a standard command line interface will turn out.

[Mystery Keeper]

Good thing is that it stopped crashing with the last update. Can use it as automate again. But editor of choice is still AvsP.

[Didée]

Hmh. Did some specifc testing, and it seems that Binomialblur() from Variableblur.dll is leaking some memory when variances >1.0 are specified. That's not good.

[Mystery Keeper]

And MeGUI still does crash =/

[Didée]

I've uploaded a new version of TempGaussMC beta-1. Functionality is exactly the same, but the script no more uses VariableBlur.dll, because of BinomialBlur's memory leakage.

(A test with a simple script that uses three instances of BinomialBlur (like TempGaussMC does, on average) did leak 250MB over the curse of 60'000 frames ... the fixed beta-1 is stable, memory usage stays constant.)

Beta 1, updated (http://home.arcor.de/dhanselmann/_stuff/TempGaussMC_beta1.rar).

[Wilbert]

I've uploaded a new version of TempGaussMC beta-1. Functionality is exactly the same, but the script no more uses VariableBlur.dll, because of BinomialBlur's memory leakage.
Did someone contact the author of VariableBlur about this?

[Yoshiyuki Blade]

Hmm, this version causes x264 to use only one core. It hasn't crashed yet tho :p

EDIT: Fixed a dumb typo and... Actually, it crashed just now lol. Gonna play around with it and see if it was something I did. It may be an experimental build of x264 I'm using.

EDIT2: Running a lossless pass with Vdub on the 2GB lappy. Vista notified me of low memory once, but the process still seems to be going. Hopefully it can complete the process. That's definitely an improvement over before. I supposed the MeGUI+x264 crash is just due to the complexity of the avs script. Update: The lappy successfully completed the process without crashing.

[murrsturr]

I had originally attributed what I thought to be a memory leak to Megui. Its core had been updated the same time this beta came out and it was only apparent after I used larger files in Megui. Whoever was the culprit, I'm glad to report beta 1 now working fine in Megui\XPsp3.

thanks Didee.

[Yoshiyuki Blade]

Here's a sample that I did:

http://www.mediafire.com/?m4yn0fomm4j

1080i from the camcorder bobbed to 1080p 60fps, and lanczos resized to 720. Used edi mode nnedi. I havent compared it to other bobbers but Yadif. Yadif failed horribly on the long cable that goes across the water, while tempgaussmc renders it almost perfectly. The overall sequence is also much steadier in general.

I'd upload the 1080p version if it wasn't over 100MB (close to 200 MB actually). That one looks even better, though it requires a lot of CPU power to decode at full speed.

[WorBry]

Didee,

I see that the beta incorporates a measure to offset a slight chroma shift caused by MVDegrain when Pel >1 (as it is by default, Pel=2). In that case, would your recommendation be to apply this corrective measure to MVDegrain in any context? Taking, for example, standard 'standalone' MVDegrain2, would this be correct:

backward_vec2 = clp.MVAnalyse(isb = true, delta = 2, truemotion=true, pel = 2, overlap=4, sharp=1, blksize=8, idx = 1)
backward_vec1 = clp.MVAnalyse(isb = true, delta = 1, truemotion=true, pel = 2, overlap=4, sharp=1, blksize=8, idx = 1)
forward_vec1 = clp.MVAnalyse(isb = false, delta = 1, truemotion=true, pel = 2, overlap=4, sharp=1, blksize=8, idx = 1)
forward_vec2 = clp.MVAnalyse(isb = false, delta = 2, truemotion=true, pel = 2, overlap=4, sharp=1, blksize=8, idx = 1)
mvdg2=clp.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,idx=1)
chrcor = mvdg2.mt_lutxy(clp,"x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * - ?",Y=2,U=3,V=3)
Return(chrcor)

If so, perhaps other functions that utilize MVDegrain, like Temporal Degrain, should be modified accordingly? Maybe it should be reported as an MVTools bug, if it has not already.

[sidewinder711]

I've uploaded a new version of TempGaussMC beta-1. Functionality is exactly the same, but the script no more uses VariableBlur.dll, because of BinomialBlur's memory leakage.

Only FYI:

During the last week I used TempGaussMC_beta several times and everything worked without any problems.
Yesterday I made an update to
- TempGaussMC_beta1,
- VirtualDub 1.81 latest build and
- Avisynth 2.58 RC2.

Now, after loading an avs file into VirtualDub (more or less only using TempGaussMC_beta1 with default values), the screen stays black. If I push the start button, VD/Avisynth crashes due to an "CAVIStreamSynth" error.

After searching the forum, I have learned that this a quite general error message. The error can be based on scripts, codecs, hardware parts...

I went back to TempGaussMC_beta ... and don't have any problems until now. Because the error message can be based on so many items, I will investigate the aforementioned problem a little bit deeper and keep you informed if I'm able to figure out any other reason than the new script.

[Didée]

@ sidewinder:
Strange. The only change was to replace BinomialBlur() with GaussResize() or RemoveGrain(11).GaussResize(). Can you check if the following simple script also fails:
source
w = source.width()
h = source.height()

source.gaussresize(w,h,0,0,w+0.0001,h+0.0001,p=3)

Another vague possibility: If you have more than 2GB of RAM, squid_80 reported a problem (http://forum.doom9.org/showthread.php?p=1158423#post1158423).


@ Worbry
Not sure if it's a bug per se in MVTools, it could be just some rounding issue going unlucky. The color shift is very slight when pel>1 & overlap=0, and very slightly more when pel>1 & overlap>0. The actual shift seems to be in range +/-2, so it could be that +/-1 comes from rounding in the subpel interpolation, and +/-1 comes from the block summation code.
However I'm in no way sure about this, it's just guessing.

As a general measure against the problem it's a bit too harsh, since it shifts every pixel back towards its original value. Now, what if you have some *slight* chroma noise in your source that you expect to be removed ... it's very likely that this measure will just restore the chroma noise that MVDegrain had successfully removed.

People deal with this for a long time now, and there were not much complaints about it (Terranigma once asked me in a PM).
I just included it here because with some of the samples I used, the shift was quite noticeable (e.g. on the water in the "Stockholm" sample), and I didn't want to have reports like "Hey, TempGaussMC messes up my colors!". ;)

[sidewinder711]

@Didée
I checked your code above on 2 machines with nearly the same VD/Avisynth configuration... no problems. BTW: I do have 4 gb RAM, but in all my scripts is "SetMemoryMax=1024". I made some quick tests:

- I tested TGMC_beta1 on my old machine... no problems loading a source file.
- Then I did the same on my new machine, which I usually use for encodings. Loading the TGMC_beta1 avs file for the first time, no problem. But re-loading the same script caused the problem that no film was loaded, the screen stayed black, but no crash.

All of the above mentioned crash problem occured as I had created a joblist in VD and VD was working through the jobs during the night. In the morning half of the jobs were done, the other half was errored out. Re-loading the "error scripts" caused these crashes I mentioned above.

Atm, it seems to me that the problem is memory related. Usually I don't have memory or other hardware problem with my machines (no crashes, bluescreens etc). In one forum message I read about an xvid codec problem, if it is running on a "normal priority" level (which I do), but I need to do further tests to narrow the real source behind the problem.

I'll keep you informed if anything new occurs.

[Didée]

All of the above mentioned crash problem occured as I had created a joblist in VD and VD was working through the jobs during the night. In the morning half of the jobs were one, the other half was errored out.
Ah, that reminds me of some issues I had (long) time ago when using VD's joblist with "complex" AVS scripts. My solution was to have a small dummy file (huffyuv, ten frames or so) to be converted to something else. This "dummy task" I placed between all the "real" tasks, and surprise, those VD errors disappeared.
Must be related to VD not correctly releasing memory when a job is completed, or something.

[sidewinder711]

Thanks, Didée, for your help. Now I have another idea to test.:)

[IanB]

Most of the methods so far in this thread involve some sort of averaging of adjacent data. And generally none of them totally remove the flicker. This is probably due to the issue I encountered when adding the interlace option to the SubTitle() filter.

This issue is Gamma!

You need to undo the Gamma compensation, apply your favourite averaging method, then reapply the Gamma compensation.

[Gavino]

The gamma thing seems to have been widely overlooked in digital image processing. See this paper (http://www.4p8.com/eric.brasseur/gamma.html) and this thread.

However, although there is a real issue here, I wonder if it's slightly overblown. Consider that in many cases we are averaging as a form of interpolation. The fact that we have a non-linearity in the representation just means we need a better interpolator than simple bilinear. After all, the real-world (continuous) intensity doesn't usually vary in a linear manner, so all we are doing is interpolating a different function (I(x,y)^gamma instead of I(x,y)).

Or am I missing something?

[IanB]

Well actually I(x^(1/gamma),y^(1/gamma))^gamma instead of I(x,y)

For gamma=2.2 and I(x,y)=(x+y)/2

x y I(x,y) I(x^(1/gamma),y^(1/gamma))^gamma
0.5 0.5 0.5 0.5
0.25 0.75 0.5 0.463
0.1 0.9 0.5 0.390
0.0 1.0 0.5 0.218

[Terka]

Does this mean the TempGaussMC has to be updated regarding the gamma?

[Didée]

Nope. :)

Firstly, there's hardly any need for that. The aim of TGMC is not to produce any averaged values (though it produces them intermediately), but rather to end up with pixel values that exist discretely in the current, previous or next frame/field.

Of all the problems that TempGaussMC or any other bobber are struggling with, I'd say that gamma compensation is the least important of all ...


Then, while gamma compensation basically is a good idea, it's pretty much inpractical to do at the script level. At the script level we're yet bound to 8-bit precision, and that's highly insufficient for such a gamma compensation.
See:

a) TemporalSoften(2,32,32,32,2):
http://img337.imageshack.us/img337/2544/normalux9.th.png (http://img337.imageshack.us/my.php?image=normalux9.png)

b) The same with gamma compensation: (with 8bit/plane precision, through levels() )
http://img186.imageshack.us/img186/2784/gammacompensated8bitey8.th.png (http://img186.imageshack.us/my.php?image=gammacompensated8bitey8.png)

Another example: (left=normal resizing, right=gamma-corrected resizing)

http://img406.imageshack.us/img406/7600/normalnb6.th.png (http://img406.imageshack.us/my.php?image=normalnb6.png) -- http://img167.imageshack.us/img167/9200/gamma8bitbb7.th.png (http://img167.imageshack.us/my.php?image=gamma8bitbb7.png)

In both cases that's not an improvement. It's a severe degradation, caused by way too little precision available in 8 bits. One can play tricks like using gamma compensation only for values bigger than 64, or so, sure. But that defeats the purpose.


If you want to have gamma compensation, either urge all authors of all plugins that do any sort of spatial and/or temporal averaging to make their plugins perform that compensation internally. Or you wait for Avisynth (and the needed filters) to provide 16bit/plane precision. (Yes, 16 bit ... 10bit chimaera are still not sufficient for this.)

Apart from that, gamma really is an RGB concept. In YUV colorspace, "gamma" adjustment is a whacky approximation that doesn't truly reflect what gamma is supposed to be.

[Terka]

ok :)

[Gavino]

Apart from that, gamma really is an RGB concept. In YUV colorspace, "gamma" adjustment is a whacky approximation that doesn't truly reflect what gamma is supposed to be.
But aren't YUV filters affected by the gamma issue just as much as in RGB?

Perhaps even more so, precisely because of the whacky approximation used in RGB<->YUV conversion (which is done using gamma-encoded RGB values rather than gamma-encoding the converted linear values).

[WorBry]

Specifically, in DV camcorders, gamma correction is normally applied to the linear digital RGB signal after the Rec 601 transfer function and before conversion to Y'CbCr color space.

http://en.wikipedia.org/wiki/DV

[Didée]

This way, that way, or another. Still I don't see how TGMC could benefit, since it's basically flicker-free. If it flickers in places, then it's because of mocomp-mismatches, or because of misinterpreting a good compensation as being bad, and thelike ... but not because of missing gamma compensation.

My bigger fear is HOWDOIPROCESSYUY2SOURCESWITHIT ... sooner or later, it will come up ...

[WorBry]

My bigger fear is HOWDOIPROCESSYUY2SOURCESWITHIT ... sooner or later, it will come up ...

ConvertToYV12(interlaced=true) ?

[AVIL]

My bigger fear is HOWDOIPROCESSYUY2SOURCESWITHIT ... sooner or later, it will come up ...

A little help (sorry for inserting an attachment but the script exceeds 16000 chars limit)

[Didée]

Ah, splendid! Nice work, really, thank you very much!

Did you count how often it is converted back-and-forth between planar and interleaved? Twenty, thirty, perhaps forty times ... ?

(It's kind of ridiculous if something has to be done like that, isn't it ... but alas it's the only way to keep all those precious chroma samples ... a pity that they will be lost anyway, if in the end a compression with Mpeg2/x264/Xvid/whatever is done ... <giggles>)

[2Bdecided]

Just to confirm that the table in this post (http://forum.doom9.org/showthread.php?p=1155566#post1155566) pretty much restores the alpha3 performance to beta1, but for my HDV footage alpha3 still has the very slight edge IMO.

For my HDV footage, the default beta1 settings are a disappointment (except in terms of speed!). I think NNEDI>EEDI2 is the biggest factor, but everything seems to play its part.

I accept that for more detailed footage beta1 might be far better, but (again, IMO) the stuff that looks a bit like combing shouldn't be coming through by default.

Just my 2 pence. It's all a bit theoretical for me - it's not really practical to use something this good (slow) on HD anyway, except for grabbing stills.

Cheers,
David.

[Terka]

to 2Bdecided:
if i can understand correctly, the defaults:
for beta are fast, but bad quality?

[Yoshiyuki Blade]

Just my 2 pence. It's all a bit theoretical for me - it's not really practical to use something this good (slow) on HD anyway, except for grabbing stills.


Yes, it may seem way to slow to be used in practice, but I've been encoding many 1080 resolution clips using TGMC, and its well worth it :D. Although (currently) none of my clips ever exceed just a couple minutes, every second of footage looks fantastic.

But even on the great hardware I have, it will take quite a long time to process everything, and will also require great hardware to playback at full speed. It really depends on what you have, I guess.

[Didée]

to 2Bdecided:
if i can understand correctly, the defaults:
for beta are fast, but bad quality?
They're not bad quality. They are just faster.

What looks good-or-bad depends pretty much on the actual source and its characteristics.

Please read this post (http://forum.doom9.org/showthread.php?p=1154607#post1154607) again.

[2Bdecided]

I wasn't arguing against your post Didée, which is why I wrote what I wrote, rather than what Terka thought I meant. The results I post are for my footage; certainly not universally proven.

I do have a slight concern that WorBry seems to be seeing similar problems though, on quite different footage. Maybe a slightly different default setting might make more sense. I don't know. I'm not using other people's content.

It's strange, because in other uses (e.g. mcbob, upsizing), if I can see a difference, I usually subjectively prefer the eedi2 version over nnedi. Whereas with this script, nnedi is clearly better for my content.

Cheers,
David.

[Terka]

2 Didee:my question was posted because i didnot understand what 2Bdecided wants to say. When i reread 2Bdecided's post - its still not clear to me.
So beta has faster default settings, in different situation they produce worse or better results than default setings used in alpha.
Sorry for using simple English.

[2Bdecided]

So beta has faster default settings, in different situation they produce worse or better results than default settings used in alpha.Yes, that's it.

Cheers,
David.

[Terka]

Hi Didee,
welcome back from holidays.

tgmc sometimes causes following artefacts:
on _static_ parts with detailed structure (like grass on psi.avi)
Grass should be static, but some bigger (40*20pixels) parts of it are moving in different directions by +-1pixel. Could this be somehow eliminated (what about separate picture onto smaller areas and use dup?)


Some questions regarding the tmcg. As usually from me, if something could be useful, take it, if not, ignore it. Please dont spend much time regarding the following.
if the TG result depends on interpolation method (nnedi, edi ...), than we can:
1. feed it with something better
2. use "weaker settings" (you told that:TempGaussMC will average away much of the benefits that any motion-compensate bob will feed it with.)

ad 1)

a) overlay "interlaced original over tgmc"
b)

o'riginal
g'aus
n'nedi

o
g
o
g

(double the height)
o
n1
g
n2
o
n3
g

(remove lines with g)

o
N -> overlay of n1,n2 or another nedi to get the line between n1,n2
o
N

ad 2) dont know if i understand the script, is the core the >>temporalsoften<< ?
if yes, what about double the framerate to weaker the temporalsoften behaviour?

[WorBry]

@Didee,

Just wondering, does this have implications for TempGaussMC?

http://forum.doom9.org/showthread.php?p=1172038#post1172038

[Nikos]

The same typo error in beta-1 :D

# construct temporal gaussian average from linear averages
t = (tr0==0) ? dbob
\ : (tr0==0) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)

[Mystery Keeper]

I can't find tempgaussmc_beta2 anywhere. Am I dumb? ^_^'

[WorBry]

I can't find tempgaussmc_beta2 anywhere. Am I dumb? ^_^'

AFAIK, there is no beta2 (as yet). Beta1 is here:

http://forum.doom9.org/showthread.php?p=1158000#post1158000

The same typo error in beta-1 :D

# construct temporal gaussian average from linear averages
t = (tr0==0) ? dbob
\ : (tr0==0) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)


By George, he's right you know. Obviously, easily remedied:


# construct temporal gaussian average from linear averages
t = (tr0==0) ? dbob
\ : (tr0==1) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)


...but probably Didee should be the one who puts up a corrected version.

[Nikos]

Foremost, thanks Didie for this excellent function.

After observation the whole function i have one note:


beta-1
Smode = default( Smode, 2 ) # Which method to use for re-sharpening the MC'ed temporal gauss:
# 0 = not at all
# 1 = 3x3 kernel
# 2 = vertical min/max plus 3x3 kernel

SLmode = default( SLmode, 2 ) # How to limit the sharpening:
# 0 = not at all
# 1 = spatial, before 2nd MV stage (fast)
# 2 = MC-temporal, before 2nd MV stage (slow)
# 3 = spatial, after 2nd MV stage (fast)
# 4 = MC-temporal, after 2nd MV stage (slow)


Sbb = default( Sbb, 1 ) # Back-blending of gauss-blurred sharpen's difference (slightly increases visual fidelity)
# 0 = no back-blending
# 1 = before sharp-limiting
# 2 = after sharp-limiting
# 3 = before AND after sharp-limiting


but here with Smode !=0, SLmode = 4 or 3 and Ssb = 3

# re-sharpen the temporal gaussian blur
stage1a = (Smode==0) ? stage1
\ : (Smode==1) ? stage1.mt_lutxy(stage1.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)
\ : stage1.mt_lutxy(st1mmavg.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)

# apply vertical thinning?
stage1a = (SVthin==0.0) ? stage1a : stage1a.mt_adddiff(vmedDD,U=2,V=2)

# apply 1st sharpening back-blending?
stage1a = ((Sbb==1 || Sbb==3) && Smode!=0 && sharpness!=0.0)
\ ? stage1a.mt_makediff(mt_makediff(stage1a,stage1,U=1,V=1).removegrain(11,-1).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=5),U=2,V=2)
\ : stage1a

# apply sharpening limiting? (SLmode 1|2)
stage1b = (sharpness==0.0) ? stage1
\ : (SLmode==1) ? ( (SLrad<2) ? stage1a.repair(edi,1) : stage1a.repair(stage1a.repair(edi,12),1) )
\ : (SLmode==2) ? stage1a.mt_clamp(pmax,pmin,Sovs,Sovs,U=3,V=3)
\ : stage1a

# apply 2nd sharpening back-blending?
stage1b = ((Sbb==2 || Sbb==3) && Smode!=0 && sharpness!=0.0)
\ ? stage1b.mt_makediff(mt_makediff(stage1b,stage1,U=1,V=1).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=5),U=2,V=2)
\ : stage1b

we have two back-blending before sharp-limiting.

[thetoof]

beta2 is an unofficial version modded for the multithreaded version of MVTools
http://forum.doom9.org/showthread.php?p=1171286#post1171286

[WorBry]

Since its not an official update from the author, wouldnt it be better to call it something different like TempGaussMC_Beta1_MT or similar?

Didee, wherefore art thou???

[Didée]

I'm busy making preparations for my funeral. When I saw that "tr0==0" typo, I got a heart attack, and deceased. :D

Just wondering, does this have implications for TempGaussMC?
http://forum.doom9.org/showthread.php?p=1172038#post1172038
For the moment, no. I consider that not important enough. When using Yadif/EEDI2/NNEDI as interpolator, there should be no practical impact on the result at all. Chroma is only a "small helper" in MVAnalyse. And even when using EdiMode="MickeyMouse" (no EDI, use simple bicubic interpolation), the error is so small that it hardly matters. (it does when you're chaining several instances of bob->separatefields->weave ... that's a good way to demonstrate the problem, but it's nothing you do in a typical workflow.)
Let's wait for Avisynth to sort this issue internally.


@ Nikos: Well spotted that "tr==0" error. How could I overlook that!?

You're also correct on the back-blending issue in case of SLmode=3|4. However, that one is on purpose. Re-sharpening is done before the 2nd MVDegrain stage, and after the 2nd MVDegrain stage it's no more possible to differentiate between difference-of-sharpening and difference-of-MVDegraining. Theoretical options were to sharpen after the 2nd MVDegrain stage, or to take the sharp-diff from before and back-blend it after the 2nd MVDegrain ... but both ways would be prone to re-introduce some noise or bob-shimmer.
The fully correct way would be to first separate the sharp-difference, and apply yet-another instance of MVDegrain to this difference. And that's way too much computational effort for a rather small effect.

The way it is now, the backblending procedure works not exactly as described (in case of SLmode=3|4 and Sbb=2|3), but it works reasonably. I'll leave it like it is.


I've updated the script with the major edit of [tr0==0] => [tr0==1]. :rolleyes:


@ Terka: I'm not convinced that your last proposal of weaving + NNEDI-interpolation will work out, methinks it should lead to shimmer again. However I'm not fully sure in this case, so I'll have to actually try it out.

[Nikos]

Thanks Didie for the analytical explanation. Another solution is to aplly "Back-blending after sharp-limiting" only for SLmode=1|2.

Sbb = default( Sbb, 1 ) # Back-blending of gauss-blurred sharpen's difference (slightly increases visual fidelity)
# 0 = no back-blending
# 1 = before sharp-limiting, for Slmode = 1|2|3|4
# 2 = after sharp-limiting, for Slmode = 1|2
# 3 = before AND after sharp-limiting, for Slmode = 1|2

[WorBry]

@Didee,

I see Fizick has now fixed the MVDegrain 'chroma shift' issue in the latest MVTools v1.10.2.1

http://forum.doom9.org/showthread.php?p=1176507#post1176507 :rolleyes: :rolleyes:

Does this mean that the compensating segment in TGMC_beta1 (lines 245 - 247) can and should now be deleted?

## MVDegrain causes a chroma shift (yes it does, with pel>1 !) We compensate by shifting chroma towards plain EDI by a small notch
## [ 1+(x-1)/(1+(x/5)^4) ] on 128-centered diff-clip (x-y) ==> [ x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * + ? ]
stage2 = stage2.mt_lutxy(edi,"x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * - ?",Y=2,U=3,V=3)

Edit: Ah, I note Nikos has queried this also in the MVTools thread:

http://forum.doom9.org/showthread.php?p=1176566#post1176566

[boondoggle]

I get "no function named MVAnalyseMulti" (line158) when using MVtoolsv1.10.2.1 and TGMC beta2 .. but with MVTool 1.9.6.7 it works. Any ideas whats wrong?

[talen9]

Yes :)

There are two (at this time) separate branches of MVTools; 1.10.x.x is Fizick's branch, it contains only the standard "MVAnalyse" functions.
1.9.6.x is josey_wells' branch, it does contain the MVMulti* functions.

So, the behaviour you're reporting is consistent.

Let's only hope that those two branches can be merged soon ... at least, to avoid further confusion :)

[boondoggle]

ah, could you/anyone describe differences between the two?

[talen9]

Well, there's the MVTools thread (http://forum.doom9.org/showthread.php?p=1171286), where all the info you're requesting (and more) can be found :)

Have a look at the last 3-4 pages, I think it should be enough :)

[thetoof]

Hi,
I've got a sample that's flickering like crazy after deinterlacing... does someone know anything that'd help remove that? I tried a few settings with tgmc and even if I can't have anything better with the other smart-bobbers, it is still unpleasing to the eye.

Get it here (http://www.mediafire.com/?jxdjdg9rtdi) if you want to give it a try.

Maybe it could be a good test clip for the dev of tgmc since it's very tricky...?

[Didée]

You just got aware of the "black hole problem" of de/interlacing.

To start, I came up with settings like this:
tempgaussmc_beta1(2,2,3,0,0,0,"EEDI2",eedi2maxd=16,truemotion=true,sharpness=1.75,Sbb=2,SLrad=2,SVthin=0.75,Sovs=2)

In now way perfect, yes, but it won't get much better than that, see below. If you think it's bad, then do a stackhorizontal with TDeint or Yadif/Mod or with whatever else -- instantly, the result of TGMC will look much better then! ;)


There's lots of motion in vertical direction, and there lies the problem. MC'ed bobbers/deinterlacers basically are temporal superresolution filters, i.e. the information not present in the current frame (field) they try to pull out of the neighbor frames (fields). This is fine if the vertical component of motion amounts to 0 / 2 / 4 /... pixels. On contrary, if the vertical component of motion amounts to 1 / 3 / 5 /... pixels, then the current frame/field and its neighbors contain exactly the "same" information, and exactly the "same" information is missing. In this case there is *nothing* that can be pulled from the neighbors. This results in "static aliasing" in the moving parts. Now, if mod2 of the vertical component is not exactly 1.0 but only close, then the result will be some kind of "travelling" aliasing in the moving parts. In parts where the temporal approach (necessarily) has to fail, the only hope is that the spatial deinterlacing part constructs something useful. This will succed in many places, but will fail in others, and usually will be plagued by flickering, especially if speed of motion is rather slow.

Since in this sample there is stuff moving at all kinds of different speeds, the result contains the full bandwith from "perfect" deinterlacing, over the travelling aliasing nastiness, up to the black hole.

TGMC still does better than most other deinterlacers - the other ones will fail if the missing information is not present in the +/-1 neighbors, while TGMC can pull a good amount from the +/-2 ones, too, and even a bit from the +/-3 neighbors (not very much from the latter, though.)
In theory one could reflect about evaluating an increasing temporal window in order to pull information from even further away neighbor fields; but that's difficult, and the computational effort explodes.

So, sorry if it's not perfect, but that's the way it just is. In case you find something that works better than TGMC for this stuff, keep us informed!

(I really would like to see what some expensive hardware like Snow & Wilcox would produce in this case .... not because I expect a [much] better result, but rather for the chance to see such $$$$$-hardware failing in the very same way.) ;)

[2Bdecided]

I think the fault lies with the originator of the content. Image detail of the order of 1 pixel high combined with movement of the order of 1 pixel per field cannot be accurately represented in an interlaced system. With live events, you never know what might happen momentarily - you can sometimes see the same problem with details in football matches and motor sport. However, with animation, you create the stuff frame by frame - or in this case field by field. Watch it on an interlaced display, and you'll get plenty of weirdness! The originators of the content should have spotted this, and either filtered the fine detail, or modified the scroll rate.

I doubt that Snell and Wilcox can solve it, but they have some great white papers explaining this specific problem, among others...

http://www.snellwilcox.com/community/knowledge_center/engineering_guides/

I think it's the standards conversions and composite decoder documents - IIRC it crops up in both, but I could be wrong.

Cheers,
David.

[thetoof]

Thanks a lot for the detailed explanation!

I never questionned the fact that tgmc outputs amazing results compared to the other bobbers around (that's why I said:
I can't have anything better with the other smart-bobbers
Anyways, thanks again for your help/explanation/awesome script!

[WorBry]

I know Snell & Wilcox is considered to be the holy grail of converters, but has anyone out there in Doom9 land used it? I've never see an example on the forums. AFAIK there is a standalone, software version (Helios) that someome, somewhere posted retails at $3000+. Strange that they dont seem to have a demo version available. It sure would be interesting to compare with TGMC (for deinterlacing) and MVFlowFPS (for frame-rate conversion).

[Dr.D]

Can I use TempGaussMC for removing flickering from a progressive (deinterlaced) clip?

[Adub]

You really shouldn't. Use a flicker reducer, such as ReduceFlicker or Deflicker. You never want to deinterlace a progressive source.

[thetoof]

What was discussed here (http://forum.doom9.org/showthread.php?t=141292) might interest you ^_^

[Dr.D]

You really shouldn't. Use a flicker reducer, such as ReduceFlicker or Deflicker. You never want to deinterlace a progressive source.
Sure I don't want to deinterlace. I want to femove flicker.
I have some clips without sources, deinterlaced by wrong deinterlcer (I would say, any deinterlacer is wrong for my camera except TempGaussMC :), because produces this annoying flicker).

So, question to Didee - is it possible to populate this magic deflickering logic from the TempGaussMC to work with progressive source? Or it's impossible to make a meat from a grinded one?

[WorBry]

Or it's impossible to make a meat from a grinded one?

Try TempGaussMincedChicken :D

[Didée]

is it possible to populate this magic deflickering logic from the TempGaussMC to work with progressive source? Or it's impossible to make a meat from a grinded one?
A bit of both. It's certainly possible to remove much of such flicker, but it will always boil down to some sort of "brute force" filtering.

Taken very strictly, you won't get TempGaussMC's "magic" when running it on already-deinterlaced sources with deinterlace-flicker. The point of TGMC is that the, hmh, the deviations of even fields and those of the odd fields should cancel out each other. But on already deinterlaced sources, you're basically missing one of those fields completely, and so the cancelling-out obviously can't work correctly anymore.

Nonetheless an improvement by TGMC surely is possible. And the proposals that thetoof above has pointed to will also improve notably.

Point is, there is no really "correct" way of dealing with the problem. Possibilities are plenty, each with their pros and cons ... and in the end, it's once more a matter of personal preference which method might be *your* personal favorite.

Important points:

a) temporal filtering is a must

b) without motion compensation you won't get very far

c) when using motion compensation, then the flicker that you want to remove is very likely to disturb the motion search


Both TGMC and the script suggested by thetoof (the 1st of the three, actually) address all three points. TGMC probably will be somewhat more strong on the pre-filtering side (I suspect the tempgauss to straighten out more flicker than FFT3D), but it's not clear if the mocomp-tempgauss stage deals well or better should be modified for such a task. In any case, thetoof's script uses edge masking, which is likely to keep more detail in the result (mostly in flat areas, think of skin and faces).

A random suggestion to try:

TempGaussMC_beta1(2,2,2,4,2,2,"NNEDI",sharpness=4.0,Sbb=3,SVthin=2.0,SLrad=2,sovs=1)
Merge( SelectEven(),SelectOdd() )
... which of course could be additionally combined with edge masking, too.

Again, there's thousands of possibilities ... at best, you try them all. ;)

-----

BTW, did anyone notice?
... expensive hardware like Snow & Wilcox ...

ROFL! :eek::p:D

(That day, it was VERY cold over here ...)

[Dr.D]

Didée, thetoof thanks a lot, I'll try both.

Another question. The source is noisy as well. What is the best option for denoise before de-flickering:
1. No any denoise before.
2. Some denoise (what kind?).
3. All supposed denoise.

[Dr.D]

try tempgaussmincedchicken :d
:) :)

[Terka]

@ Didee:
"I'm not convinced that your last proposal of weaving + NNEDI-interpolation will work out, methinks it should lead to shimmer again. However I'm not fully sure in this case, so I'll have to actually try it out."
could you have a practical look at #159 thank you, Terka

[Didée]

Well ...

ad 1)

a) overlay "interlaced original over tgmc"


That's already an impossibility: "tgmc" has double as much frames as the "interlaced original". So, when taking that proposal *literally*, it does not make sense.

It could be interpreted like:

a) overlay InterlacedOriginal.DoubleWeave() over TGMC

=> NNEDI interpolation will construct a result that's inbetween the results of TGMC and orig.DoubleWeave(). This seems not promising.


b) overlay InterlacedOriginal.Bob() over TGMC

=> NNEDI interpolation will construct a result that's inbetween the results of TGMC and orig.Bob(). This seems not promising either.


The trick is that the differences between even and odd phases are *not symmetric*. That's why interpolation based on the original fields won't work out in the way one is dreaming of.
Even MCBob stumbles in this pitfall of a false assumption: its STT routine is a misconception, it re-introduces bob shimmer. :)

[Didée]

Frankly, that description above wasn't very good. Let's try a simple example instead.


Original progressive sample:

... 80 80 80 ...
... 20 20 20 ...
... 60 60 60 ...


Examine a (field)/(bob frame) where the dark line (20 20 20) is missing and has to be re-interpolated.

Interlaced:

... ?? ?? ?? ...
... 80 80 80 ...
... ?? ?? ?? ...
... 60 60 60 ...
... ?? ?? ?? ...


TGMC result: (example)

... 82 80 78 ...
... 19 20 21 ...
... 58 60 62 ...


Now we do what you proposed.

Interleave orig with TGMC:

... 80 80 80 ...
... 19 20 21 ...
... 60 60 60 ...


Let NNEDI create interpolations:

... 80 80 80 ...
... 50 50 50 ...
... 19 20 21 ...
... 40 40 40 ...
... 60 60 60 ...

Throw out TGMC's interpolation, replace with average of NNEDI interpolation orig<>TGMC:

... 80 80 80 ...
... 45 45 45 ...
... 60 60 60 ...

Hey! The "20" line has turned into a "45" line! A dumb bob would've produced a "70" line.

It's a very simplistic example, but it shows that this method will turn a 100% correct result into a result that lies halfway between "100% correct" and "dumb bob". This means that you'll get 50% of the flicker/shimmer that a dumb bob would produce. Not good. First use a rather slow bob filter, then throw away 50% of the improvement you got from the slow method? No. That's a too heigh prize to pay only to "safely" use the original lines of the original field.

(That example didn't really use NNEDI, just ordinary linear interpolation - but that's irrelevant. It doesn't matter which spatial interpolator you use here. It's the basic principle in itself that is faulty, the kind of interpolator has nothing to do with that.)

[Terka]

of course we want to double the resolution, look for information which is not there, maybee in previous/next frame.

hm... simple clear model. yes nnedi method fails. but interleave looks quite good. in horizontal direction.
but what about in above posts described "errors" seen in narrow vertical lines which are discarded by pure tgmc?

and could the 2) be useful

or could we put the temporal axis to nnedi (put eg 3 frames over each other and after that fill the missing information)
like for example
1.some bobber (needed for more sucessful motion comp.)
2.motion comp - overlay
3. erase the filled areas="gaps" come into existence
4. fill the "gaps"

[Terka]

is the above useful?

[Didée]

Can't tell. I don't "see" what exactly should be done, your description is not precise enough, sorry.

My probably-closest interpretation of your 1.-4. steps would mean that step 3) is exactly un-doing step 2), which wouldn't make much sense.


What else could it be? Mo-comp c-1 and c+1 onto c, then NNEDI-average between them? Not spectacular, in this case NNEDI would perform some kind of fine-compensation in addition to the initial mo-comp. I don't see an actual problem being solved by this.

First weave scanlines of c-1, c, c+1, then doing mo-comp on this weave? Probably not. That plainly can not work, mocomp on such spatially-not-continuous frames can't be successful.


Hint: always think about which basic problem a method should solve, and WHY the method solves that problem. To me, it frequently sounds like "take some A, take some B, throw'em at NNEDI, see if some magic arises."

Such poking is not the way. (Alchemy *never* has been able to produce gold. Nuclear physics can, but the result is more expensive than natural gold. )

So please, try to explain better.
- If needed, make diagrams.
- - In case of doubt, implement yourself, then show us that it works. ;)


edit: oops, forgot your "ad 2)" :
[ 2. use "weaker settings" (you told that:TempGaussMC will average away much of the benefits that any motion-compensate bob will feed it with.) ] ...

ad 2) dont know if i understand the script, is the core the >>temporalsoften<< ?
if yes, what about double the framerate to weaker the temporalsoften behaviour?
No, not good either. Temporal-gauss-filtering calms the up-down-up-down flicker into a "flat" sequence (at least that's the basic idea), so that motion compensation doesn't "follow" that flicker. There is no benefit by first increasing framerate.
What could be a possibility is: to do a rough pre-pass motion compensation, to make the initial tempgauss not ghost as much as it currently does without MC. But that would require bigger blocksizes than 16x16, more like 32x32, perhaps up to 48x48. If I'm not mistaken, MVTools does not offer that.

Phase correlation is something too ... but a) we don't have it, and b) IMO it's an over-hyped concept. Phase correlation can show you "yes there IS an solution", but it doesn't GIVE you one. To GET that solution that phase correlation showed to exist, you need to use ... good old ME+MC, and in an instant, you're facing exactly the same problems as without phase correlation.

[Terka]

input:
11111111
________
55555555

we need fill the blank line (_____)
the nnedi or another method could fill like
11111111
33333333
55555555

what i want to say - lets use for the filling also the f-1, f+1 frames
because the original could be eg.
11111111
55555555
55555555

how?
A) do the motion comp. (or phase correlation or ...)
put the pictures over each other:
(lets assume pointresize to doubleheight)
eg. lets the object moving right-down by 1/2pix per frame
111111
11111111
_1111111
______
555555
55555555
_5555555

so from the next (red) frame we could get the half of missing line.
for the successful overlay we need good step A
but simple mo-co is comparing two different pictures (upper-lower), thats why i tried to explain how to get more correct vectors (first fill the missing lines, mo-co to get vectors, unfill the filled=back to original, use the vectors to overlay and fill the gaps)

add 2)
No, not good either. Temporal-gauss-filtering calms the up-down-up-down flicker into a "flat" sequence (at least that's the basic idea), so that motion compensation doesn't "follow" that flicker. There is no benefit by first increasing framerate.

is the core of temp-gauss the usage of temporalsoften?

[Didée]

Small allegory before falling asleep: (2.00 AM here)


We have a bucket that has its bottom broken away. We also have some synthetic granules to repair the bucket with. To work the granules, we need to mix it with water. Water is available from a far-away river.

The problem is, obviously, how to transport the water from there to here.

You are suggesting to transport the water in the bucket with the missing base.


zzzzz..... <sleeps>

[Didée]

OK, lets expand a bit on that allegory. BTW, just found there's a Wikipedia article (http://en.wikipedia.org/wiki/There%27s_a_Hole_in_My_Bucket) about that song.

(It's only some free minutes during lunchbreak, not sure if I can finish in this run.)


There is information missing. And no matter how you turn the coin: in order to have any method "perfectly" reconstruct the lack, the method would need to have a-priori access to the information that is yet missing.

Throwing out some simple thoughts:

Your example with |1|?|5| . Assuming the case that "?" should actually be "5", yould "showed" that this info could be gotten from a neighbor frame (using mocomp).

What you forgot: assume that mocomp of f+1 gives you a "5", BUT f-1 gives you a "1". Now what to do? You can't decide if the "1" is correct, or if the "5" is correct. Or if the truth infact lies in the middle, and there really should be a "3". You just can't decide.


Looking at it from a generalized point of view, it boils down to this:

The "simple" approch uses mocomp to fill in the missing data from the neighbors. This generally works, but we found the result is often insufficient, because certain configurations of the "decimated" original data can lead to unwanted results of the motion engine.
Spatial interpolation is not sufficient, because it basically does not change the characteristics that fool the motion engine.
So you propose to instead use a pre-pass motion compensation for "better" interpolation of the missing data. And that's the point where the dog bites its own tail:
If the whole mocomp thingy gets fooled in the "simple" approach, then the mocomp thingy is *not suited* to provide a better pre-interpolation for the "real" mocomp thingy in a 2nd pass. All that happens is that the 1st mocomp stage would consolidate those characteristics that are fooling the motion engine.

Or like this: a one-stage mocomp suffers from producing the error "E". We want to eleminate producing this error. Now, in order to prepare the initial data in a better way, you propose to use the very method that is producing error "E". Hence, the 2nd-stage mocomp will be working on a dataset that has the error "E" already burnt-in.

It just does not work out. There's a whole in my bucket oh Henry oh Henry, ...


OTOH ...

as long as rather "small" motion is present, current TempGaussMC does work out pretty good already. There is not so much that could be improved at all.


Further on ...

Elaborating about "simple examples" is good and all, but it's not sufficient. One can get to "solutions" that *seem* to work on the simple examples. But the bad surprise usually comes when you practice those "solutions", and you discover that are so darn many small pitfalls and special cases that also have to be considered; and it's all these little things that turn the beautiful "solutions" upside-down and inside-out, and *POOF*, there the bubble blows.

Think about the "black hole" problem (vertical motion of 1 pixel, the data missing "here" is also not available from "there"). A big problem, and I don't see your proposal to offer any solution.

Or what about not-antialiased original (progressive) detail of high frequency. Your current dataset is |5|?|5|, and from the mocomp you get a surprising "60" as solution for "?". Now, decide if that "60" is correct (it is really detail), or if it's false compensation. If you just play safe ("such a big difference must be considered an error"), then you#re fine if it really was an error; BUT of course you get nasty flickering if it indeed is detail. (This is the route that's usually taken: better play safe.)
The other way round, if you just blindly trust mocomp's result, then you are fine if it really was detail, but you get artifacts if it in fact was an error.


And so further and so on ...


Lots of problems that can arise. The current way surely is not at all perfect, but I'd say it's rather good. Over time, I've wrapped my mind quite thoroughly around what can be done with our current tools; and I don't see easy ways to get a worthwile improvement with reasonable effort.

I'm all open for NEW ideas to be introduced.

However, old wine in new skins won't get us very far.


Finished *almost* in time. ;-)

[Didée]

To not get accused of just babbling and making everything bad, I (tried to) make a script that follows Terka's last proposal.
Perhaps it is what he meant, perhaps it's just sort of an interpretation ... it's still not fully clear.

# Trying an idea of Terka
# Target: a pre-bobbed clip with "better interpolation"
# Method: Do vector search on (dumb) bobbed clip. Create forward compensation and backward compensation.
# Let NNEDI interpolate between them two. From that interpolation, use the according complementary fields to weave with the original fields.


bs = 16 # blocksize
ov = bs/2
tm = true # truemotion?
iidx = 15 # idx value to use

i = last # this is the original interlaced input

fflag = i.GetParity()

bob1 = i.bob(0,0.5)
bob1 = fflag ? bob1.AssumeTFF() : bob1.AssumeBFF()

# motion vectors
bv = bob1.MVAnalyse(isb=true, truemotion=true,blksize=16/1,overlap=8/1,idx=iidx)
fv = bob1.MVAnalyse(isb=false,truemotion=true,blksize=16/1,overlap=8/1,idx=iidx)

# bw & fw compensation
bc = bob1.MVCompensate(bv,idx=iidx,thSCD1=800,thSCD2=255)
fc = bob1.MVCompensate(fv,idx=iidx,thSCD1=800,thSCD2=255)

# from the MC'ed bob frames, select the "new" fields
compfields_b = bc.SeparateFields().SelectEvery(8,1,2,5,6)
compfields_f = fc.SeparateFields().SelectEvery(8,1,2,5,6)


# Now, make a "NNEDI average" of (forward compensation) and (backward compensation)

# breeeaaaaaathe in deeply .........
interleave(compfields_b,compfields_f).AssumeTff().Weave().NNEDI(field=1,dh=true).AssumeTFF().SeparateFields().SelectOdd().AssumeFrameBased().AssumeTFF().SeparateFields().SelectEvery(4,0,2)
# breeeaaaaaathe out again!

# weave the original fields with the NNEDI-averaged compensated fields
interleave( i.separatefields() , last ) .SelectEvery(4,0,1,3,2)
fflag ? AssumeTFF().Weave() : AssumeBFF().Weave()

# for comparison: radius-1 dumb temporal gaussian blur
t = bob1.temporalsoften(1,255,255,32,2).merge(bob1,0.25)

left = last.Subtitle("Search clip, proposed method")
rite = t.Subtitle("dumb temporal gaussian blur, temp.radius=1")

stackhorizontal(left,rite)

return(last)


See if you find something useful in it ... note that it's not for producing a "nice" output, but only for preparing a clip to search motion vectors on.
Hence, "sharpness" is not (much of) an argument. Absence of bob flicker/shimmer is.

[thetoof]

TGMC seems to have some trouble with the motion blur... maybe it's just me or the source being tricky, but here's the sample: http://www.mediafire.com/download.php?djchzhwjzii

[Didée]

What is this? The source to be processed by TGMC, or the result after bobbing + re-weaving?

If the former - great, the source is already full of artifacts. Expect a bobber to repair motion defects that are in the source?
If the latter - great, what to say? Yes, it's full of artifacts. Having the original sample could help.

(If it's the result indeed, then more exhaustive search settings will be benefitial - blocksize=8 / searchparam=8 / pelsearch=8 / small lambda & pnew etc.pp., if you have time...)
(edit - and if it's really the source, then we have interlaced content coded as progressive?! O_o)

[thetoof]

The following was asked a little while ago, but I think it ended up being unanswered:

Now that
1.10.2.1 (28.08.2008 by Fizick)

* MVDegrain1-3: fixed old rounding error resulted in some chroma tint (some thanks to Didee for bugreport, but it could be more persevering in official MVTools forum thread :)
Should we remove this from tgmc?
## MVDegrain causes a chroma shift (yes it does, with pel>1 !) We compensate by shifting chroma towards plain EDI by a small notch
## [ 1+(x-1)/(1+(x/5)^4) ] on 128-centered diff-clip (x-y) ==> [ x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * + ? ]
stage2 = stage2.mt_lutxy(edi,"x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * - ?",Y=2,U=3,V=3)

[News Bot]

I've been trying to get TempGaussMC to work for a few hours now, but it out-right refuses. Everything is perfect, there are no errors. However anytime I try to encode the actual .avs script with it in it, it crashes whatever program I'm using (MeGUI, x264 builds, Media Players etc).

I'm using Vista 64, would this have an effect?

[Adub]

For one, post your script.

For another post the error that you are getting. What happens when you drop the script into virtualdub or media player classic?

[thetoof]

You say there are no errors.... so I guess that what's going on here is simply that tgmc is too slow for you. Of course it'll hang in MPC... it is not meant for speeds such as 60/50 fps. And for megui, you could simply do a lossless rendering pass to speed up encoding.

1st - try drag & drop your avs in virtualdub. If something else than an error appears, it means it works (you could hit file-run video analysis pass to confirm)
2nd - In vdub : video-compression-Lagarith (YV12 mode) / video-fast recompress / file-save as (about 20-40GB per hour of
footage (unless you use selecteven/odd or some decimation)
Then use that file to create a new avs file and use that for x264.

If step 1 works, it means there is no problems. If you want to skip step 2, fine, but be prepared to wait for a while and make sure that you have enough ram to run this. If you're doing a 2 pass encode, a rendering pass is strongly recommended (this way you don't have to run the filters twice = overall major speed-up)

[News Bot]

I got it working ok, a preview comes up now. I had to use the "mt=false" command (I'm running a Quad Core). However now I get a dreaded "CAVISynthStream: System exception - Illegal Instruction at 0x46b4c86" instead of the video itself being rendered. I get it with everything from MPC, VirtualDub, MeGUI etc. It will encode, but the output will just be that error for the length of the video, as will the preview.

Any way to fix this? I've installed and uninstalled several versions of AviSynth but all give the same error.

As for my script:

ffmpegsource("sample.mp4")
AssumeTFF()
TempGaussMC_beta1mod(mt=false,edimode="NNEDI",tr2=1).SelectEven()
Spline64Resize(596,384)
maa()
LSFmod(strength=50)

I've tried using purely TempGauss alone, but it will not budge. Is there any way to fix this issue?

[thetoof]

I can't reproduce your issue. Do you have the TGMCb1mod that uses mvtools2? http://www.mediafire.com/download.php?zjmtgc2qrzi
Guess I should've put some version numbers of something... (at first, this was only meant as something to include in the requirements.7z of animeivtc, but I ended up posting it here and there. My bad.)

[News Bot]

Yeah, I've used every version of TGMC there is, but I still get hit with the same error.

[thetoof]

Have you updated your mvtools version? Does it work with another type of source? (avi, mpeg2..)
The latest ffmpegsource uses a 2 pass decoding :
ffindex("file"), then it'll say it did not return a video clip, and you run
ffvideosource("file")

[News Bot]

I've singled out MVTools as the reason for the error now. The ONLY filter I get it with is TempGauss but it is certainly an issue with MVTools.

I'm using Windows Vista Ultimate 64 bit with Service Pack 1. But I've heard that it works for others, so I'm totally confused on the whole issue. =/

[Terka]

have a look at:
http://portal.acm.org/citation.cfm?id=1440455.1440555&coll=portal&dl=ACM

[Terka]

can be TGMC be upgraded to use mvtools 2?
will be there any spead/quality gain?

[thetoof]

It has been "upgraded", though not officially. Check tempgaussmc_beta1mod (you can get it on the wiki).
You can test and report for the *whatever* gain.

[Terka]

is there any spead/quality gain?

[krieger2005]

You can test and report for the *whatever* gain. :P. As i heard here in the forum it seems that it work better with MT, so with MT there should be an speed gain. Qualitywise there should't be any difference, since i think fizick just ported the internal processing from v1 to v2. But fizick can give here a better answer

[thetoof]

MT should be faster, but then you won't benefit of further upgrades (idx removal (requires less memory), MVDegrainx chroma shift correction (done in 1.10.2.1 and MT is 1.9.7.7... but Didée had corrected it for tgmc with the masktools anyways) and a few other thingies (see the latest MVTools2 changelog for more info)).
So, it doesn't work "better" (nothing really does in this forum ;)), but it's up to you to decide if the v2 upgrades are worth letting go of the MT speed boost.
On a side note, it'd be interesting to see the difference between SetMTMode(2,x) + mvt2 and mt=true.

[Boulder]

Is there an up-to-date TempGauss version with variableblur.dll being used? I seem to recall that it was supposed to be a bit faster, and the memory leak in the dll was fixed by neuron2 some time ago.

[Didée]

Can't tell for sure, but probably there isn't. Anyway, it doesn't matter. The Resize().Resize() combo (that replaces BinomialBlur()) on its own would perform multiple-times-realtime. So in the overall picture, the speed penalty is absolutely neglectable.

[Terka]

Which parametrs tweak in tgmc to calm static details like grass? Standard settings produce areas moving here and there.
see original:
http://rapidshare.com/files/25061661/Psi.rar
is it suitable to denoise/deblock (DV compression) before processing tgmc?

[2Bdecided]

Which parametrs tweak in tgmc to calm static details like grass? Standard settings produce areas moving here and there.
see original:
http://rapidshare.com/files/25061661/Psi.rar
You've been deinterlacing that clip for nearly two years! ;)

There's a bit of aliasing, which causes some instability. You can try some of the mo-comped super resolution stuff from other threads as a post-process, and then re-size back to SD. Painfully slow, but it helps a bit.

At least TGMC_alpha3 is more stable than mcbob. I'd be happy more than with it, I think - though it's too slow for most uses!

Cheers,
David.

[Terka]

is it possible to speedup the tg following way:
interlaced.separatefields() #not bobbing
calming
motion estimation
>so the calming an mo-est. is done on halve size clip.
is it possible to use the "halve_height" mo-vectors on original clip?

[Didée]

It could be done using MVIncrease(), but there's several problems. Accuracy (half- vs. full-pel) is one problem. A bigger one is that MVIncrease does *not* support block overlapping, so the process would be highly prone to introduce block artefacts.

[Terka]

the bobbed clip can be split to two using separatefields(); 2 clips processed used same mo-vectors. and weaved back.

[Didée]

Ah, didn't think of the obvious, now I see. Yes, that should be possible, and rather easy to do. Will be tried out somewhen soon, to see how it turns out.

[Terka]

thank you for replies. dont understand the last sentece. you or someone tried this already?

[Terka]

2 Didée:
1.tried to do the separate_fields - > weave, but im not able to implement it directly to Tempgauss (Tempgauss_beta1mod to be precise)
could you help?
2. tried fluxsmoothT to calm bob's flickering, looks good in static areas.
3.can we get some profit if temporalsoften be used as mo-comped?
for clean soures is TG realy good, (my) DV sources have much more noise which is difficult for me to beat.

[sarmano]

# apply sharpness limiting (SLmode 3|4), or has "draft" been requested?
stage3 = (draft==2) ? t .Subtitle("Draft 2") : (draft==1) ? t1 .Subtitle("Draft 1")
\ : (SLmode==3) ? ( (SLrad<2) ? stage2.repair(edi,1) : stage2.repair(stage2.repair(edi,12),1) )
\ : (SLmode==4) ? stage2.mt_clamp(pmax,pmin,Sovs,Sovs,U=3,V=3)
\ : stage2

stage3


How it's working? I don't understand.
When it's removed TGMC works perfectly on 10x speed without strong sharpness limit.

[Didée]

"You shall not alter complex scripts when you don't know what you're doing."

Quick test:
TGMC with default sharpness limiting (SLmode=2): ~6.6 fps
TGMC with all sharpness limiting deactivated (SLmode=0): ~6.4 fps

If you comment-out (or remove) exactly the code sniplet that you posted, then TGMC will return just the input clip, without any processing, without any deinterlacing.

So - yes, doing *nothing* is a very fast operation, indeed. ;)

[sarmano]

"You shall not alter complex scripts when you don't know what you're doing."

So - yes, doing *nothing* is a very fast operation, indeed. ;)


Hmm. I tried encode 720p video clip without using TMGC and speed was ~8fps but with removed iterations from TMGC it's encoding about 1.2 fps. So - no, doing *something* isn't a very fast operation ;).

I really don't understand the step on stage3 and how many passes it'll do.

BTW: Thanx for answer anyway.
(Sorry for my English!)

[WorBry]

So - yes, doing *nothing* is a very fast operation, indeed. ;)

:D Love it

[Didée]

Hmm. I tried encode 720p video clip without using TMGC and speed was ~8fps but with removed iterations from TMGC it's encoding about 1.2 fps.
720p is progressive. You are using a deinterlacer on a progressive clip ... ?

I really don't understand the step on stage3 and how many passes it'll do.
That "stage3" section does not do something like several passes or "iterations". It's a basic IF..THEN..ELSEIF... condition.
Then, with default settings of TGMC, that section does *nothing*, anyway. With the default setting of (SLmode=2), the sharpness limiting is done earlier in the script (section "stage1b"). For that reason, your change wouldn't make much sense: you are removing a section that does no processing at all (with default parameter, that is).


Also, the code in TGMC is slightly different from the code you quoted (border/crop is missing). Due to those differences, it is not fully clear what exactly you removed, and what exactly is happening in your modified script.
If you want all doubts dispeled, post the complete version of your modified script.

In any case - if you get a 10-fold speedup, then it is impossible that TGMC still does what it's supposed to do.

[sarmano]

Didée many thanks for the explanation of the script.
The purpose of the removal step 3 was my desire to speed up the script a bit by removing unnecessary options as well.
I need some time to understand where I made an error in adjusting the data. Perhaps part of the code slows down the processing of data and I have the impression of useless steps.

720p is progressive. You are using a deinterlacer on a progressive clip ... ?
Yes, I used a resized progressive clip.After several tests, I noticed that NNEDI or EEDI2 does an image more elegant, as compared with the original material, even in small amounts.
Of course, this is not quite correctly associated with the technology of processing, but I really like the result of these actions.

[Terka]

Didée, could you help with the separate_fields - > weave, TGMC hack?
Thank you,
Terka

[Terka]

or someone else? Asked Didee, because he is the author.

[martinfrombern]

i get this strange artifact when using TempGaussMC_beta1mod(edimode="NNEDI"). source is pal dvd. screenshots (thumbnails):

http://hdimage.org/images/0iix94mx5ark26dfio5_source_thumb.png (http://hdimage.org/viewer.php?file=0iix94mx5ark26dfio5_source.png)http://hdimage.org/images/184wyx01af97qbrajt59_tempgauss_thumb.png (http://hdimage.org/viewer.php?file=184wyx01af97qbrajt59_tempgauss.png)

[Didée]

@ martinfrombern
Those are artifacts from failed motion compensation that hasn't been detected as being faulty. You might try using more aggressive repair options, such as TGMC(edimode="NNEDI", rep0=1,rep1=1,rep2=1).
The defaults for rep0/1/2 are 4/0/4. The smaller a number is, the more aggressive the corresponding repair section is acting (and "0" deactivates a given repair section).
However, the more aggressive you choose the repair values, the more likely it is you'll get bob-flicker in static scenes.


@ Terka
While the basic idea is pretty simple to do, it turns out that it's a bit cumbersome to implement into TGMC in such a way that everything still works as it should.

Meanwhile, to cool down your eagerness a little, let's make an estimate:
Say, TGMC is spending ~20% of its procesing time with the motion search. Your suggestion will cut down the time for motion search by ~50%. So in the end, your suggestion would bring ~10% speed increase with slightly reduced quality. (Those are rough numbers from the guts, but fairly realistic.)

See why I'm not overly thrilled to make those changes? Sure, every little bit helps, but ... boosting a 3.0 fps script up to 3.3 fps isn't very spectacular.

[Terka]

Didée, of course, the speed gain wont be big.
I wanted to try it myself, but im not able.
btw. didnot understand
"Will be tried out somewhen soon, to see how it turns out."
thank you, T.

[Sagekilla]

Meanwhile, to cool down your eagerness a little, let's make an estimate:
Say, TGMC is spending ~20% of its procesing time with the motion search. Your suggestion will cut down the time for motion search by ~50%. So in the end, your suggestion would bring ~10% speed increase with slightly reduced quality. (Those are rough numbers from the guts, but fairly realistic.)

This reminds me of Amdahl's law (http://en.wikipedia.org/wiki/Amdahl%27s_law). Even if you speed up one part of a program by an infinite amount, your program can still be very slow.

[lansing]

I kept getting an integer overflow error from the script after an install of windows 7.

I did a clean install of avisynth, some trial and error for all the required plugins. And the error message is still the same:

http://img266.imageshack.us/img266/4644/errormessagep.jpg

t1 = t.VCRep(dbob,ed=ed0,od=od0) #line 144
tD_2 = mt_makediff(ref,clp,U=3,V=3) #line 272

I think the problem comes from masktools, but I don't know what to do about it

[Undead Sega]

i dont mean to sound rude or anything, but is TempGaussMC considered to be 'the' Motion Compensation deinterlacer?

or what Motion Compensation is suppose to be? because there are probably hundreds of different MC's out there, which one do we know is the (works) better and etc.

[Adub]

Typically, the choices between motion compensated deinterlacers lies between MCBob and TempGaussMC. The latter has a nice effect in that it also filters noise, but you can't go wrong with either of these deinterlacers. Just pick the one that works best for your purposes.

[2Bdecided]

There are two mcbob versions - the eedi2 one, and the nnedi one. Horses for courses.

There are multiple tgmc versions - I still like alpha3 for my HDV footage.

tgmc beta1 and 2 give you lots of options - eedi2 or nnedi etc etc etc - there's a post a few pages back that summarises it. These can run faster than alpha3.


IMO(!) visible differences include:

how successfully shallow diagonals are recovered without flicker (tgmc better than mcbob)
how well noise and artefacts are suppressed (tgmc better than mcbob)
how well very fine details are preserved (tgmc beta default seems better than tgmc alpha 3; mcbob seems better too, but less stable)


I often compare the deinterlaced output with what you see on a native interlaced CRT. IMO tgmc can be better almost all the time; mcbob can be better most of the time, but most other oft recommended AVIsynth deinterlacers fail miserably to maintain the full perceived resolution. But mcbob and tgmc are too slow! ;)

Hope this helps.

Cheers,
David.

[Terka]

another speedup possible?
http://forum.doom9.org/archive/index.php/t-22096.html

[Didée]

No.

TemporalSoften is, roughly, 100 times faster than TGMC as a whole. Even if temporalsoften2 (very old & outdated, wasn't it designed for Avisynth 2.0, IIRC?) would be some percent faster, it wouldn't matter. Some percent from one percent is ... practically null.

BTW, somewhen lately I made I rough implementation (only POC, not *generally* functional, hence not posted yet) of your faster ME proposal, which also included the transition from MVTools v1.9.x (original TGMC) to the actual MVTools v2.4.x. What I observed was that there's a small speed improvement of "fast-ME" vs. the original "full-ME", but ... somehow, even with "fast-ME", the new MVTools-v2 version was slower than the original MVTools-v1 version ...

It seems a bit ridiculous to put effort into micro-improvements on the script level, when the hosting environment/tools get slower on a macro level ...

[Terka]

yes, i know that the improvement is low.
1.what is the most time consumer in TG? mvtools time could be halved, bob instead of nnedi/edi can be used.
2.so mvtools2 are slower than mvtools1? and what about quality?
3. im using TGMC on DV sources. unfortunately DV has quite big artefacts, so some appear more visible when TGMC calms most of the picture.
but TGMC is far best deinterlacer.

[2Bdecided]

But doesn't MVTools-v2 multi-thread properly? So it could be faster?

I don't know - I find it hard to keep up!

Cheers,
David.

[Adub]

Yes, MVTools2 multithreads nicely with MT. I have seen a speed up of several fps on my "heavy scripts" when compared to v1.

[aegisofrime]

Personally for me TGMC Alpha 3 runs faster than TGMC Beta 2 by adding a Distributor() to the end of the script. I usually get 10 FPS that way when on a pre-rendering job, as opposed to 8 FPS for Beta 2.

[Terka]

how modify TGMC to
use more frames in MVDegrain?

when used filtering like see below on DV source, result is more stable. But im sure Didee knows why he put the other routines to TGMC.


clp=avisource("c:\hj\kamera\avisynth\psi\!Psi.avi")
SetMemoryMax(512)
bob=clp.bob(0,0.5)
bob=clp.nnedi2(field=-2)



# denoise ##############################################################
calm = calmI(bob)
denoised = mo_denoiseAB (calm,bob)
denoised.Sharpen(0.5)
#######################################################################


###################################################
function mo_denoiseAB (clip calm,clip denoise , int "blksize", int "overlap", int "blksize", int "sharp", int "thSAD", int "refframes")
{
clp=denoise
idx = 20
blksize = default(blksize,4) # blksize value (4, 8 or 16)
overlap = default(overlap,blksize/2) # overlap value (0 to half blksize)
sharp = default(sharp,1) # 0=bilinear softest, 1=bicubic, 2=Wiener sharpest
thSAD = default(thSAD,400) # 640didee,200 orig. higher risks motion ghosting and swimming, lower risks blotchy denoising
refframes = default(refframes,8) # temporal radius for MVTools using the "Multi" modification by Josey Wells


vectors = calm.MVAnalyseMulti(refframes = refframes, pel = 2, blksize=blksize, overlap=overlap, sharp=sharp, idx = idx)

clp.MVDegrainMulti(vectors, refframes = refframes, thSAD = thSAD, idx = idx + 1)
return(last)
}

function calmI (clip)
{
t1 = clip.temporalsoften(1,255,255,28,2)
t2 = clip.temporalsoften(2,255,255,28,2)
t1.merge(t2,0.357).merge(clip,0.125)
return(last)
}

[Chainmax]

TGMC's latest version is TempGaussMC_beta1, right?

[Terka]

i think so.

[WorBry]

TempGaussMC_beta1 is the latest/last official release from the author, Didee. There's a modded version TempGaussMC_beta1mod (courstesy of thetoof) that uses the multi-threaded branch of MVtools or MVTools2.

http://avisynth.org/mediawiki/TempGaussMC

Probably both versions can be updated to include NNEDI2, just released:

http://forum.doom9.org/showthread.php?p=1296128#post1296128

Easy enough to do:

# Create spatially interpolated bob-clips
dbob = clp.bob(0,0.5)
edi = (EdiMode=="NNEDI") ? clp.nnedi(field=-2)
\ : (EdiMode=="NNEDI2")? clp.nnedi2(field=-2)
\ : (EdiMode=="EEDI2") ? clp.SeparateFields().EEDI2(field=-2, maxd=EEDI2maxd)
\ : (EdiMode=="Yadif") ? clp.Yadif(mode=1)
\ : dbob

[henryho_hk]

I love this function. It works even on those ill-brained footage with mixed interlaced and field-duplicated materials (....though I seem to find ghosting on those field-duplicated scenes.... very occasionally.... It may actually exist in the footage itself... not 100% sure).

[Undead Sega]

Typically, the choices between motion compensated deinterlacers lies between MCBob and TempGaussMC. The latter has a nice effect in that it also filters noise, but you can't go wrong with either of these deinterlacers. Just pick the one that works best for your purposes.

sorry for the late response, upon reading all the other replies here, i am still wondering, if MCBob and TempGaussMC are deinterlacers that cant go wrong as u described, what is really the main difference?

as i mentioned before in my previous post, is TempGaussMC 'the' motion compensation technique? i say this because, if i am correct, there are many different techniques that motion compensation has? like on the way it searches pixels and data?

[2Bdecided]

if MCBob and TempGaussMC are deinterlacers that cant go wrong as u describedOh come on man! "you can't go wrong" is colloquial speech - it doesn't mean the result is faultless!

Cheers,
Davd.

[Undead Sega]

The latter has a nice effect in that it also filters noise, but you can't go wrong with either of these deinterlacers. Just pick the one that works best for your purposes.

I was only retorting this line here but probably rephrased it wrong or didnt come out right.

anyways, anyone may i ask?

[Didée]

If you expect an "A is better than B, period." answer, then stop reading NOW.



MCBob

Pro:
- "lossless" bobbing, in the sense that the original fields' scanlines remain absolutely unchanged.

Con:
- result is less stable & less compressible than TGMC, i.e. MCBob has more residual bob shimmer in the output.
- instead of field(x)<-->field(x+1) motion compensation, it uses field(x-1)-->(x)<--field(x+1) motion interpolation. Motion interpolation is (much) more prone to fail.
- uses static masking for reckognition of no-motion areas. Though that's good for (really) static areas, there's always the danger that repetitive motion is misjudged.

(Sidenote: MCBob's Shape Transposition Technology is a failed concept..!)



TGMC:

Pro:
- result is more stable & more compressible, residual bob shimmer is (most likely) the most minimal you'll get from any existing bob- or deinterlacing filter for Avisynth.
- uses motion compensation, which is less likely to fail.

Con:
- TGMC is not lossless, i.e. the original fields' scanlines are altered. (*technically* that's a cutback, but it helps to improve the *visual* quality)

Pro AND Con:
- doesn't use any kind of static-masking.
(Pro: since not used, it can not fail.);)
(Con: Slightly artificial resolution in perfectly-static areas)

___

In direct comparison of "how much effort" it takes for "what kind of result", I'd say that MCBob is overly expensive.

Personally, in most circumstances I prefer TGMC.

[Dominiko]

I can't understand this complex script and it's way for deflickering. Can it be made usefull for deflickering without deinterlacing(bobing) on progressive frames (from DVD)? And will it be better than simple script like this so called Stab() (http://avisynth.org/mediawiki/Stab).

[Lynx Pardinus]

What if we combine MCBob and TempGaussMC? I mean using MCBob as the initial bobber for TemGauss instead of NNEDI or yadif.

Do we get the best from both worlds and get a better result or do we get the worst from both worlds?

I have made a try and to my eyes teh result looks better but I would like to know the experts opinion.

[TiGR]

What if we combine MCBob and TempGaussMC?
Wouldn’t that be slow as hell? :p

[Lynx Pardinus]

Of course I am asking quality wise not speed wise.

I know it is slow as hell, I have already tried it. 1 fps to get the MCBob and 1 fps for the TempGauss, 0.5 fps for a T5600.

[shoopdabloop]

0.5 fps!?

so does it produce the results you were hoping for?

[Lynx Pardinus]

I tested it on a video wich still had some noticeable flicker after TempGaussMC and, although it was still not perfect, almost all the flicker had dissapeared.

I also noticed that in some frames where MCBob had better results than TempGaussMC, the new result was closer to MCBob's.

[Terka]

Your math is wrong.
1fps,1fps, together 0,5fps? Lets assume PAL (50fps). MCbob is 1/50realtime. And after it every frame of MCbob is done again with speed of 1/50realtime. So 1fps is processing again, (again 50times slower than realtime).
1/50*1/50=1/2500
so you get 1 frame /50 s=0,02fps
I already tried it myselve few months ago, if you want, try mvbobmod instead of MCbob. Maybee its better.

[Gavino]

Your math is wrong.
1fps,1fps, together 0,5fps? Lets assume PAL (50fps). MCbob is 1/50realtime. And after it every frame of MCbob is done again with speed of 1/50realtime. So 1fps is processing again, (again 50times slower than realtime).
1/50*1/50=1/2500
so you get 1 frame /50 s=0,02fps
Your logic is wrong.
Realtime is irrelevant. Filters don't slow things down by some constant factor, they just take the time they need. By your argument, you could make MCbob run at 50fps by adding AssumeFPS(2500).

1fps + 1fps = 0.5fps is correct.
Each frame takes 1 sec in the 1st filter and 1 sec in the 2nd, so 2 secs in total.
1 frame in 2 secs = 0.5fps.

[Didée]

Hmh ... I never actually tried it that way (MCBob as internal basic bobber for TGMC), but ... thinking about it, that's using a sledgehammer to break a nut. I'd guess you had a similar result by adjusting the "repX" parameters of TGMC - which would come for free, instead of slowing the processing down to the speed of tectonic plate shift ...

In respect to "residual bob flicker", it is pretty much unimportant which kind of basic bobber is used. For that part in TGMC, even a simple bob() gives about the same stability as the more advanced bobbers. (Stability of the motion vector field is achieved mainly by the temporal gauss filter -- after which, there is hardly any important difference left over between bobber X or Y).

If you have a sample on which TGMC leaves noticeable flickering behind, just for fun try again with settings like TGMC(2,2,2,rep0=0,rep1=0,rep2=0, ...).

Does it still flicker? ... Ah, see!

Ofcourse, all rep's at zero is quite dangerous to produce artifacts in areas with non-predictable motion. The rep's have to be balanced for a suitable compromise between [risk-of-artifacts] and [flicker removal]. It's also highly dependent on the characteristics of the source. It's a long way from a 10th-gen VHS copy up to a HD DV-cam capture.
That's why there *are* parameters, instead of just hard-wiring everything.

[Terka]

Yes, i have a bug there, instead 0,02fps
should be 0,02 realtime.
sorry.
but the equation is ok. the numbers has to be multiplied.

[Terka]

When deciding to feed TGMC with something
We can say, there are 2 inputs to TGMC.
bob() for vectors creating
edi,nnedi etc. which is used for filtering and thus seen filtered in output.
So in fact we can change input 1) or 2).
Didee, am i correct?

so if you will go extra slow, put as:
input 1) something extra stable (TGMC with long temporal filtering)
input 2) something with original rows untouched and good resolution (MCbob or mvbobmod)
you will get it aproximately 4 times slower, hopefully also a small bit better than TGMC.

[Gavino]

Yes, i have a bug there, instead 0,02fps
should be 0,02 realtime.
sorry.
but the equation is ok. the numbers has to be multiplied.
If your logic was correct, it would in any case be 0,0004 realtime (1/2500).
But this is just wrong. The frame rate of the clip has no effect whatsoever on how long it takes the filter to process a frame, so please explain what realtime has to do with any of this. And where exactly does the multiplication come from?

As I said before, by your logic, you could make a script run 100 times faster by putting AssumeFPS(100*framerate()) at the start, which would be very nice, but is clearly nonsense.

[Didée]

Did anybody ever use "draft = 1" (or 2) in TGMC, and spend some minutes to reflect about the result? That's the searchclip, guys. draft=2 is the naked temporal gauss, and draft=1 is the repaired (by "rep0") version that is used to do the motion search on ...


Didee, am i correct?
Halfway between right and wrong. With more weight at the right than at the left. :)

TGMC uses only one internal bob filter. Depending on "EdiMode", that is either NNEDI or EEDI2 or Yadif, or none of them (plain bicubic). That's what is used both for final rendering *and* for constructing the searchclip for motion search. The choice of interpolator influences the final rendering, sure. But for the motion search, again, it does hardly matter.

Moreover, the searchclip already IS flicker-free (basically...it depends on "rep0", as mentioned previously). So there's little sense to feed an "external" super-duper-flickerfree clip for motion search ... because you don't *have* such a one. That's a chicken-and-egg problem. TGMC tries to produce a flickerfree result from interlaced input. So you basically suggest to make use of a result before you have it ...

Of course, one could do something along the lines of

TGMC( prefiltered = TGMC( prefiltered = TGMC( prefiltered= ..... ))..)

Whether that makes much sense remains to be proven ... but most likely not.
(For error elimination, usually one should combine different, "perpendicular", methods. Combining one method with itself can't eliminate an error inherent to the method.)

[Terka]

Find out that TG with blocksize 32 is good for some of my DV vids (static parts), but for moving parts are better smaller blocksizes.
Want to try mrecalculate for this, correct me, if im wrong.

function TempGaussMC_beta1modii(clip clp, int "tr0", int "tr1", int "tr2", int "rep0", int "rep1", int "rep2", string "EdiMode", int "EEDI2maxd",
\ float "sharpness", int "Smode", int "SLmode", int "SLrad", float "Sbb", float "SVthin", int "Sovs",
\ int "blocksize",int "blocksizec", int "overlap", bool "truemotion", bool "globalmtn",
\ int "search", int "searchparam", int "pelsearch", int "sharp", int "lambda", int "DCT", int "pnew", int "plevel", int "lsad",
\ int "SCth1", int "SCth2", int "thSAD1", int "thSAD2",
\ float "pel2hr", bool "border", int "draft",
\ bool "MT")
{
clp

# Defaults for temporal gauss filtering
tr0 = default( tr0, 2 ) # temporal radius for temporal Gauss before motion compensation (1 or 2)
tr1 = default( tr1, 2 ) # temporal radius for temporal Gauss with motion compensation (1 or 2)
tr2 = default( tr2, 1 ) # temporal radius for final MVDegrain (1, 2 or 3)

# Defaults for EDI interpolation
EdiMode = default( EdiMode,"EEDI2") # interpolator to use: "NNEDI", "EEDI2" "Yadif". Any other string: use plain bicubic bob (fast!)
EEDI2maxd = default( EEDI2maxd, 8 ) # EEDI2 interpolation only: spatial search distance value

# Defaults for temp-gauss reparation
rep0 = default( rep0, 4 ) # repair temporalsoften-defects for searchclip
rep1 = default( rep1, 0 ) # repair MVDegrain-defects for output (stage1)
rep2 = default( rep2, 4 ) # repair MVDegrain-defects for output (stage2)

# Defaults for contra-sharpening of the temp-gauss'ed clip
sharp0 = default( sharpness, 0.25+(tr1+tr2)/6.) # strength of sharpening, 0.0 to 1.0, or more if you like
Smode = default( Smode, 2 ) # Which method to use for re-sharpening the MC'ed temporal gauss:
# 0 = not at all
# 1 = 3x3 kernel
# 2 = vertical min/max plus 3x3 kernel
SLmode = default( SLmode, 2 ) # How to limit the sharpening:
# 0 = not at all
# 1 = spatial, before 2nd MV stage (fast)
# 2 = MC-temporal, before 2nd MV stage (slow)
# 3 = spatial, after 2nd MV stage (fast)
# 4 = MC-temporal, after 2nd MV stage (slow)
SLrad = default( SLrad, 1 ) # How much prev+next temporal neighbors to consider for sharpness limiting (SLmode = 2|4),
# resp. spatial radius for spatial sharpness limiting mode (SLmode = 1|3)
Sbb = default( Sbb, 1 ) # Back-blending of gauss-blurred sharpen's difference (slightly increases visual fidelity)
# 0 = no back-blending
# 1 = before sharp-limiting
# 2 = after sharp-limiting
# 3 = before AND after sharp-limiting
SVthin = default( SVthin, 1.0 ) # Vertical thinning of broadened horizontal edges. 0.0=OFF 0.5=weak 3.0=strrrong
Sovs = default( Sovs, 0 ) # Allowed "overshoot" for sharpness limiting (a little cheating, that is)

# Defaults for important MV-parameters
_bs = default( blocksize,16 ) # Blocksize for motion search
_ovlp = default( overlap,_bs/2) # Overlap size for ME blocks
_bsc = default( blocksizec ,0 ) # Blocksize for motion search MRECALCULATE
_ovlpc = default( overlap,_bsc/2) # Overlap size for ME blocks
_tm = default( truemotion,false) # Whether to use MVAnalyse's "truemotion" defaults
_global = default( globalmtn, true) # "global" parameter of MVAnalyse

# Defaults for "less important" MV-parameters
_search = default( search, 2 ) # search method
_ME = default( searchparam,2) # search depth
_pelsrch = default( pelsearch, 2 ) # accuracy of pel level search: 1 = fast, 2 = accurate
_shrp = default( sharp, 2 ) # sharpness of subpel interpolation
_DCT = default( DCT, 0 ) # DCT mode. Various modes may help or may harm ... default is 0 = OFF
_lambda = default( lambda, _tm ? 1000* _bs*_bs /64 : 0 ) # vector coherence
_lambdac = default( lambda, _tm ? 1000* _bsc*_bsc /64 : 0 ) # vector coherence
_pnew = default( pnew, _tm ? 50 : 0 ) # penalty for new vectors over predicted vectors
_plevel = default( plevel, _tm ? 1 : 0 ) # lamda level scaling mode
_lsad = default( lsad, _tm ? 1200*_bs*_bs/64 : 400*_bs*_bs/64 ) # local lambda resetting threshold
_lsadc = default( lsad, _tm ? 1200*_bs*_bs/64 : 400*_bsc*_bsc/64 ) # local lambda resetting threshold

# Scenechange thresholds and MVDegrain thSAD value.
# ***** DO NOT TOUCH WITHOUT SPECIFIC REASON *****
_SCth1 = default( SCth1, 180 ) # SAD threshold for "bad blocks"
_SCth2 = default( SCth2, 98 ) # percentage of bad blocks to trigger a scenechange
_thSAD1 = default( thSAD1, 5* 128 ) # SAD threshold for 1st MVDegrain (gaussian stage)
_thSAD2 = default( thSAD2, 2* 128 ) # SAD threshold for 2nd MVDegrain (linear stage)

# other stuff
border = default( border, true ) # true = padd borders internally to catch "half scanlines" at top + bottom (broadcast material)
draft = default( draft, 0 ) # '1' outputs a quick draft, and '2' is even more draft'ier :p
pel2hr = default( pel2hr, 0.0 ) # 0.0 is OFF. 0.1 ~ 0.3 can be useful to reduce halo-amplifying of pel=2 subsampling
MT = default( MT, false ) # true = use the multithreaded branch of MVtools
ST = mt ? false : true # Single-thread
RefineMotion = (_bsc!=0) ? true : false #use recalculate?


# parameter adjustments for internal usage
sharpness = default(sharpness, (SLmode==1||SLmode==3) ? sharp0 : 2*sharp0 ) # temporal limiting can afford more than spatial limiting
ed0 = rep0<10 ? rep0 : rep0/10
od0 = rep0<10 ? 0 : rep0-ed0*10
ed1 = rep1<10 ? rep1 : rep1/10
od1 = rep1<10 ? 0 : rep1-ed1*10
ed2 = rep2<10 ? rep2 : rep2/10
od2 = rep2<10 ? 0 : rep2-ed2*10
trmax = (tr1 > tr2) ? tr1 : tr2
use1 = (trmax > 0) ? true : false
use2 = (trmax > 1) ? true : false
use3 = (trmax > 2 || SLrad>1) ? true : false
thinn = SVthin * 6.0


#---------------------------------------------------------------------------------------------------
# Let's start doing something.

nullclip = blankclip(clp,width=16,height=16)

# if "border" is requested, apply padding by 4 pixels at top & bottom
clp = (border) ? clp.pointresize(clp.width(),clp.height()+8, 0,-4,-0,clp.height()+8.001 )
\ : clp
ox = clp.width()
oy = clp.height()

# Create spatially interpolated bob-clips
dbob = clp.bob(0,0.5)
edi = (EdiMode=="NNEDI") ? clp.nnedi(field=-2)
\ : (EdiMode=="EEDI2") ? clp.SeparateFields().EEDI2(field=-2, maxd=EEDI2maxd)
\ : (EdiMode=="Yadif") ? clp.Yadif(mode=1)
\ : (EdiMode=="NNEDI2")? clp.nnedi2(field=-2)
\ : dbob

# create linearily weighted temporal averaging
t1 = dbob.temporalsoften(1,255,255,28,2)
t2 = dbob.temporalsoften(2,255,255,28,2)

# construct temporal gaussian average from linear averages
t = (tr0==0) ? dbob
\ : (tr0==1) ? t1.merge(dbob,0.25)
\ : t1.merge(t2,0.357).merge(dbob,0.125)

# IF rep0=true: Allow only bob-typical vertical differences
t1 = t.VCRep(dbob,ed=ed0,od=od0)
t2 = (rep0!=0) ? t1 : t

# Create clip for motion search.
# Trick: weight-in a gaussian blur, to reduce local contrast of searchclip. (Needed to later make MVDegrain work as expected ...the "SAD concept" doesn't fit
# to the realities -- so, let's tailor the realities to fit the darn concept ...)
t3=mt_lutxy(t2,dbob,"x 3 + y < x 3 + x 3 - y > x 3 - y ? ?",U=3,V=3) # small cheat for better motion search
searchclip = t2.removegrain(11).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=2)
\ .merge(t2,0.1).mt_lutxy(t3,"x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?",U=3,V=3)


# Get motion vectors
_pel = 2

searchclipsuper = searchclip.msuper(pel=_pel,sharp=_shrp, levels=0)
recalculate = searchclip.MSuper(pel=_pel,sharp=_shrp, levels=1)



allv = nullclip

bvec3 = (use3) ? searchclipsuper.MAnalyse(isb=true, delta=3,truemotion=_tm,blksize=_bs,overlap=_ovlp,lambda=_lambda,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsad) : nullclip # ,sadx264=3
bvec3 = (use3&&RefineMotion) ? MRecalculate(recalculate, bvec3,isb=true, delta=3,truemotion=_tm, blksize=_bsc, overlap=_ovlpc,lambda=_lambdac,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsadc) : nullclip # ,sadx264=3
bvec2 = (use2) ? searchclipsuper.MAnalyse(isb=true, delta=2,truemotion=_tm,blksize=_bs,overlap=_ovlp,lambda=_lambda,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsad) : nullclip # ,sadx264=3
bvec2 = (use2&&RefineMotion) ? MRecalculate(recalculate, bvec3,isb=true, delta=2,truemotion=_tm, blksize=_bsc, overlap=_ovlpc,lambda=_lambdac,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsadc) : nullclip # ,sadx264=3

bvec1 = (use1) ? searchclipsuper.MAnalyse(isb=true, delta=1,truemotion=_tm,blksize=_bs,overlap=_ovlp,lambda=_lambda,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsad) : nullclip # ,sadx264=3
bvec1 = (use1&&RefineMotion) ? MRecalculate(recalculate, bvec3,isb=true, delta=1,truemotion=_tm, blksize=_bsc, overlap=_ovlpc,lambda=_lambdac,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsadc) : nullclip # ,sadx264=3

fvec1 = (use1) ? searchclipsuper.MAnalyse(isb=false,delta=1,truemotion=_tm,blksize=_bs,overlap=_ovlp,lambda=_lambda,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsad) : nullclip # ,sadx264=3
fvec1 = (use1&&RefineMotion) ? MRecalculate(recalculate, fvec1,isb=false, delta=1,truemotion=_tm, blksize=_bsc, overlap=_ovlpc,lambda=_lambdac,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsadc) : nullclip # ,sadx264=3

fvec2 = (use2) ? searchclipsuper.MAnalyse(isb=false,delta=2,truemotion=_tm,blksize=_bs,overlap=_ovlp,lambda=_lambda,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsad) : nullclip # ,sadx264=3
fvec2 = (use2&&RefineMotion) ? MRecalculate(recalculate, fvec2,isb=false, delta=2,truemotion=_tm, blksize=_bsc, overlap=_ovlpc,lambda=_lambdac,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsadc) : nullclip # ,sadx264=3

fvec3 = (use3) ? searchclipsuper. MAnalyse(isb=false,delta=3,truemotion=_tm,blksize=_bs,overlap=_ovlp,lambda=_lambda,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsad) : nullclip # ,sadx264=3
fvec3 = (use3&&RefineMotion) ? MRecalculate(recalculate, fvec3,isb=false, delta=3,truemotion=_tm, blksize=_bsc, overlap=_ovlpc,lambda=_lambdac,pnew=_pnew,
\ global=_global,search=_search,searchparam=_ME,pelsearch=_pelsrch,DCT=_DCT,plevel=_plevel,lsad=_lsadc) : nullclip # ,sadx264=3

vec1 = nullclip
vec2 = nullclip
deg2 = nullclip


# create motion compensated temporal averaging with linear weighting
#tr1 temporal radius for temporal Gauss with motion compensation (1 or 2)
edisuper= st ? edi.msuper(pel=_pel,sharp=_shrp, levels=1) : nullclip
mvdg1 = edi.MDegrain1(edisuper,bvec1,fvec1, thSAD=_thSAD1,thSCD1=_SCth1,thSCD2=_SCth2)
mvdg2 = (tr1>1) ? edi.MDegrain1(edisuper, bvec2,fvec2,thSAD=_thSAD1,thSCD1=_SCth1,thSCD2=_SCth2) : nullclip

# create explicit motion compensations (needed for SLmode = 2|4)
comp_fw1 = (SLmode==2 || SLmode==4) ? st ? edi.MCompensate(edisuper,fvec1,thSCD1=_SCth1,thSCD2=_SCth2) : edi.MVCompensate(fvec1,thSCD1=_SCth1,thSCD2=_SCth2,idx=7) : nullclip
comp_bw1 = (SLmode==2 || SLmode==4) ? st ? edi.MCompensate(edisuper,bvec1,thSCD1=_SCth1,thSCD2=_SCth2) : edi.MVCompensate(bvec1,thSCD1=_SCth1,thSCD2=_SCth2,idx=7) : nullclip
comp_fw3 = (SLmode==2 || SLmode==4)&& use3 ? st ? edi.MCompensate(edisuper,fvec3,thSCD1=_SCth1,thSCD2=_SCth2) : edi.MVCompensate(fvec3,thSCD1=_SCth1,thSCD2=_SCth2,idx=7) : nullclip
comp_bw3 = (SLmode==2 || SLmode==4)&& use3 ? st ? edi.MCompensate(edisuper,bvec3,thSCD1=_SCth1,thSCD2=_SCth2) : edi.MVCompensate(bvec3,thSCD1=_SCth1,thSCD2=_SCth2,idx=7) : nullclip

[Terka]

the continue:


# cheap halo-reduction for sharp pel modes (for Lmode=2|4)
cx1=comp_fw1.width()
cx3=comp_fw3.width()
cy1=comp_fw1.height()
cy3=comp_fw3.width()
comp_fw1 = (pel2hr==0.0) ? comp_fw1 : comp_fw1.mergeluma(comp_fw1.removegrain(11,-1).gaussresize(cx1,cy1,0,0,cx1+.0001,cy1+.0001,p=5),pel2hr)
comp_fw3 = (pel2hr==0.0) ? comp_fw3 : comp_fw3.mergeluma(comp_fw3.removegrain(11,-1).gaussresize(cx3,cy3,0,0,cx3+.0001,cy3+.0001,p=5),pel2hr)
comp_bw1 = (pel2hr==0.0) ? comp_bw1 : comp_bw1.mergeluma(comp_bw1.removegrain(11,-1).gaussresize(cx1,cy1,0,0,cx1+.0001,cy1+.0001,p=5),pel2hr)
comp_bw3 = (pel2hr==0.0) ? comp_bw3 : comp_bw3.mergeluma(comp_bw3.removegrain(11,-1).gaussresize(cx3,cy3,0,0,cx3+.0001,cy3+.0001,p=5),pel2hr)

# figure local min & max over given temporal window (for Lmode=2|4)
pmax = (SLrad>0) ? edi .mt_logic(comp_fw1,"max",U=3,V=3).mt_logic(comp_bw1,"max",U=3,V=3) : edi
pmax = (SLrad>1) ? pmax.mt_logic(comp_fw3,"max",U=3,V=3).mt_logic(comp_bw3,"max",U=3,V=3) : pmax
pmin = (SLrad>0) ? edi .mt_logic(comp_fw1,"min",U=3,V=3).mt_logic(comp_bw1,"min",U=3,V=3) : edi
pmin = (SLrad>1) ? pmin.mt_logic(comp_fw3,"min",U=3,V=3).mt_logic(comp_bw3,"min",U=3,V=3) : pmin

# create motion-compensated temporal gaussian blur
stage1 = (tr1==0) ? edi
\ : (tr1==1) ? mvdg1.merge(edi,0.25)
\ : mvdg1.merge(mvdg2,0.2).merge(edi,0.0625)

# IF rep1=true: Allow only bob-typical vertical differences
stage1 = (rep1!=0) ? stage1.VCRep(edi,ed=ed1,od=od1) : stage1


# calculate vertical median (for thinning), and vertical min-max-average (for sharpening)
vmedD = mt_luts(stage1,stage1,mode="median",pixels="0 -1 0 0 0 1",yexpr="128 x y - "+string(thinn)+" * -",U=1,V=1).blur(1,0)
vmedDD = mt_lutxy(vmedD,vmedD.removegrain(11,-1),"y 128 - abs x 128 - abs > y 128 ?")
st1mmavg = mt_average( stage1.mt_expand(mode="vertical",U=3,V=3),stage1.mt_inpand(mode="vertical",U=3,V=3),U=3,V=3 )
\ .mt_lutxy(stage1,"x y < x 1 + x y > x 1 - x ? ?",U=3,V=3)

# re-sharpen the temporal gaussian blur
stage1a = (Smode==0) ? stage1
\ : (Smode==1) ? stage1.mt_lutxy(stage1.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)
\ : stage1.mt_lutxy(st1mmavg.removegrain(11),"x x y - "+string(sharpness)+" * +",U=3,V=3)

# apply vertical thinning?
stage1a = (SVthin==0.0) ? stage1a : stage1a.mt_adddiff(vmedDD,U=2,V=2)

# apply 1st sharpening back-blending?
stage1a = ((Sbb==1 || Sbb==3) && Smode!=0 && sharpness!=0.0)
\ ? stage1a.mt_makediff(mt_makediff(stage1a,stage1,U=1,V=1).removegrain(11,-1).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=5),U=2,V=2)
\ : stage1a

# apply sharpening limiting? (SLmode 1|2)
stage1b = (sharpness==0.0) ? stage1
\ : (SLmode==1) ? ( (SLrad<2) ? stage1a.repair(edi,1) : stage1a.repair(stage1a.repair(edi,12),1) )
\ : (SLmode==2) ? stage1a.mt_clamp(pmax,pmin,Sovs,Sovs,U=3,V=3)
\ : stage1a

# apply 2nd sharpening back-blending?
stage1b = ((Sbb==2 || Sbb==3) && Smode!=0 && sharpness!=0.0)
\ ? stage1b.mt_makediff(mt_makediff(stage1b,stage1,U=1,V=1).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=5),U=2,V=2)
\ : stage1b

# final temporal filter for stabilisation, motion-compensated
stage1bsuper= st ? stage1b.msuper(pel=_pel,sharp=_shrp, levels=1) : nullclip
stage2 = (tr2==0) ? stage1b
\ : (tr2==1 && MT) ? stage1b.MVDegrainMulti(vec1,thSAD=_thSAD2,thSCD1=_SCth1,thSCD2=_SCth2,idx=8) : (tr2==1) ? stage1b.MDegrain1(stage1bsuper,bvec1,fvec1, thSAD=_thSAD2,thSCD1=_SCth1,thSCD2=_SCth2)
\ : (tr2==2 && MT) ? stage1b.MVDegrainMulti(deg2,thSAD=_thSAD2,thSCD1=_SCth1,thSCD2=_SCth2,idx=8) : (tr2==2) ? stage1b.MDegrain2(stage1bsuper,bvec1,fvec1,bvec2,fvec2, thSAD=_thSAD2,thSCD1=_SCth1,thSCD2=_SCth2)
\ : MT ? stage1b.MVDegrainMulti(allv,thSAD=_thSAD2,thSCD1=_SCth1,thSCD2=_SCth2,idx=8) : stage1b.MDegrain3(stage1bsuper,bvec1,fvec1,bvec2,fvec2,bvec3,fvec3,thSAD=_thSAD2,thSCD1=_SCth1,thSCD2=_SCth2)

# IF rep2=true: Allow only bob-typical vertical differences
stage2 = (rep2!=0) ? stage2.VCRep(edi,ed=ed2,od=od2) : stage2

## MVDegrain causes a chroma shift (yes it does, with pel>1 !) We compensate by shifting chroma towards plain EDI by a small notch
## [ 1+(x-1)/(1+(x/5)^4) ] on 128-centered diff-clip (x-y) ==> [ x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * + ? ]
#mod : disabled with MVTools2 since it has been corrected in MVTools 1.10.2.1
stage2 = mt ? stage2.mt_lutxy(edi,"x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * - ?",Y=2,U=3,V=3) : stage2

# apply sharpness limiting (SLmode 3|4), or has "draft" been requested?
stage3 = (draft==2) ? t .subtitle("Draft 2")
\ : (draft==1) ? t1 .subtitle("Draft 1")
\ : (SLmode==3) ? ( (SLrad<2) ? stage2.repair(edi,1) : stage2.repair(stage2.repair(edi,12),1) )
\ : (SLmode==4) ? stage2.mt_clamp(pmax,pmin,Sovs,Sovs,U=3,V=3)
\ : stage2


##########################################
# if "border" was active, crop it back again
(border) ? stage3.crop(0,4,-0,-4)
\ : stage3



return( last )
}

but getting invalid vector stream error. Where is the bug sitting there?

[Didée]

Copy/paste woes ... like e.g.

bvec2 = (use2&&RefineMotion) ? MRecalculate(recalculate, bvec3,isb=true, delta=2,truemotion=.....

there's more of those, check them all.

[Terka]

sorry, i put wrong file.
but when mrecalculating only bvec1 (to have only 1 line containing possible error, other mrec lines are commented):

bvec1 = searchclipsuper.MRecalculate( bvec1 )

still got error at line:
mvdg1 = edi.MDegrain1(edisuper,bvec1,fvec1, thSAD=_thSAD1,thSCD1=_SCth1,thSCD2=_SCth2)
"mvbw`s block size is incorrect"
my fault- have to change BOTH bvec1 and also fvec2

[Didée]

Sorry, but I can't tell what's causing that problem for you. The following simple code does work for me:
(Using MVtools2 - v2.4.7, just downloaded a few minutes ago)

o = last
osup = o.msuper()
bv1 = osup.manalyse(isb=true, blksize=32,overlap=16)
fv1 = osup.manalyse(isb=false,blksize=32,overlap=16)
bv1a = osup.mrecalculate(bv1,thSAD=200,blksize=8,overlap=4)
fv1a = osup.mrecalculate(fv1,thSAD=200,blksize=8,overlap=4)

dg1 = o.mdegrain1(osup,bv1,fv1)
dg1a = o.mdegrain1(osup,bv1a,fv1a)

stackhorizontal(dg1,dg1a)
Right now, the only advice is: check all your syntax & parameters very carefully.

Note that you need either *all* or *none* of the vector clips to be recalculated (at least when changing the block-size). It will not work if some of the vector clips are mrecalculate'd and some are not.

___

edit - saw your edit only after submitting my post. Seems the problem is solved.

[Terka]

Didee, thank you. its solved now. It looks like that the logic - first 32, then 4 blocksize looks better. now i have to check on different sources.
maybee there is a question, if also change the "calmclip" for the mrecalculate, or have same clip for both searches.
And there is a question, which setting to change for 2nd search (blocksize,..)?

[Didée]

Yes ... when using vector re-calculation in such a way, it might be better to use a less aggressively (or not at all) filtered searchclip for the re-calculation. Or it might not, you never know. That's question hard to answer from a theoretical point of view ... meaningful answers would come only by doing lots of experimentation.
(Which I'm not about to do these days - it's up to y'all, folks.) ;)

[Terka]

Didee,
i am testing alot :)
btw:
ed0 = rep0<10 ? rep0 : rep0/10
od0 = rep0<10 ? 0 : rep0-ed0*10
gives me od0 always 0. I suppose this is not the expected behaviour?

[Didée]

That piece of code does exactly what it's supposed to do. The numbers for "repX" may carry two parameters in one number. The first part is the erosion distance, the 2nd part is the distance for over-dilation - e.g.

rep0 = 13

doesn't read "thirteen", but it reads "one-three", and means

"for repairing the difference mask of stage 0, use erosion = 1 , overdilation = 3".

As long as a single-digit is specified (like e.g. "rep0=2"), the overdilation distance is zero. (i.e. the dilation distance is equivalent to the erosion distance)

The motivation behind was that, in case of very strict repairing of the difference mask (i.e. allowing only very little error), over-dilation might give a bit more headroom to rescue more of the wished effect from being erroneously repaired.

Honestly, I can't tell whether over-dilation makes any noticeable improvement or not. I did put it in just in case ... the theoretical POV is that it might help occasionally, while it's almost impossible to do any harm.

[Terka]

i see.
i couldnot chceck myself, because i dont know how to see a value of numeric variable. following doesnot work:

var=5
clp.subtitle(var)
so the divide is provided on integers, so for
ed0 = rep0<10 ? rep0 : rep0/10
od0 = rep0<10 ? 0 : rep0-ed0*10
rep0=13, ed0=1 not 1.3?

[Gavino]

i couldnot chceck myself, because i dont know how to see a value of numeric variable.
clp.Subtitle(string(var))
so the divide is provided on integers, so for
ed0 = rep0<10 ? rep0 : rep0/10
od0 = rep0<10 ? 0 : rep0-ed0*10
rep0=13, ed0=1 not 1.3?
Assuming rep0 is type integer, yes.
To get 1.3, you would need to convert it to a float
float(rep0)/10

You should read this page (http://avisynth.org/mediawiki/Script_variables) about types and variables.

[Terka]

Thank you!

[vorob]

Got XR500E camera, and "steps" on some lines in video was my real headache. But now, using this deinterlace method I've got real 50fps video without any crap.

The only problem is speed. Got 0,5 fps on my pc
http://vorobfiles.narod.ru/Config/config.htm

My question is, are development stopped or not? Any info on speeding this process via video card?

[elguaxo]

Any info on speeding this process

try faster settings:
http://forum.doom9.org/showthread.php?p=1325335#post1325335
http://forum.doom9.org/showthread.php?p=1325620#post1325620

[Revgen]

I updated thetoof's tempgaussmc_beta1mod to support EEDI3 and NNEDI2. EEDI3 is very slow right now and IMO should only be used for testing until Tritical releases an optimized version. EEDI3 is enabled by default. Use EDImode="NNEDI2" to use NNEDI2.

http://www.sendspace.com/file/jyviyv

[Terranigma]

His is the MT version. Update the non-MT version i've posted as well. :P
http://forum.doom9.org/showthread.php?p=1340412#post1340412

[aegisofrime]

I have an urgent an unusual request:

I have been having problems with my Phenom II PC and am considering upgrading to a Core i7. Can somebody with the Core i7 help me out by running a quick benchmark? I need to know how many FPS you get by running TGMC x264 encoding on the Core i7-860/920 with DVD content. Thanks!

[sarmano]

Computer: Core2Quad Q6600 - proc, 4gb - ram

TempGaussMC_beta1u(2,2,3, 0,0,53, "blah", sharpness=1.0, Sbb=3, Smode=2, pelsearch=2, blocksize=16, overlap=8, thSAD2=8*8*3, DCT=10, search=5, searchparam=5, rfilter=2, sadx264=12) (* - MRecalculate(8:4) of MAnalyse(16:8) for final stage, ** - MVTools2 MT version)

on HD movie 1920:1080p - encoding x264 ~ 0.40fps on 4pass
on DVD movie (not tested yet) I think ~2.8-3.6fps 2pass

So, I think Core i7 do this about 1.7-2.5x speed.

[Didée]

TempGaussMC_beta1u(2,2,3, .....) (* - MRecalculate(8:4) of MAnalyse(16:8) for final stage, ** - MVTools2 MT version)
Your post is a bit confusing. There are * and ** footnotes, but I don't see the the corresponding * / **'s which they could refer to??

Whatever. Is there a mod of TGMC that actually implements MRecalculate? If so, I'd like to have a look at it!

(MRecalculate is a good potential addendum to TGMC indeed. The pitfall is that the most obvious place to put it in is a bad suited place to put it in. Doing it the obvious way means big effort for little benefit.)

[sarmano]

Didée , Terka

I edit TempGaussMC_beta1u.avs for myself, so probably it's code that will not be clear or seems superfluous, but it's well.

This is what I do and how
http://www.mediafire.com/?zdymw2jwmnn


Didée
MRecalculate does calculation of already made operations, specifies them and really in most cases it is only additional step for uncertain, but actually opportunities are more extensive on use, for example, use the following scheme

MAnalyse
MRecalculate
a = MDegrain1 (MAnalyse)
b = MDegrain1 (MRecalculate)
Something(a,b)

- or -

MAnalyse
MRecalculate
MRecalculate (again for the first MRecalculate)
b = MDegrain1 (MRecalculate on MAnalyse)
c = MDegrain1 (MRecalculate on MRecalculate)
Something(b,c)

- or -

MAnalyse (all vectors)
MRecalculate (only first and second vectors)
MRecalculate2 (again for the first MRecalculate only first vectors)
# do? b = MDegrain1 (MRecalculate on MAnalyse)
# do? c = MDegrain1 (MRecalculate2 on MRecalculate)
# do? Something(b,c)
MCompensate(all vectors)
MDegrain1(compensated)
MCompensate(only first vectors for MRecalculate2)


seems to me will be interesting step, but it is required to understand time all complexity of the conceived operations on vectors. For me now It's like a 1-2-3 pass stats of encoding.

I only experiment systems studying results of actions only from the visual point of view and speed at reception of necessary results.
The mathematical approach to calculations most likely will be more preferable, but on it there is no necessary time.

I know that I'm wrong on some operations but I try to understanding...


btw: If 3rd scheme used then MDegrain did smooth stronger on high thsad, it's cool I think.
Mdegian becomes operated at smaller quantity of passes and performance on blocks of overlappings less than 8.

[Didée]

a) MRecalculate does not automatically provide better vectors.

b) that bunch of scripts and functions is pretty much convoluted. All I can see at a quick glance is that myriads of vectors are computed, and the myriads then even are MRecalulate'd.
I have no clue what you are doing there. Seriously, do you?

c) An easy one is that you are loading a source at 23.976 fps. Under normal circumstances, such a source is not even a target for TGMC. I have no clue what you are doing.


I don't feel like doing deeper analysis of what exactly your filter armada might be supposed to do or to improve. If you have a handy explanation, speek freely! Though, fFrom your description in the previous post I also can't see any hard points ... all of that is pretty nebulous to me. The only really interesting part, if at all, would be in the something(a,b) operation. Alas, there is zero hint what it should do, or why, or how ...

I'm generally all ears for questions of the type "Hey, there is problem 'X' / deficiency 'Y' / shortcoming 'XYZ' , couldn't we improve by doing [so] or [this] or [that]."

In contrast, strategies like "Hey, we have this funky MRecalculate filter, sounds like it's somehow made for improving, let's kick it in in a few places!" are of no interest to me.

My preferred strategy is "reckognize a problem, formalize it, solve it." (I'm not at all a strict formalist. But I like to have a clear red line of what should happen, and why.)

For those liking to poke in the blue - I wish happy poking, but don't expect me to comment if you're poking warm, or cold, or hot.

[sarmano]

Didée

It's just experiments that all.
All I want - totally denoising movie with perfect image and faster of course :).
Naked TempGauss make terrible results for me, so I disable it.
I'm using TGMC only as function of MC.
Another ideas U're using inside TGMC very impressive.


Compare please my little idea with source and original TGMCmod:
http://img248.imageshack.us/img248/9922/sourcem.th.png (http://img248.imageshack.us/i/sourcem.png/)
http://img684.imageshack.us/img684/7207/tgmc.th.png (http://img684.imageshack.us/i/tgmc.png/)
http://img15.imageshack.us/img15/7725/ideap.th.png (http://img15.imageshack.us/i/ideap.png/)

My last idea much much faster then TGMC.
So...


PS. Try my scripts, it's easy.
I used not only "stupid" code ;)

[Didée]

Well ... did you hear what I said? Your source is progressive. TGMC is a deinterlacer. Using a deinterlacer on a progressive source is not such a good idea in general.

Also, the denoising effect of TGMC is just a sideffect of the method. It's in no way optimized to be particularly good at denoising ... if the task is just about denoising+sharpening a progressive source, then of course I would not use TGMC, but some other dedicated scripts or functions.

So you used the wrong filter in the wrong place, and then present the conclusion that you get better results with some other filter chain. Very entertaining! - I've seen comedy shows with worse plots than that.

[sarmano]

I hear, U cant...

TempGauss
# create linearily weighted temporal averaging
t1 = dbob.temporalsoften(1,255,255,28,2)
t2 = dbob.temporalsoften(2,255,255,28,2)

# construct temporal gaussian average from linear averages
t = (tr0==1) ? t1.merge(dbob,0.25)
\ : (tr0==2) ? t1.merge(t2,0.357).merge(dbob,0.125)
\ : dbob

Deinterlacer
# Create spatially interpolated bob-clips
dbob = clp.bob(0,0.5)
edi = (EdiMode=="NNEDI") ? clp.nnedi(field=-2)
\ : (EdiMode=="EEDI2") ? clp.SeparateFields().EEDI2(field=-2, maxd=EEDI2maxd)
\ : (EdiMode=="Yadif") ? clp.Yadif(mode=1)
\ : dbob

Thats all. Is it wrong?
You used Mdegrain1 for first vectors and again MDegrain(1-2-3) for all vectors as option, is it for deinterlacing?


Try some like this:
MVDegrain1 to clp.nnedi(field=-2)
MVDegrain3 to eedi3(searchclip=nnedi2())

[Didée]

Yes, you quoted the script parts correctly. But what is your suggestion aiming at? Plain deinterlacing? Bobbing? Or neither of both, but just denoising? And again ... whatever you are aiming at: what is the improvement over existing methods? In which respect is it supposed to do better?

See, you throwed a bunch of code on the table. I asked "Why/what for?". The answer I got is: "Try this: <code>".

[sarmano]

Didée

I cant explain all I want to say, my english to bad for this.
Your scripting more usefull for another operations then You right now thinking ;)
So we can develop more and more. This is my idea.

I think TGMC be very popular not for it functions, it's slow, very slow and it will do some cool but no one i think trying to do to make some more specific parts for better work of it.

For me right now tgmc's a script that can do deep compared sharping without loosing data (maybe a little) and compensating. MDegrain do some to make image more precisely that has spoiled by temporalsoften. This part slow down to much the speed.

I need a clip to make some stuff on it.
The code I see in TGMC do the same I wrote early. I try change only parts that important for myself and do it faster and better a little.
Deinterlacer inside it's a directly EDI function, so if we've it then we can try manipulating them.

For example, EDI can do change not directly on image but

origImage 720/480:
luma -> resize image to 1420/480 -> do sharp then mini or medium thin smooth -> resize back to 720/480
chroma -> resize image to 360/240 -> do strong smooth -> resize back to 720/480 -> sharp it
compare it with original
merge important different parts with original
compensate with light mdergain1
This is a reflection.

I need too a plan what and why I do something but I need a real clip not generated to try.
Everyone want more speed of operation. This part very very important.

[Didée]

Okay ... now you raise twi points: 1) speed of TGMC and possible improvement / 2) Usage of TGMC for applications other than deinterlacing


a) Speed

You won't get TGMC worthwile faster than it is now. Remember that you can reduce or switch-off several of its "sophisticated" operations. I know what TGMC does and why, and be assured: whatever TGMC is told to do, the implementation is at least so good that you won't squeeze out noticeably more speed, for the same result.

What about this: (Note I'm on a single-core, still...)

source.NNEDI2(field=-2)
=> 8.5 fps

source.TGMC_beta1u(1,1,0,EdiMode="In.a.hurry",Smode=1,SVthin=0.0,Sbb=0,SLmode=1|2)
=> 9.0 | 8.5 fps

Those are heavily reduced settings that still do something "reasonable". TGMC is still doing "complex" spatio-temporal processing, including active motion search & compensation, contra-sharpening, and all that stuff. In contrast, NNEDI2 is "only" doing spatial interpolation. Leaving multithreading aside, looking only at the mere computational effort, one can see that TGMC is about the same speed as NNEDI2. (!)

Seeing that TGMC's basic speed is similar to NNEDI2, I consider point a) hereby finished.


b) Other applications than deinterlacing

Sure. The possible ways to do [this] or to achieve [that] often are quite similar, or atleast appear to be so. Several principles and tidbits of TGMC can be successfully used for denoising, for sharpening, to some extend even for upscaling. And for possible combinations for all of these.
But, if I want to do any of these, then surely I won't use TGMC. Instead, I would just use those tidbits that are suited for the planned operation. There's plenty of stuff in TGMC that has not the slightest justification to be used in conjunction with progressive input ... examples: all "bobbing" operations in TGMC of course are total nonsense on progressive input. The "gaussian" temporal element does not make much sense in that case as well. And a few more hidden ones ... e.g. several operations are "vertically oriented", which is fully on purpose for bobbing, but rather pointless for progressive input.
Taking these two major elements out of the game, there is not any good reason to take TGMC as basis for further investigations ... because at this point, there's not much left over.
Instead, start from scratch. It's the better way.

Useful elements are (or can be) ... the pre-denoising principle, but that's an old hat, the method is used for a long time by now. Also the contrast-reducing trick, though it could be made a bit smarter for general application (SAD threshold scaled to presence of edge-magnitude in a given block, that would be something). Sharpening plus temporal-limiting is also useful - but this, too, has been shown before. The thinning principle is a useful puzzlepiece for upscaling, but for that purpose it should (IMHO) be assisted by some impulse enhacement.

And so on, bla blah, bla bleh, bla bluh ...


If you want to point me to something that I didn't think of yet, that's a nice intention. But to succeed with that, you need to try harder. Much harder. You have no picture how far my mind has been travelled already.

[sarmano]

Didée

Yeah...
You have no picture how far my mind has been travelled already.
I think this a big problem!
Be simple. ;)

I've understood all aforesaid. TempGauss as idea not working for me as method on video, for static image maybe.
Nevertheless, thanks a lot for ideas. They're really new, interesting and usefull.

I try that all. ;)

[Didée]

TempGauss as idea not working for me as method on video, for static image maybe.
I give up.

[Terka]

Hi Didee,
i must smile to see there are even worse ones ^, than i am.
I didnot play with the deint stuff for a while, because no new cray-sy ideas. But.. you mention something, so i hope, you will
jump over the pitfall you mentioned.
So do you think you will show us something new?
ive tried to put mrecalculate to tgmc, because for static using of larger blocks looked better for me.
so the 'mod' if i can call it so, was only 2 different blksizes and thresholds.
but you were speaking about correct place to put the mrecalculate....

[Didée]

There are two different possible aspects of vector recalculation: a) adaptive blocksize, and b) better catch on motion.

a) is obvious - just recalculate the vectors with a smaller blksize.

The point with b) is that TGMC uses a "flattened" searchclip, because of the thSAD problem I explained in the past. That's okay for getting SADs that allow MDegrain to do the expected job. But it's suboptimal in regard to the plain motion search: the flattening reduces data, hence the motionsearch could be impaired. It would be better to do the MAnalyse's on the original calmed searchclip (namely "t2"/"t2_super"), and only then use MRecalculate to update the SADs in respect to "searchclip"/"srch_super".

The pity is that to do *both* a) and b) together in a reasonable way, you need two instances of MRecalculate for each vectorset. Together with the possibility that one may specify different search parameters for each recalculation stage, this would allow to boost TGMC from (now) 20 different parameters to (then) 50 different parameters. (Or thelike, I didn't count those numbers. You know what I mean: too much parameters are too much parameters.)

It's actually not very difficult to implement such options, only a bit elaborative. (And I'm lazy with scripting these days - much less time for digital video, much more for square art (http://www.flickr.com/photos/44056535@N03/).)
Also, I hardly see complaints that TGMC isn't good enough - but complaints that TGMC is too slow, those I see quite often. Therefore my motivation is low to make a boring implementation that enables small improvements (which most people never would even notice), but makes things a good bit slower (upon which everyone would cry MURDER).

[Terka]

i see.
and the pitfall is to do the select of the more precise ones?
how to do it?
btw.
1. there are complaints about 'artefacts'.
2. imho some people complaining about speed want to spend the processor time for insane x264 settings
to lower the bitrate and have better quality. so IMHO coplaints about speed are de-facto complaints about quality. ;)

[Boulder]

It's actually not very difficult to implement such options, only a bit elaborative. (And I'm lazy with scripting these days - much less time for digital video, much more for square art (http://www.flickr.com/photos/44056535@N03/).)

OT: Is your surname by any chance "Gaff"? Nice work :)

[Didée]

Terka - sure, there are all sorts of complaints. But from what I hear, quality/artifacts is more seldom the point. People would probably like to use TGMC if, oh if only it was 10 times faster. That's only loosely related to quality. People want to finish their encodes in a few hours, not in a few days. For many, Yadif is the only usable deinterlacer, because it runs so fast ... innumerous people that care only for Yadif's speed, and don't even notice that its quality often is questionable.

Oh, and I forgot to mention another point about adaptive blocksize by MRecalculate: though it's good to have it, the actual method is a bit unsatisfying. And one more time, it's the darn fixed-threshold principle: " SAD(block) < [thresh] ? good : bad" This mostly works out for hard edges, but it has a tendency to fail when there are no hard edges, like e.g. on motion-blurred moving objects.
I have experimented with an adaptive method, and it seemed to me that it works better. Method: do a full search + compensation at blocksize [big], and a full search + compensation at blocksize [small]. Get SAD mask from both. If SAD of [small block] is better by 50%, use it. Else, keep the result of [big block]. (The 50% is an example, actually this is a parameter. Also, I didn't really use a fixed threshold, but instead a sliding threshold zone like 30% to 60%.) The point is that this won't use the small block just because it's a tiny bit better (and thereby lose the big block's stability without necessity), and it won't fail to use the small block because SAD is generally low in a given area. Instead, it (mostly) succeeds to use small blocks in those areas where the small block achieves a *worthwile* improvement over the big blocksize.
But then, of course the implementation is quite slow and cumbersome. Doing full compensations, producing masks, compairing the masks, then doing maskedmerge. And after this, you still can't use MDegrain with it, but you have to simulate MDegrain with the interleave/ttempsmooth/select procedure. Hence, it is a purely proof-of-concept method, but not really practical due to the speed. And just to be clear - this method also can not "just quickly" be implemented into MVTools. The current method of MRecalculate is ~relatively~ easy and straightforward. The method I described is more like a complex processing chain.
Still, when you know that things could be done better, then it's much less fun to use the available "if it's green, it must be a vegetable" methods.


@ Boulder - no, it's still Didée.;) Gaff's objects are nice eyecatchers, but in fact they are lame. E.g: The unicorn is made of three different pieces which are sticked together. And the stickman is either multipiece, or cheated by cutting/tearing. Such is not the pure art. The pure art is One Square, and no cutting/gluing. The idea is that you can take the finished result, and revert it back to the original square, unspoiled.

[WorBry]

The pure art is One Square, and no cutting/gluing. The idea is that you can take the finished result, and revert it back to the original square, unspoiled.

Hence the little known and subtle relationship between One Square and a pure bob deinterlacer.......sorry, I couldn't resist :D

[aegisofrime]

It's funny because I personally use TGMC alot on progressive sources. I do not claim to be an expert: As the author of this script you Didee obviously knows far more than anyone of us as to how TGMC work. I'm also not saying that TGMC is made for bobbing progressive sources, however from my own experience, TGMC is very often better with MVTools. One huge reason why I prefer TGMC over MVTools is that if I use the double frame-rate script:

super = MSuper(pel=2)
backward_vec = MAnalyse(super, overlap=4, isb = true, search=3)
# Use block overlap, halfpixel accuracy and Exhaustive search
forward_vec = MAnalyse(super, overlap=4, isb = false, search=3)
MFlowFps(super, backward_vec, forward_vec, num=2*FramerateNumerator(last), \
den=FramerateDenominator(last))


I get an obscene amount of ghosting during fast motion scenes. TGMC has a much better output here.

[shoopdabloop]

Hence the little known and subtle relationship between One Square and a pure bob deinterlacer.......sorry, I couldn't resist :D

that reminds me, why do line-interpolaters like NNEDI2 not leave the original lines unfiltered?

[thetoof]

aegisofrime, TGMC on a progressive clip will duplicate every frame , while the mflowfps script you posted tries to interpolate (i.e. create a new frame that would be an intermediate between the two original ones)

TGMC = A A B B C C
mflowfps = A AB B BC C CD

Other example - imagine a wonderful dance move where you'd have to move your arm for pointing upwards to in front of you.
TGMC 1-2 = up, 3-4 = front
mflowfps 1 = up, 2 = 45 degrees (between up and front), 3 = front....

See, 2 different goals. If you want to double the frames, a changefps(framerate*2) will do just about the same, only much (MUCH) faster.
If you want to simulate smoother motion, try mflowfps for mo-comp or convertfps for blends......

[Didée]

thetoof - that's spot-on what theory tells. However, practice often is a bit different from theory. ;)

TGMC on progressive input - yes, it should give an AA BB CC... pattern. But there's more to it. Due to the bob-frame ordering, the number of different motion states is not equal in forward and backward direction. Since the search-clip is preprocessed with some TemporalSoften, this can lead to the effect that MVTools finds slighty different vectors for two Bobframes that belong to the same progressive sourceframe. So the produced pattern in fact can be more like 'A A' 'B B' 'C C'... , i.e. with some mini-motion between the same-lettered frames, as indicated by the ' signs.
The strengh of this effect is not exactly predictable, and it also depends strongly on the repX-settings: the more strict repX is set, the lesser the effect will be.


mflowfps 1 = up, 2 = 45 degrees (between up and front), 3 = front
That's exactly what we expect MFlow(FPS) to produce. Alas, exactly this is what we hardly ever get from it. If an arm points forward in one frame, and upward in the next frame, then the interpolated middle frame will not show the arm pointing at 45°. Instead, it most likely will produce funky artifacts of varying degree. The motion engine will not be able to connect these two motion states, since their representation is so different that MAnalyse can not reckognize the belonging-together parts as belonging together.

[aegisofrime]

thetoof - that's spot-on what theory tells. However, practice often is a bit different from theory. ;)

TGMC on progressive input - yes, it should give an AA BB CC... pattern. But there's more to it. Due to the bob-frame ordering, the number of different motion states is not equal in forward and backward direction. Since the search-clip is preprocessed with some TemporalSoften, this can lead to the effect that MVTools finds slighty different vectors for two Bobframes that belong to the same progressive sourceframe. So the produced pattern in fact can be more like 'A A' 'B B' 'C C'... , i.e. with some mini-motion between the same-lettered frames, as indicated by the ' signs.
The strengh of this effect is not exactly predictable, and it also depends strongly on the repX-settings: the more strict repX is set, the lesser the effect will be.



That's exactly what we expect MFlow(FPS) to produce. Alas, exactly this is what we hardly ever get from it. If an arm points forward in one frame, and upward in the next frame, then the interpolated middle frame will not show the arm pointing at 45°. Instead, it most likely will produce funky artifacts of varying degree. The motion engine will not be able to connect these two motion states, since their representation is so different that MAnalyse can not reckognize the belonging-together parts as belonging together.

Thank you for the explanations thetoof and Didee. While I understand that TGMC is not made for bobbing progressive sources, and MFlowFPS is, unfortunately alot of times in practice I find that TGMC works better. In fact, moving arms are one of the main problems with MFlowFPS, and the problem is exactly what you described Didee. I get a watery ghostly kind of image. Maybe I'm knocking a square peg into a round hole, but the ends justify the means, and so for some sources at least, I prefer using TGMC.

[Leak]

that reminds me, why do line-interpolaters like NNEDI2 not leave the original lines unfiltered?
:confused:

They do...

[shoopdabloop]

Really? Hm, for some reason I was under the impression that they didn't.

[IanB]

Which is why you get this flicker.

T is top field data, B is bottom field and x are the interpolated values.

T x T x
x B x B
T x T x
x B x B
T x T x
x B x B

In order for x values to be non flickering with respect to both it's spatial buddies and it's temporal buddies you need to tweak all the buddies.

[2Bdecided]

beautiful paper folding and deinterlacing progressive sources. this thread is just surreal.

Oh, and I still use TGMC on HD when I really need to - e.g. when I need to zoom+crop.


FWIW I noticed TGMC did very little damage to the progressive parts on hybrid sources (25p + 50i). I like it for this (on its own - no adaptive i/p detection - because that can create its own problems), but it's too slow. ;)

Cheers,
David.

[Terka]

Hi Didee,
1. bigger coherence gives me better results for TGMC in static. what a surprice :eek:
2. what about use the "TGMC denoising" as edeint.
so the tdeint result will be quite calm (in compare to clp.nnedi2(field=-2).
And use mild denoising to finish the result.
So something like:
its quick-not much tested. "TGMC denoising"=degrainX is stolen from TGMC. same as VCRep.
yes 2 times motion search, maybee can be done 1 times. What do you think?



clp.TdeintTMMnnedi2up().degrainx(SAD1=100,x=3)

function TdeintTMMnnedi2up(clip c, int "qual")
{
GetParity(c) ? AssumeTFF(c) : AssumeBFF(c)
edeint=nnedi2(c,field=-2,qual=qual).degrainx(x=3)
Tdeint(c,mode=1,emask=TMM(mode=1),edeint=edeint)
}
function DegrainX (clip o, int "calm", int "rep0", int "X", int "SAD1", int "bs", int "limit", bool "external_denoiser")
{
# makes MDegrain1-3 for deinterlace
# Calm function is needed

X = default( X, 3 ) # MVDegrain 1, 2 or 3
calm = default( calm, 1) # use calm() for predenoising as default
bs = default( bs, 16 ) # blocksize
SAD1 = default( SAD1, 400 ) # Threshold for degraining. Decrease if you see ghosting
limit = default( limit, 255 ) # Limits maximum change of a pixel. Default means no limit
ov = bs/2 #overlap
rep0 = default (rep0, 4)


calm=(calm==1) ? o.Calm(rep0): o

o_super = o.MSuper(pel=2, hpad=16, vpad=16, levels=1) # create the source superclip
srch_super = calm.MSuper(pel=2, hpad=16, vpad=16) # create the calm superclip

bv3 = (X==3) ? srch_super.MAnalyse(isb=true , delta=3, blksize=bs, overlap=ov) : BlankClip
bv2 = (X>=2) ? srch_super.MAnalyse(isb=true , delta=2, blksize=bs, overlap=ov) : BlankClip
bv1 = srch_super.MAnalyse(isb=true , delta=1, blksize=bs, overlap=ov)

fv1 = srch_super.MAnalyse(isb=false, delta=1, blksize=bs, overlap=ov)
fv2 = (X>=2) ? srch_super.MAnalyse(isb=false, delta=2, blksize=bs, overlap=ov) : BlankClip
fv3 = (X==3) ? srch_super.MAnalyse(isb=false, delta=3, blksize=bs, overlap=ov) : BlankClip


NR = (X==3) ? o.MDegrain3(o_super, bv1, fv1, bv2, fv2, bv3, fv3, thSAD=SAD1, limit=limit) :
\ (X==2) ? o.MDegrain2(o_super, bv1, fv1, bv2, fv2, thSAD=SAD1, limit=limit) :
\ o.MDegrain1(o_super, bv1, fv1, thSAD=SAD1, limit=limit)



#NR.mt_lutxy(NR.removegrain(11),"x x y - "+string(0.45)+" * +",U=3,V=3)
NR.sharpen(0,0.4)
return (last)
#return (NR)
}



function Calm (clip clp, int "rep0")
{
##################################
# PREPARES CLIP FOR MOTION SEARCH
#################################
#needs VCRep

rep0 = default (rep0, 4) # repair temporalsoften-defects for searchclip
ed0 = rep0<10 ? rep0 : rep0/10
od0 = rep0<10 ? 0 : rep0-ed0*10
ox = clp.width()
oy = clp.height()

# create linearily weighted temporal averaging
ts1 = clp.temporalsoften(1,255,255,28,2)
ts2 = clp.temporalsoften(2,255,255,28,2)

# construct temporal gaussian average from linear averages
t = ts1.merge(ts2,0.357).merge(clp,0.125)

# IF rep0=true: Allow only bob-typical vertical differences
t2 = (rep0!=0) ? t.VCRep(clp,ed=ed0,od=od0) : t

# Create clip for motion search.
t3=mt_lutxy(t2,clp,"x 3 + y < x 3 + x 3 - y > x 3 - y ? ?",U=3,V=3) # small cheat for better motion search
searchclip = t2.removegrain(11).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=2)
\ .merge(t2,0.1).mt_lutxy(t3,"x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?",U=3,V=3)
return (searchclip)
}

[7ekno]

source.TGMC_beta1u(1,1,0,EdiMode="In.a.hurry",Smode=1,SVthin=0.0,Sbb=0,SLmode=1|2)
=> 9.0 | 8.5 fps


Might be a stupid question, but where does one find "TGMC_beta1u"?!?

Can find beta1 and beta1mod on the Wiki entry, can find various MT and MVTools2 versions in this thread, just can't seem to find the elusive "beta1u" version (or is it outdated?!?) ...

7ek

[Didée]

Yeah ... too much modd's, moddy-mod's, and mod-of-the-mod-of-the-modded-mod ...

To clarify things a bit, here's a link that leads to a link that leads to a link (http://forum.doom9.org/showthread.php?p=1347200#post1347200). :D

[7ekno]

LOL, thanks, I did find that one, just didn't look at the function name!

Cheers,
7ek

[nikosvault]

I updated thetoof's tempgaussmc_beta1mod to support EEDI3 and NNEDI2. EEDI3 is very slow right now and IMO should only be used for testing until Tritical releases an optimized version. EEDI3 is enabled by default. Use EDImode="NNEDI2" to use NNEDI2.

http://www.sendspace.com/file/jyviyv

How did you combine EEDI3 and NEDI2 like you did in that NHL clip (the TGMC + EEDI3 + NEDI2 example):rolleyes:

[Revgen]

How did you combine EEDI3 and NEDI2 like you did in that NHL clip (the TGMC + EEDI3 + NEDI2 example):rolleyes:

It's the default EDIMode of the script I posted. It's the bold part of this section of the script.


# Create spatially interpolated bob-clips
dbob = clp.bob(0,0.5)
edi = (EdiMode=="EEDI3") ? clp.eedi3(field=-2,sclip=clp.nnedi2(field=-2))
\ : (EdiMode=="EEDI2") ? clp.SeparateFields().EEDI2(field=-2, maxd=EEDI2maxd)
\ : (EdiMode=="NNEDI2") ? clp.nnedi2(field=-2)
\ : (EdiMode=="Yadif") ? clp.Yadif(mode=1)
\ : dbob

[aegisofrime]

I had a glimpse at it back in the past ... frankly, I found the scripting style / script flow a bit unintuitive for me, so I let it be. ;)
My thoughts currently circle rather around TGMC (20-40% faster, perhaps make it 'lossless', ... )
And every day, the paper is crying for me, too ... (see sig.)

This was posted in another thread, but I thought it will be better to ask this question here.

I'm curious as to what you have in store for TGMC. It's a script that I use on a daily basis, so any speedup will be awesome! Also, JoshyD is porting quite a fair number of filters to 64-bit. Will 64-bit versions of TGMC's dependencies speed it up?

[Didée]

Can't tell you nothing about how things might be in 64bit land, so my answer to that is "perhaps". ;)

The mentioned speedup is simply achieved by replacing some of the generic MaskTools filters with faster counterparts. E.g. mt_luts(median) is a nice general tool, but rather slow. In the context of TGMC, it can be replaced with the much faster VerticalCleaner() by Kassandro. Another one (albeit smaller) is mt_inflate/deflate, the effect of which can be achieved faster by removegrain+mt_logic.

The improvement varies depending on which settings are used, of course. (I.e. when the inherently-slow NNEDI2 or EEDI2 is used, the improvement is much smaller, compared to using the pretty fast Yadif or plain-bicubic interpolators.)

Some rough speed numbers I got on the Core-2 machine were these:

TGMC(2,2,1,EdiMode="NNEDI2") : approx. +16%
TGMC(1,1,1,EdiMode="NNEDI2") : approx. +21%
TGMC(1,1,0,EdiMode="bicubic") : approx. +40%


I'll post the adapted script later today. Stockholm convinced me that the defaults also should be notched a little ... I'm not a too big fan of truemotion defaults, but the truemotion=false defaults are a bit too loose, either. lambda=400,pnew=25 seems more stable.

[aegisofrime]

Thanks for the reply! I'm sure many others using TGMC will be appreciative of the upcoming speedup :D

BTW, your ultrafast setting:


tempgaussmc_beta1u(1,1,0,0,0,0,edimode="--",SVthin=0.0,pelsearch=1)

Gives me 40fps on DVD resolution content without too much of a quality hit (In fact, it was nearly imperceptible, at least to my eyes.) I'm eager to see if I can get realtime with the upcoming speedup!

[Didée]

Alas, but no. Those settings are completely deactivating everything that is suspected to be sped up. In/Deflate is used in the safety-repair section, which here is completely switched of (the 2nd triple: "0,0,0"). And SVthin=0.0 also does deactivate that feature - and if it's not used, then it can't benefit from a faster median. ;)

[aegisofrime]

Oh I see. Well, hopefully with the speedup, a higher quality setting will give me the same speed as the ultrafast setting. :D

I have always been using TGMC(2,1,1,EdiMode="NNEDI2"), and that gives me about 10 fps. A bit ridiculous especially for 2 hours long DVD footage, but that's the price I have to pay for quality I guess!

One disadvantage of the ultrafast setting was that the encoded file is bigger than the "TGMC(2,2,1,EdiMode="NNEDI2")" one, but that's normal behavior right?

[Didée]

Sorry for I didn't post the mentioned update yet. I started with fiddling a "lossless" mode into TGMC (i.e. a mode that leaves the original fields untouched), and don't want to post a flood of new revisions every few days.
The inherent problem is the same old one ... you can easily get some residual combing, and measures to completely avoid this issue are very likely to also harm good detail, and/or to lose some of the temporal stability. Compromises of some sort have to be made.

The current implementation was made-up rather quickly. Visually, there is only little difference to TGMC-beta1. When things start to look very similar, numbers become more interesting, and so I made a quick test with MSU's measuring tool, compairing the bob-deinterlaced 576i Streams with the 576p50 reference.

Using the Stockholm sequence:
YadifMod(NNEDI2) : avg.PSNR = 34.779

TGMC(1,1,1,bicubic) : avg.PSNR = 36.135 (beta1u)

TGMC(1,1,1,bicubic) : avg.PSNR = 41.489 (beta2: "lossless")

It's only a "snapshot test", but it seems there is potential. ;)

[Revgen]

^Sounds like this "lossless" version can be used appropriately with functions like Srestore since it leaves the original fields unchanged.

Even if it misses some fields, I'm sure a quick vinverse() afterwards won't hurt much.

I'll be waiting to see it released.

[Didée]

Can't tell yet how it'll work with fieldblended footage, that's quite another game to play. For the moment I evaluate only with normal video-interlacing footage.
The code is knotty, but it's fun to finally see in "scientific" numbers what the eye has seen for a long time already. The current TGMC, even tough it gets "respectable" numbers in PSNR/SSIM tests, gets pretty much underrated by those. No wonder, because in the trade for stability it changes 100% of the frame. Other deint's may flicker and whatnot, but they have 50% of the frame correct to start with. And PSNR/SSIM don't care at all about temporal relations, while in the case of bobbing this is one of the most important factors! (Have told this already like ~10 years before when I came to digital video as a newbie ... everybody was so keen on PSNR back then, I told about the missing but important temporal relation, and of course nobody listened ...)

In any case, it's fun to see bobbers X-Y-Z doing ellbow-fighting in [the midrange of] 30db land, while TGMC happily roams in [the lower half of] 40db land, mostly.

I've one or two more things to try, and then the big knot in the script must be cleaned.

[Terka]

Hi Didee,
1. looking forward what the mastercook will serve us.
2. tried the 'noise bypass' technique using 2 mdegrains (both on bobbed=progressive clip)
where "limit" was different. so the most filickering parts
got away. (mostly horizontal lines). after that classical tgmc can be used. know that this is slow (2mdegrain), think that mvtools could be quite simply changed limit-> limitMIN, limitMAX so 1mdegrain will be needed

[tritical]

The results of TGMC are impressive, but it has to be stated (probably has been) that if there was ever a clip born to show the advantage of mc'd deinterlace it is that stockholm sequence :). Very high level of sharp detail, very slow stable pan (pure translation, just fast enough that motion-adaptation is useless) with no complicated motion to confuse mc.

[Didée]

Quite true, the Stockholm sequence is a dream of a perfect showcase example. However, the most important feature is that the dis/advantages are perfectly visible on this sequence. But the basic characteristics are pretty much the same on most other sequences, too. There's so many different things that can be tested. E.g. even when you have a source that has been very strongly lowpassed before interlacing (flicker reduction), so that the bobflicker is so much reduced that it's hardly visible anymore - if two bobbers look "almost the same" on such a source, but one bobber requires 25%~50% more bitrate on mpeg-compression compared to the other, what does that mean? :)
Also, at the very end of the Stockholm sequence the camera is still. Just a very few small objects are moving very slowly. Not much to do for MC there ... yet the new TGMC is still 1.5~2.0 db PSNR ahead over YadifMod(NNEDI2).
Another funny test is to simply knock out all original fields in a final comparison (since they're the same unchanged fields anyway), and compare only the interpolated fields to the respective reference. Guarantees for some funny numbers. (Or in the same spirit: bob-deinterlace, make a fresh interlaced source from only the interpolated fields, then bob-deinterlace *that*. Seriously, try that with a plain Yadif! Horror result!)

[Didée]

OK, another little test. A relaxed scenario, to not get accused of using "extreme" or "cherry-picked" sources that no filter except TGMC could ever handle. :rolleyes:

Contestants: TGMC-b2 lossless, tdeint(nnedi2), Yadif, YadifMod(nnedi2)

Source is ParkRun2 720p50, downsized to 576p for faster comparison.

The progressive source has been lowpassed before interlacing, to make things easier for the contestants. (So don't say the ultra-sharpness from not-lowpass'ing is the cause for the results.)

The snip is from the end of the sequence, frames 400-450. There is almost no motion in that snip, the camera is almost still. The overall scene shows minor subpixel-movement in the first half, the 2nd half is perfectly still. There is some slow motion in the water waves, though.
(So don't say it's the perfect horizontal translation which causes the results.)

Used Avisynth script:
RawSource("720p50_parkrun_ter.yuv",1280,720,"I420").assumetff()

spline16resize(720,576) # make 576p

blur(0,1).sharpen(0,0.75) # lowpass before interlacing

crop(40,0,-40,-0,true) # better preview on 1280-wide displays...

p = last # safe progressive reference

i = separatefields().selectevery(4,0,3).weave() # interlace

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

nnedi = i.NNEDI2(field=-2)

td = i.tdeint(mode=1,edeint=nnedi) # try a bobber
yad = i.Yadif(mode=1) # try another bobber
ydm = i.YadifMod(mode=1,edeint=nnedi) # and yet another bobber
tgmc = i.tempgaussmc_beta2(lossless=3) # and this one, too


comp1 = compare(yad, p)
comp2 = compare(ydm, p)
comp3 = compare(td, p)
comp4 = compare(tgmc,p)

stackhorizontal(comp1,comp2)
# stackhorizontal(comp3,comp4)
# comp1
# comp2
# comp3
# comp4

trim(400,450)


PSNR Results:


Yadif: starts with ~38.5db, ends with ~40.0db. oPSNR = 38.94

YadifMod: starts with ~39.5db, ends with ~41.0db. oPSNR = 39.68

tdeint: starts with ~36.0db, ends with ~41.8db. oPSNR = 37.44

TGMC-b2: starts with ~44.8db, ends with ~44.9db. oPSNR = 44.86


Video Sequences with PSNR measurements: LINK (http://www.mediafire.com/file/vuzojejhi2l/PSNR.rar) (Mediafire, ~16MB)


Let me repeat this isn't a cherry-picked example. That PSNR difference really is typical. I found only few cases where the difference is less, and quite a few where the difference is even bigger.



Temporal stability results:

(Encode to Xvid, q2, no Bframes, "flat-8" matrix. A practical way to watch out for switch-swatch bob shimmer.)

size % of TGMC % of ref

576p reference: 8760 kb (124%) 100%

TGMC-b2: 7023 kb 100% 80%

Yadif: 11148 kb 159% 127%

YadifMod: 10530 kb 150% 120%

tdeint: 10123 kb 144% 116%


Conclusion:
Compared to TGMC, all contestants have a noticably lower quality. (PSNR surely isn't the holy grail - but hey, a difference of 4~8 db is a darn lot, isn't it?)
Compared to TGMC, all contestants are remarkably less compressible. So in a realworld scenario, you start with a lower-quality source to begin with, and then would even need to compress it more strongly to achieve any given filesize, thereby reducing the quality even more.

Makes me wonder ... people happily use slow, slower and evenslower x264 settings to improve 2 percent here, another percent there. But when it's about vastly improved frame quality at vastly reduced birate, then no, thanks, it is too slow. Let's rather use the poor Yadif to quickly turn the source into a psychedelic something, then compress with insane x264 settings to no avail. Strange world.

[tritical]

The interesting thing to me is that in your second test the psnr difference between tdeint+nnedi2 is 37.4 vs 44.8 (7.4) and yet I can hardly tell the difference just watching the sample with the two side by side (maybe I have bad eyes and a crappy monitor). Whereas with the stockholm sequence the psnr difference is 34.7 vs 41.4 (6.7) and the difference is night and day. Actually, it doesn't surprise me since I have seen the same thing developing nnedi2 using squared error to train. Sometimes large psnr gains translate to almost zero visible improvement, whereas sometimes small gains translate to very visible differences (i'm talking gains over cilps containing frames from 50-60 sources). The hvs is very sensitive to differences in certain areas (clear defined structure) more than others ("busy" but somewhat random areas, like the trees and grass in that second sequence). Actually, if you have the time I'd be interested in the psnr numbers for nnedi2() alone and nnedi2 with qual=3 if it isn't too slow. :thanks: (maybe tdeint(mthreshL=-1,mthreshC=-1) also for just cubic interpolation with original fields preserved for kicks). Plus I am in no way trying to say that yadif is going to beat tgmc except for a rare clip or two, in fact I know its and tdeint's horrible scores on psnr tests well.

[Dogway]

Im having a problem setting qual=3 in tempgauss:

tempgaussmc_beta1u(2,2,3,EdiMode="NNEDI2",qual=3)

The encoding crashes at second pass. Its strange because qual=2 works nice, and qual=3 works nice on yadifmod. Do I have to call it as a variable? Do I have a wrong version? How do I know the version I have?

EDIT: Also when you say TGMC, is it the another version, or you just changed the function name?

[aegisofrime]

Great comparison videos there Didee. As far as I'm concerned TGMC has no competitors. Back when I was starting out in video editing, I tried a few trial versions of some commercial deinterlacing plugins for After Effects. None of them worked as well as TGMC.

Also, JoshyD seemed to have gotten TGMC running in 64-bit mode and is reporting significant speed differences. Should be interesting :cool:

Alright, I think I've got that temporal soften bug squashed, test it and let me know if there are any issues

I have TempGaussMC running . . . I'm showing some significant speed differences, anyone care to try there hand at it? I've got a four core machine, and telling AviSynth to use ~8 threads seems to be the sweet spot for processor utilization for me.

[Boulder]

Is the recommended way to deinterlace with TGMC (keeping the original frame rate) to simply use SelectEven or SelectOdd afterwards? Has anyone tested how it fares against other deinterlacers or is it expected that the results are very similar to Didée's tests?

[Didée]

tritical - will do those nnedi2 PSNR's, too. In fact, I definetly would be apt to do a more extensive comparison test, like you did (http://bengal.missouri.edu/~kes25c/deinterlace_comparison.txt) in the past. But you know it's quite an effort to do ... and the fact that my PC is from the beginning of this century doesn't exactly help. Would take me like half a year, and so I probably won't.

The results of PSNR often don't correlate well with HVS, that's oh so true. But that's known for long, and I don't feel like explaining the what-it-means, what-it-means-not, what-it-can-mean, and what-is-it-all-about every time such (mini-)tests are posted. People should know by now that PSNR does tell something, but is to be taken with a BIG grain of salt, and has to be interpreted in context. If they still don't know, so be it.


Dogway - no idea about the qual=3 issue with NNEDI2. Perhaps tritical has. "TGMC" of course is just a shorthand for quicker typing, and for using less space by subtitling. The new version still noone has, except me. ;)


aegisofrime - I'm far from being concerned with 64bit world (well, perhaps later this year, who knows...), but in any case, it seems JoshyD is doing a monster job there! Someone order him free beer for the rest of the year!


Boulder - yes, selecteven/odd is the only way to get samerate. It doesn't even create additional overhead. If "samerate" would be integrated as a feature into TGMC, it would be done in the very same way. The motion engine has to work with all fields anyway, so there's not really much chance to take any sort of "shortcuts" to achieve same-rate deinterlacing. SelectEven/Odd is fine.

Regarding the to-be-expected testing scores of same-rate deinterlacing: The PSNR scores will stay pretty much the same. PSNR/SSIM metrics work only spatially, so it doesn't matter all too much whether all frames are evaluated, or only every other frame. The actual numbers will change only little, the overall figures stay the same.

The "temporal stability", related to "compressibility", is another story. When bobbing, the major part of additional bitrate (compared to TGMC) comes from the flip-flop effect, which causes relatively big changes from one frame to the next. When doing same-rate, the effect is much smaller: the result no more goes flip-flop-flip-flop-.., but either flip-flip-flip,.. , or flop-flop-flop-... i.e. the switching-effect between frames is (mostly) not present anymore. That's much easier to encode.


In numbers:
With the settings given above, Yadif needed 50% more bitrate than TGMC. When doing same-rate, it needed 15% more bitrate. That's much less of a difference, but it's still not trivial. Also, see it in combination with visual quality, as follows.

In moving pictures:
"Shields" sequence, lowpass was done before interlacing, then doing same-rate deinterlacing.
(The shields sequence is nice because it features horizontal translation, static parts, and zoom-motion at the end. Zoom is a tricky situation.)

Sample: Yadif vs. TGMC.selecteven (http://www.mediafire.com/file/enw3mzzngwm/shields_samerate_Yadif-TGMC.avi) (~36MB, sorry it got a little big)

Look close, then tell me why Yadif is so "widely recommended" ... to me, it is visually much worse than any PSNR or compress numbers would ever suggest.

[Dogway]

XD I was about to ask what version was that too.

Actually something had to be on cache on tests because now not even qual=2 works after rebooting, ah, and it crashes just starting first pass. Strangely Avsp shows preview perfectly, can even framforward.
I narrowed my script so the error must be somewhere in there, I post it for if someone can lend a hand.

global MeGUI_darx = 257
global MeGUI_dary = 200

setmemorymax(768)
SetMTmode(5)
Loadplugin("C:\Windows\system32\MT.dll")

SetMTmode(2)
DGDecode_MPEG2Source("D:\MyLovely.d2v")
ColorMatrix(dest=2,hints=false,interlaced=true)

tempgaussmc_beta1u(2,2,3,EdiMode="NNEDI2",qual=3)
SRestore(FRate=23.976)
Dup(threshold=9,blend=false,copy=true,chroma=false,blksize=8,show=false)

trim(12281,22105)

[Boulder]

First of all, move the SetMTMode(2) line after the MPEG2Source. I'm also unsure whether SRestore works properly when multithreaded, weren't global variables a no-no?

[Didée]

tritical, here the PSNR results for NNEDI2 with qual=1|3, for non-adaptive tdeint with kernel interpolation, and for good old BOB(). Testbed setup was the same.

Filter settings:
- NNEDI2(field=-2,qual=1)
- NNEDI2(field=-2,qual=3)
- tdeint(mode=1,mthreshL=-1,mthreshC=-1)
- bob(0,0.5)


Quick numbers: (overall PSNR)

Parkrun2:
--------
NNEDI2(1) 33.10
NNEDI2(3) 33.29
tdeint 33.81
bob 33.45

Shields:
-------
NNEDI2(1) 38.47
NNEDI2(3) 38.62
tdeint 38.10
bob 37.96

Stockholm:
---------
NNEDI2(1) 39.15
NNEDI2(3) 39.26
tdeint 40.19
bob 38.63


Result screens: CLICKME (http://www.mediafire.com/file/mwndxmqzez2/PSNR%20results.rar)


Lesson learned: on my rusty 1core, running 2 times NNEDI2 in parallel is about the same speed as running TGMC. :D

[Didée]

I'm getting tired of it, so throw it out in the wild ...


TempGaussMC, version beta-2 (http://www.mediafire.com/file/ykyg5ymmzyw/TempGaussMC_beta2.rar).


Hope I've ruled out all mistakes, but you never know. If you find something, do speak.


What's changed:

- additionally requires VerticalCleaner.dll (http://home.arcor.de/kassandro/prerelease/VerticalCleaner.rar) by kassandro!! (->Info (http://videoprocessing.11.forumer.com/viewtopic.php?p=651))

- speedup by replacing slow-ish generic filters with faster alternatives. Depending on settings, 15% ~ 40% faster. Affected are several repair modes (tr0,tr1,tr2 parameters), and SVthin operation. When those are deactivated, there is no speedup either.

- introduced new "lossless" parameter:
-- lossless=-1 deactivates (default, same behaviour as has been)
-- lossless=0 is a dumb weave of original/TGMC fields. (Not for using! Just for demonstrating why it can't be done that easily.)
-- lossless=1 is a dumb weave with simple spatial correction.
-- lossless=2|3 use temporal compensation, followed by spatial correction. 2 is faster, 3 is calmer.

- optional "edeint" (clip) parameter. Works as known from tdeint and YadifMod. Useful e.g. when comparing several bob filters that all want to use NNEDI2 interpolation. May also safe from unnecessary script hacking when tritical comes up with NNEDI53 and EEDI427.

- adjusted some MAnalyse defaults:
-- "search" default is now "4" (was "2")
-- shifted the not-truemotion defaults for params "lambda"+"pnew" a little towards truemotion values.


Another side-effect of the "lossless" modes is that it makes the inherent noise-reduction of TGMC much weaker. That's no surprise: if the original fields stay really original, then they keep their noise, too.

[poisondeathray]

Thanks Didee!

I'm getting an error: Invalid arguments to "pointresize" , line 147

which corresponds to this in the .avsi downloaded from the link above


edi = default(edeint.pointresize(ox,oy, 0,-4,-0,oy+.001 ), edi)

[Stephen R. Savage]

@poisondeathray: You can just comment it out. It occurs because edeint was not set, resulting in it having the "void" type when PointResize expects the "clip" type for its first argument. Perhaps this is a 2.5.6 vs 2.5.8 thing.

Alternatively, I think the following works (why -4?):


edi = defined(edeint) ? edeint.pointresize(ox,oy, 0,-4,-0,oy+.001 ) : edi


I find that the new version is mostly similar to the original, but some of the characteristic ghosting artifacts of TGMC on cartoons are greater in this version.

[Didée]

Yes. I'm an idiot. Lately I checked only if edeint can be used - but forgot to check if it can be not used. That, and a misunderstanding-in-detail of the script parser.

Link updated, please get the new one.

[poisondeathray]

Thanks, it works fine now

[Didée]

(why -4?)
Because the script blindly assumes that the optional "border" parameter is set to default, and never set to false by the user. If done so nonetheless, I imagine funny results.

Stupidness corrected. This gave me also time to switch chroma-repair on again, which was completely switched off.

The link is updated again, I am an idiot, you download once more.

[Dogway]

Nice for sharing, it helped me spot the error on my little test script. Now it even doesnt preview on avsp, the conflict was with the dup filter. I can either yadif+dup, or tgmc+nodup. Anyways it looks like a buggy filter... any alternative?

[poisondeathray]

Nice for sharing, it helped me spot the error on my little test script. Now it even doesnt preview on avsp, the conflict was with the dup filter. I can either yadif+dup, or tgmc+nodup. Anyways it looks like a buggy filter... any alternative?

Something similiar happened to me on 1 computer but not the other.... I finally found out the PC that didn't work does not have SSE3 instruction set, so I removed VerticalCleanerSSE3.dll and it worked fine after that; I don't know if this will help you

[WorBry]

Thanks for the 'official' beta2 update Didee :)

Played around about a bit with the lossless modes. Cant see myself using them, at least with my home DV sources - prefer "no residual combing", even if that is at the expense of a little more blur.

One thought though. For denoising interlaced material, I normally bob (with YadifMod-NNEDI2), denoise with MDegrain and reinterlace, based on the understanding that denoising on bob-deinterlaced frames is preferable to denoising on separated fields. Since TGMC_beta2, in lossless modes, now preserves (i.e does not distort) the original fields, do you see it offering any particular benefit purely for denoising interlaced material, or would I be better sticking to my existing method, maybe adding some repair and contra-sharpening to the denoised output before reinterlacing (like TemporalDegrain)?

[Terka]

Didee
Thank you for next version!

WorBry
Please post some samples where you get combing. (DV source)

[Dogway]

(...)didn't work does not have SSE3 instruction set, so I removed VerticalCleanerSSE3.dll and it worked fine after that(...)

Yes it worked! Thanks for that, although my cpu has SSE3, its a core 2 duo...

Anyway I think that only fixes my last problem, Im gonna run some more tests.

EDIT2: OK the error was here:

tempgaussmc_beta2(2,2,3,EdiMode="NNEDI2")
SRestore(FRate=23.976)

It seems I cant decimate from 59.94fps

[Didée]

WorBry -
the denoising question is a bit too complex to elaborate in detail now. Generally/technically, I assume that TGMC in lossless mode should fair better. Since it's more stable on temporal axis, the motionsearch of the actual denoising should find better matches, resp. matches with a lower SAD. In result, there simply should be more denoising taking place. If that's a visual benefit in the end, or if it's not, that can't be said beforehand. Case specific, Settings specific, personal-taste-specific. ;)


Terka & WorBry -
When using the lossles mode, the result is really prone to contain some residual combing. The temporal correction corrects mostly the temporal stability (try lossless=0 to see how much that shimmers again), but helps only little against combing artifacts. And the spatial correction catches some, but not all combing. In short, the spatial anticomb just looks for any interlaced clusters being at least 3 pixels in height (via the Frame-VerticalMedian>Field-VerticalMedian/Repair combo). It's the "easiest" method I found to catch as much as possible, in little time, with as little harm to good detail as possible. But the method necessarily will miss combing that doesn't meet the 3-pixel-height criteria. Such may be found e.g. on thin moving objects, or around diagonally (or near-horizontal) oriented edges.
I don't expect the lossless mode to be "perfect" in any way. It was just done to (optionally) make TGMC a "clinic" bobber. Users might insist on that lossless-ness - either because they really need it, or because they *think* they *would* need it (where in fact they don't;) ). It was just when i had the idea of temporal re-correction, of course I had to try it. And since it turned out quite usable, here it is now.

And lastly, it is a way to make TGMC shine not only visually, but also in those overrated metric tests. The lossy TGMC doesn't fair too badly in those tests (always competitive, oftentimes winner), but it definetly gets underrated for the reasons mentioned earlier. Its PSNR results simply do not justify its potential visual quality. Now, with the lossless mode, the scores are much better, even if the naked eye can not see much of a difference.

Example result for Stockholm - old beta1 on the left, new beta2 to the right:
http://thumbnails24.imagebam.com/7012/f6ed3770112247.gif (http://www.imagebam.com/image/f6ed3770112247)

No matter the result looks almost the same visually - An increase of yet another +4.8 db PSNR makes a good figure when put into some random comparative table. ;)

[Terka]

Didee,
the beta2 looks promising. (Speaking about visual, the PSNR is not important for me.)
the artifacts are present, but ist mostly ok.
plase have a look at some questions below:
have one clip where it is a bit unpleasent - skiing video,
poles of a skier - some ghosting and/or stairsteping
http://rapidshare.com/files/357446100/ski.avi
how could the default setting be tuned?
im still testing.
(on dogs clip the lossless is nice.)

[WorBry]

WorBry
Please post some samples where you get combing. (DV source)

Do I really need to? Seems little point in illustrating what Didee acknowledges is inevitable.

My interest was rather in the potential benefits of TGMC_beta2's lossless modes for denoising interlaced material......

WorBry -
the denoising question is a bit too complex to elaborate in detail now. Generally/technically, I assume that TGMC in lossless mode should fair better. Since it's more stable on temporal axis, the motionsearch of the actual denoising should find better matches, resp. matches with a lower SAD. In result, there simply should be more denoising taking place. If that's a visual benefit in the end, or if it's not, that can't be said beforehand. Case specific, Settings specific, personal-taste-specific. ;)


Thanks for the reply. I'll do some more tests to satisfy my curiosity on that.

[Terka]

its up to you if you post something. im dealing with dv also and wanted to know which artefacts are you getting.
btw. you store some recordings interlaced? which codec? DVD/mpg2?

[WorBry]

Well, yes I keep all of my edited native DV footage on tape and HDD. I dont generally archive interlaced material after post-processing and transcoding, save keeping a copy of the "heavily-edited" DVD that I produce for other family members. For personal viewing (on PC) I still prefer to bob-deinterlace (TGMC or MCBob) and transcode to x264. In that case I do also archive a copy of the 50p lossless intermediate (usually FFDShow-HuffYuV YV12). However, every now and then I revisit and play around with interlaced (MBAFF) x264 encoding; since I dont yet possess a standalone Blu-ray/AVCHD player, it's just that for now.

[2Bdecided]

I'm a big fan of TGMC, so I'm a bit disappointed that the newest version doesn't offer me anything useful for my HDV footage.*

My favourite version is still alpha3.
beta1 is genuinely sharper but with more artefacts (subtle "almost-combing", and letting more actual MPEG-2 artefacts through).
beta2 is maybe slightly worse by default, and worse still in lossless modes. I realise it gets nice PSNR numbers, but would the lossless modes really help where people think they would?

I'll try and post a test clip to show why I still like alpha3.

Cheers,
David.

*EDIT - I'm not complaining!!!! - I sounded really ungrateful, but I'm not! I'm just suggesting that maybe other test clips might be helpful during development.

[Didée]

Terka - cant say much to the skier clip at the moment, but I'll have a look into it. Worth trying: blocksize 8, different rep0/1/2 settings, MVTools params further toward "truemotion", or perhaps further away from "truemotion" ... last ressort, exhaustive search with all SAD penalties turned down :eek:. (Just dont know which is the main culprit in this case, sorry.)

2Bdecided - a sample showing the issue / regression would be nice.


The next step for a possible improvement most probably reads "MRecalculate", but then things will get slower, necessarily. Though, I'm a bit discouraged ... some time ago I had made a quick trial in that direction, and the result was different from what I had expected. Don't know if my thoughts were wrong, or if I didn't use MRecalculate corectly, or if MRecalculate doesn't do what I suppose it to do ...

[Revgen]

This appears to be my favorite (albeit very slow) replacement for yadif when used with srestore. As you said before, lossless lets in more interlacing than non-lossless (mostly on thin angled objects like stair rails) even at lossless=3, but most of what it allows in can be cleaned up for the most part using vinverse() afterwards without destroying much detail.

[nicmar]

I've got exactly the same problem on the lossless with the diagonals of my skiing video (with lossless=0,1,2) .
But it's ok with lossless=-1.

It's good with this script :
_______________________________________________________
LoadPlugin("c:\divx\avisynth\RepairSSE3.dll")
LoadPlugin("c:\divx\avisynth\RemoveGrainSSE3.dll")
LoadPlugin("c:\divx\avisynth\VerticalCleanerSSE3.dll")
LoadPlugin("c:\divx\avisynth\nnedi2.dll")
LoadPlugin("c:\divx\avisynth\mt_masktools-26.dll")
LoadPlugin("c:\divx\avisynth\masktools.dll")
LoadPlugin("c:\divx\avisynth\mvtools2.dll")

import("c:\divx\avs\TempGaussMC_beta2.avsi")
import("c:\divx\avs\LimitedSharpenFaster.avsi")
avisource("ski.avi")
assumetff()
crop(14,4,-12,-12)
# More details ???
TempGaussMC_beta2(1,1,1,1,1,1,"NNEDI2",qual=3)
# Less details ???
#TempGaussMC_beta2(2,2,1,1,1,1,"NNEDI2",qual=3)
selecteven()
BlackmanResize(720,576)
_______________________________________________________

Didée : Thanks for the work and this nice reflexion !

[Terka]

if i correctly understand the behaviour of mvdegrain
lets have clp,searchclip (done by temporalsoften).
where mvtools search fails, ghosting is visible.
so the visible ghosting are the searchclip pixels?

from Temporal Degrain comments:
# Currently, Temporal Degrain works by creating a "clean" clip that has no noise.
# This clean clip is used for MV search, and will generally give more accurate vectors
# than an unfiltered clip would. However, our current implementation uses heavy filtering
# from FFT3DFilter. The prefiltered clip looks like mush, and our first stage of denoising
# cannot exhibit denoising greater than this. Because of this, the limit on denoising
# is essentially nothing! In some cases, the denoising is much more severe because our
# "clean" sometimes replaces the results from vanilla MDegrain, giving a very flat and
# undetailed look the image. We can alleviate this by creating a secondary "limit" clip
# that isn't as severely filtered as our search clip is. But, this would cost even more time.

if yes, how the limit clip could be done?
if yes, could it be possible to replace the failed places with clp instead searchclip using mvtools parameter (implement new param. to mvtools?)

[Terka]

Didee, once you mention the (not available) inverse vectors.
eg. v=(2,3) ->v_inverse =(-2,-3)
have you tried to get them by reordering the stream with selectevery? eg. selectevery(2,0,1,0)

[Didée]

Swapping frames is not the same as reversing a vector.

_____


Don't give too much on that TDegrain explanation. Wordsmiths might debate whether the description is wrong, or just "a bit misleading". The prefiltering stage is independent from the actual filtering stage. It is not so that the result of the prefiltering would be used anywhere for the output. If the prefiltering did a small change in one place, and the actual filtering did a big change in the same place, then the actual filtering will be limited. But not the other way round: If the prefiltering did a big change in one place (too big, producing "mush"), and the actual filtering did only a small change, then the smaller change is used. No mush is used for the output. It is used whichever filter did cause the lesser change, i.e. that one that did less harm. Of course, there might be cases where the strong prefiltering caused MAnalyse to find a bad vector, which subsequently will harm the actual filtering. But then, a "wrong vector" is a pretty much different thing than "mushy prefilter is replacing the result of vanilla MDegrain." ;)

Also, all this is only for TemporalDegrain. In TGMC, limiting the actual filter by the prefilter's result is *not* done. But in TGMC, too, the various prefiltering may cause a worsened result of motionsearch in some spots. However, I suspect it's not so much the temporal prefiltering (which usually is safeguarded by the "rep" options, anyway). Probably more critical is the flattening of signal amplitude, which is done in a separate step. It has been noted before: this flattening is pretty much necessary to get the whole thing working at all. Without it, MDegrain would not work in those places where it's needed at most....

And that's the point where MRecalculate should come into play: do the motionsearch after the temporal prefilter (which is needed), but without the signal flattening. Only after the vectors have been searched, use MRecalculate to update all block-SADs in respect to the flattened signal.

That is the idea, and I consider it reasonable. But as said, a quick tryout didn't work as expected. Wrong thinking? Wrong scripting? Buggy MRecalculate? I don't know yet.

[2Bdecided]

2Bdecided - a sample showing the issue / regression would be nice.Two demuxed m2v samples here:

http://www.mediafire.com/?sharekey=605ee2b5f85656f5e62ea590dc5e5dbb31f572f6d5454f27a9a26c4ed87536eb

The images in there are field (bobbed frame) number 146 of test clip 2. I've found that's quite representative of my outdoor footage.

(clip 1 has some silly fine detail in the background (little holes on the large pipe) - no expectation this will come good, but it's a nice test case.)

What I see in clip two compared with alpha3 are little bits of false fine detail getting through (alongside some real extra fine detail).

Last time I mentioned this, you suggested settings for beta1 which made it similar to alpha3 - which 80% worked.

FWIW I rarely use TGMC for hours of HD(!) - occasionally I leave a PC running for a week to process a few minutes footage with TGMC that I need to zoom+crop. More often I use TGMC to grab a single frame for a photo.

Cheers,
David.

[Didée]

Thanks for sharing, I'll have a look. (Somehow ... HD is really nothing you would process with my PC)

By now, I remember that I also did a slight modification in the searchclip preparation from alpha3 to beta1. It's a tricky field, in the same way as the general setting or tweaking of MVTools' parameters. There never is a "better" or a "worse". It's only ever "you win here, you lose here". When saving waving hands, I lose Stockholm. When saving Stockholm, I lose waving hands. (SAD concept is fixed-absolute, not relative to amount of local energy.)

[Didée]

@ 2Bdecided: Didn't do very much testing, it's just no fun with my hardware.

Though, it seems the few non-adjustable changes from alpha3->betaX are not the point. It's really only the different defaults. There is virtually nothing that alpha3 could do that beta1/2 could not. The progress was evolutive, not eliminative.


EEDI2 <-> NNEDI/NNEDI2
alpha3 used the old NNEDI. beta1 used EEDI2 because faster than old NNEDI. Nowadays we have MT'ed NNEDI2. Use that.

blocksize=8 <-> blocksize=16
Of course, "8" can catch tricky motion better than "16". It's a speed compromise. You can set it back to "8".

repair: "hardcoded" alpha3 vs. default 4,0,4 in beta1/2
The hardcoded repair of alpha3 was more strict than beta's defaults. Use "1,0,1" in beta2 to get old behaviour (mostly).

Sharp-limiting:
alpha3 had hardcoded spatial limiting. beta has temporal limiting per default.
Set "SLmode=1, SLrad=2" to get old behaviour back.

(This is a "matter-of-principle". Spatial limiting is of course much more failsafe: MVTools has not a "sliding" thSAD limit for MCompensate, as it has for MDegrain. MCompensate is only "hard limited". Therefore MCompensate can produce rather bad blocks in difficult areas, and that's indeed dangerous for the limiting process. (Manually caring for this problem is possible, but unpleasingly slow.)
OTOH, spatial limiting is basically a poor strategy - it works out only when the source is sufficiently soft. In the theoretical hardcore case of a very sharp progressive original that has been interlaced without any lowpass, the temporal mode basically works correctly, but the spatial mode fails blataneously.)


Yet again, there is no "right" or "wrong". There's only different sources, and different preferences.


Okay then, what happens with those settings adjusted?


(2,2,1,1,0,1,edimode="NNEDI2",SLmode=1,SLrad=2,blocksize=8)
(mostly like alpha3 did)
http://thumbnails10.imagebam.com/7042/e68a8070410786.gif (http://www.imagebam.com/image/e68a8070410786)

(2,2,1,1,0,1,edimode="NNEDI2",SLmode=1,SLrad=2,blocksize=8,lossless=1)
(same, plus the simple lossless=1 mode)
http://thumbnails28.imagebam.com/7042/e01eac70410789.gif (http://www.imagebam.com/image/e01eac70410789)


Can't judge if that is exactly an "80%" approximation of alpha3's result. ;)

But if so, then it can be argued if the other 20% are to alpha3's advantage -- or perhaps to alpha3's disadvantage? I'd say the adjusted settings avoid almost all of the artifacts, and beta2 still shows more detail.

[aegisofrime]

I wonder what are we supposed to see in those comparison images? Or maybe that was the point, we are not supposed to see anything different? :D

In any case, I think in the context of video (moving images), you will have to be looking very hard to see differences. In my opinion, the important factor is speed then.

[Didée]

You've (also) to compare with the screens posted by 2Bdecided. Between the different filters and versions, the main differences are e.g. the boy's hand (with or without artifacts), the diagonal pole of the baby buggy (with or without artifacts), the texture of the girl's clothing (more or less detail, with or without distortions), ...

[2Bdecided]

Very much appreciated Didée - those settings are spot on!

Compared with alpha3 default, there's a little more genuine detail coming through, and a little more artefacts from the original encoding coming through - and (AFAICT) no increase in deinterlacing artefacts (if anything, there might be a slight decrease in deinterlacing artefacts - though there weren't many to start with). For this footage, to my eyes, this gives a nicer result than the default settings.

(The artefacts from the original encoding look worse with a simple dumb bob, so no real harm done there by tgmc. It's not a great worry anyway as it'll probably get even worse when subsequently encoded for anything).

Cheers,
David.

[WorBry]

FWIW - With my DV sources at least, I find that reducing the sbb value (default = 1.0), and sometimes inactivating it (sbb=0), can help to minimize those "subtle almost combing-like artifacts", that you referred to.

[danielkun]

I've only recently started using TGMC, and I like it a lot! On interlaced video is my first choice, and the denoiser saves me doing MCTD (which I find complex and can't get the most out of it, requires too much knowledge of the filters it uses)

Also, I like TGMC's denoising much better than MCTD's, I tried the latter's low, medium settings with some lower sigma values (it's too blurry otherwise) but it somehow fails a bit on edges (or is it that H264 accentuates some error in those edges)

The way TGMC denoises is just what I want since not only raises PSNR more, but it looks better as well, the image looks cleaner and with less "grain" around edges. Great work Didée :)

Anyway, as said, TGMC is my preferred choice for interlaced content, but it leaves to problem with telecined one. I've no experience with motion compensation or any other advanced filtering, so I'd like some help in this matter. I'd like something like:

1) Use TGMC along TMM or something, but it wasn't designed to denoise progressive content, so is this adviceable?

or

2) Tweak MCTD in order to closely ressemble TGMC's denoising.

I hope someone can enlighten me in this matter :thanks:

[Boulder]

For telecined sources, you have to do inverse telecine, not deinterlacing. Tritical's TIVTC plugin contains all you need (functions TFM and TIVTC).

[Didée]

There's a problematic clip pending - and the news are not good ...

have one clip where it is a bit unpleasent - skiing video,
poles of a skier - some ghosting and/or stairsteping
http://rapidshare.com/files/357446100/ski.avi
how could the default setting be tuned?

To make a long story short: if you want an example where TGMC works not good, here you have it !!

In this clip, it is simply so that the combination of following factors:

a) "thin" image features (little image area that MVtools can snatch onto),

b) those thin features being on almost texture-less background (vector predictors in MAnalyse don't give useful predictions),

c) the shaky hand camera

These three factors cause "situations" in which the initial gauss-denoising produces something that does more harm than it helps. And even the safety-repair (tr0) can't fully prevent the misery.


The closest approach (while keeping the general tempgauss-principle) is to just use more stringuent repair-options, together with only small temporal radii, like
TGMC(1,1,1,1,1,1, ...)

That's a little better, but "good" is something else. In this case here, it seems really necessary to completely de-activate the initial tempgauss:
TGMC(0,1,1,0,1,1, ...)

Now, deactivating the initial tempgauss kind of defeats the whole principle that TGMC stands for. But in this case, it seems it's the only way to prevent TGMC falling apart into pieces. :mad:

[danielkun]

For telecined sources, you have to do inverse telecine, not deinterlacing. Tritical's TIVTC plugin contains all you need (functions TFM and TIVTC).

Indeed, I use TIVTC with MCTD for telecined content but I'm not satisfied with the results, sorry I wasn't clear about it.

I just want to know if there's a way to use TGMC's denoising with decimate or tweak MCTD to match TGMC's denoising (since I like it so much)

[Didée]

Of course it is possible to use the general processing chain of TGMC also for progressive content. Basically, all that's needed is to deactivate the internal bobbing. Just lately someone has asked for a progressive-TGMC (though in a different context, for postprocessing after MFlowFPS) ... short of putting one more switch into the function, see here (http://forum.gleitz.info/showthread.php?p=404392#post404392) for the necessary changes, it's really not difficult. (If you don't speak German - the changes are in red.) :D

It's not 100% optimal this way, since a few things in TGMC assume that the vertical resolution is blurred much more than the horizontal resolution. Perhaps Smode=1 is better than the default Smode=2 in ths case, and probably you'd want to reduce SVthin, or even set it to 0.0. Also, it might be good to put Vinverse between IVTC and TGMC ... like

TFM().TDecimate()
Vinverse()
TGMC_b2(Smode=1,SVthin=0.49) # script modified as shown!!

It's all theory, I didn't try this myself yet.

[Terka]

Didee, ok. extrem case.
are you still working on the mrecalculate idea or is it no-go?

[Didée]

Neither-nor. It's not a no-go, (and/but) I'm currently not working on it. :)

[2Bdecided]

To make a long story short: if you want an example where TGMC works not good, here you have it !!This one is pretty atrocious too... ;)

http://www.mediafire.com/?ghxzmw4yrny

(not my clip - probably downloaded from doom9 somewhere - apparently on 2009-10-06).

That background is too sharp IMO and would flicker horribly on an interlaced display. Never-the-less, it confuses the heck out of TGMC.

Using TGMC as the edeint in Yadifmod helps (not enough IMO!), but as a general approach I think that would cause more problems than it solves.

Cheers,
David.

[Didée]

Oh, *that* clip. Yes I remember, I once had downloaded it, too.

Using TGMC as the edeint in Yadifmod helps (not enough IMO!), but as a general approach I think that would cause more problems than it solves. Well, to me, using TGMC as an edeint for YadifMod is not an option, as a matter of principle. ;)

The clip is difficult, but not impossible. The very fine hi-contrast detail is irritating most sorts of spatial filtering. As you'll see in the sample below, every deinterlacer is fighting with that issue. In TGMC it's (again) the repair-part. Set all repair's to zero, and the result changes noticeably. (Didn't I mention something similar, back when that clip was under discussion?)

Test script:
(Sorry for the funny cropping/bordering, wanted to fit 6 screens into a 1280x960 display)

AviSource("F:\Downloads\sample_interlaced_LAGS.avi") .assumetff()
converttoyv12(interlaced=true)
crop(32,0,-264,-0,true)
o=last

bobb = o.bob(0,0.5)
yad1 = o.yadif(mode=1)
yad2 = o.yadifmod(mode=1,edeint=o.nnedi2(field=-2))
td1 = o.tdeint(mode=1)
td2 = o.tdeint(mode=1,edeint=o.nnedi2(field=-2))
tgmc = o.tempgaussmc_beta2(1,1,1,0,0,0,"NNEDI2",blocksize=8,sharpness=4.0,SVthin=2.0)


vv=blankclip(bobb,width=4,height=bobb.height,color=$808080)

stackvertical(
\ stackhorizontal( bobb.subtitle("bob(0,0.5)"), vv,
\ yad1.subtitle("Yadif"), vv,
\ td1 .subtitle("tdeint")
\ ).crop(0,2,0,0).addborders(0,0,0,4,color=$808080),
\ stackhorizontal( tgmc.subtitle("TGMC"), vv,
\ yad2.subtitle("YadifMod*NNEDI2"),vv,
\ td2 .subtitle("tdeint+NNEDI2")
\ ).crop(0,2,0,0)
\ )

return(last)

Result: >Linky (http://www.mediafire.com/file/tte0jrhdizm/ChooseYourPoison-Deint.avi)< (Mediafire, ~67MB)

I don't claim there is a "winner". *) -- But there's one out of the six that appears "the least annoying" to me. ;)

*) In particular since TGMC was tweaked, but tdeint was just at its defaults ... though, I doubt you could tweak tdeint to a similar obvious improvement. ;-)

[osgZach]

Just wanted to say, thanks for all the work on TempGauss. It is giving really great results so far, that I can tell.. I'm much more content to wait a couple hours versus spending those hours messing with various IVTC combing problems (either getting through, or ending up with too much deinterlacing on good frames) and so forth.

In particular it is really good for title sequences, and brings the credits text through as pretty as I have ever seen.

Kind of a random question. Currently I'm using TempGaussMC_beta2().SelectEven() to keep the footage at 29.97fps - Although I was wondering (here comes the n00biness) can you use SelectEven() (or an equivalent to end up with a half-frame rate clip) and then use TempGaussMC, or does it really require both fields present, to form the output from? If you could do that, would it increase speed without sacrificing quality?

[osgZach]

No, that makes plenty of sense Stephen, it was just a curiousity on my part. I couldn't really tested it as I am bogged down waiting on an encode to finish at the moment, so figured I'd take a stab in the dark and ask.

[2Bdecided]

wow - can people delete posts without leaving a trace? That can make for some strange looking conversations (see above!).

Cheers,
David.

[WorBry]

@Didee,

You might recall earlier in this thread that we had some dialogue about the potential application of TGMC for anti-aliasing progressive material, and, as a case in point, pseudo-progressive (frame mode) DV footage from my Panasonic GS400 camcorder, which is highly prone to irregular aliasing:

http://forum.doom9.org/showthread.php?p=1144403#post1144403

(I cringe to look at it now )

Well, after much tinkering with altered temporal gauss blur strengths and the like, I eventually came to the startling realization that the bulk of the anti-aliasing effect could be attributed to substitution of the bobbed EDI stream for one in which the complementary (duplicate) interpolated frames are merged ('Double Edi'), viz:

edidbl=mt_average(nnedi(field=0),nnedi(field=1),U=3,V=3)

Also I found that the temporal gauss treatment itself tended to introduce conspicuous warping/undulation of lines/edges.

Even so, in terms of 'straight' denoising of the ‘Double-Edi’ with MDegrain, there does appear to be some benefit (stability-wise) in creating a search clip (for motion vectors) using the ‘trick’ (weighed-in mini spatial gauss blur) that you employ in TGMC_beta1/2 to reduce local contrast.

So, what I’ve arrived at is this, using NNEDI2 for the `Double-Edì, and a simple contrasharpen-repair routine (cringes again):

AVISource("C:\........Pseudoprogressive DV.avi")
Tweak(coring=true)
clp=last
#Create Double-Edi clip:
edidbl=mt_average(clp.nnedi2(field=0, qual=1),clp.nnedi2(field=1, qual=1),U=3,V=3)
#Prepare search clip for motion vectors - apply spatial (mini) gaussian blur to reduce local contrast (from TGMC_beta1/2):
spre=mt_lutxy(clp,clp,"x 3 + y < x 3 + x 3 - y > x 3 - y ? ?",U=3,V=3) # ?? REDUNDANT NO-OP
ox=clp.width()
oy=clp.height()
sclp=clp.removegrain(11).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=2).merge(clp,0.1).mt_lutxy(spre,"x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?",U=3,V=3)
# Get motion vectors from search clp:
sclp_super=sclp.MSuper(pel=2, sharp=2, levels=1)
edidbl_super=edidbl.MSuper(pel=2, sharp=2, levels=1)
backward_vec2 = MAnalyse(sclp_super, isb = true, delta = 2, truemotion=false, blksize=8, overlap=4, search=2, global=true)
backward_vec1 = MAnalyse(sclp_super, isb = true, delta = 1, truemotion=false, blksize=8, overlap=4, search=2, global=true)
forward_vec1 = MAnalyse(sclp_super, isb = false, delta = 1, truemotion=false, blksize=8, overlap=4, search=2, global=true)
forward_vec2 = MAnalyse(sclp_super, isb = false, delta = 2, truemotion=false, blksize=8, overlap=4, search=2, global=true)
# MDegrain denoise:
mdg=edidbl.MDegrain2(edidbl_super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=256, thSCD1=180, thSCD2=98)
#mdg=edidbl.MDegrain1(edidbl_super, backward_vec1,forward_vec1, thSAD=256, thSCD1=180, thSCD2=98)
#Repair-contrasharpening:
allD = mt_makediff(edidbl,mdg) #The difference achieved by the denoising.
ssD = mt_makediff(mdg,mdg.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.
mgdADD = mdg.mt_adddiff(ssDD,U=2,V=2) # Apply the limited difference - contrasharpen
Return(mgdADD)

Any chance you could look over it - specifically the search clip segment (red highlight), which I adapted from TGMC_beta1/2. I realize that the ‘spre’ line (as applied, without the first stage temp gauss treatment) becomes an effective no-op, but I am not sure how to modify the ‘sclp’ line without it .....should I just delete the

mt_lutxy(spre,"x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?",U=3,V=3)

I`ll put up a sample clip shortly, the old links are long dead.

Edit: Here's a short clip which exhibits some of the worst forms of aliasing I am dealing with. It's in FFDShow HuffYuv-YV12 format (Pal 720x576 anamorphic); unfortunately, I cant readily locate the original DV source footage:

http://www.mediafire.com/file/ewiwmznyzyz/Frame%20Mode%20Progressive%20Sample%20HuffYuv-YV12.avi

Note, in this sample, the above script does leave a little aliasing (some residual hatching on the white wall baseboard) but that's about as good as I've been able to acheive without blurring the heck out of everything.

Edit2: Changed the NNEDI2 qual value from 3 to 1 (highest quality)

[danielkun]

Of course it is possible to use the general processing chain of TGMC also for progressive content. Basically, all that's needed is to deactivate the internal bobbing. Just lately someone has asked for a progressive-TGMC (though in a different context, for postprocessing after MFlowFPS) ... short of putting one more switch into the function, see here (http://forum.gleitz.info/showthread.php?p=404392#post404392) for the necessary changes, it's really not difficult. (If you don't speak German - the changes are in red.) :D

It's not 100% optimal this way, since a few things in TGMC assume that the vertical resolution is blurred much more than the horizontal resolution. Perhaps Smode=1 is better than the default Smode=2 in ths case, and probably you'd want to reduce SVthin, or even set it to 0.0. Also, it might be good to put Vinverse between IVTC and TGMC ... like

TFM().TDecimate()
Vinverse()
TGMC_b2(Smode=1,SVthin=0.49) # script modified as shown!!

It's all theory, I didn't try this myself yet.

Danke Didée
I'll look into this and try your different suggestions. :)

[osgZach]

wow - can people delete posts without leaving a trace? That can make for some strange looking conversations (see above!).

Cheers,
David.

Yes.. Although some forums can be set up to not allow the user to delete their posts after a certain amount of time has passed.. I'm pretty sure I have posted on boards like that before.. If so, I would think a hack / mod of some sort would be available for VBulletin.

[2Bdecided]

Whether people should be allowed to delete posts is one thing - but on most forums it says "deleted by user" in place of the missing post.

Cheers,
David.

[henryho_hk]

I suggest case-insensitive comparison on the EDIMODE parameter. It is now rather tricky ("NNEDI" vs "nnedi2").

[Didée]

I suggest case-insensitive comparison on the EDIMODE parameter. It is now rather tricky ("NNEDI" vs "nnedi2").
I fully agree that this is bad style. The excuse is that Avisynth's parser accepts it.
(And the 2nd excuse is that the lowercase string was not added by me - that was done by third-party scripter/s.);)

It's definetly not clean, but ... laziness has learned that the parser does not care for upper/lowercase when checking identity: it evaluates "big"=="BIG" = TRUE. Has been like that for over a decade.

Is someone about to change the parser's behaviour?

Also, there's lots of bad style that frequently is used in Avisynth ... A similar case:

a = [some float]
b = [some int]

result = a * b

In a clean programming style, such mixing of var types should not be done. Strict parsers/compilers would complain. Wanna urge some billion instances in some thousands of Avisynth scripts that do an INT*FLOAT multiply?

[WorBry]

@Didee,

Any thoughts about my last post above ?:o

Hope it wasn't too dumb; if complete nonsense, just let me know.

Cheers.

[henryho_hk]

No.

While the parameter name is case insensitive, the parameter value (avisynth's string compare) is case sensitive. "NNEDI2" has the same result as "Blah".

[Gavino]

... the parameter value (avisynth's string compare) is case sensitive.
No, it isn't. Case is ignored in all string comparisons.

[Didée]

@ henryho_hk - what do you get with this little script?
check = ("BIG"=="big") ? "size doesnt matter!" : "size DOES matter!"

version().subtitle(check,align=2)



@ WorBry - only one small issue: don't put "levels=1" in the sclip_super line. Don't you get "MAnalyse: it is not enough levels in super clip (1), while MAnalyse asks [n]" ... ? - The searchclip should have all levels available.

The rest of the script seems OK to me. Same as your conclusion about AA strategy - in this case, there is not much AA to get from temporal processing. Spatial interpolation is the most-promising approach, and averaging two EDI's (top/bottom) is a good way.

Also, Also I found that the temporal gauss treatment itself tended to introduce conspicuous warping/undulation of lines/edges. is not surprising. When applying TGMC to progressive input, there's a problem because the number of different motion states in forward- and backward-direction are different. This un-balance can mislead the motion engine.

[WorBry]

OK, thanks for the advice :)

My only frustration with the 'double-Edi' approach is the line thickening, but I guess that's a better trade-off than other detail-destroying blur AA techniques, and thankfully NNEDI2 is a great improvement over its predecessors in this respect.

[Revgen]

Small question.

Does the "edeint=" parameter override the "EDIMode=" parameter?

[Didée]

Small answer: Yes. "Edeint" has priority over "EdiMode". (Assumption: if the user takes the effort of producing a bobbed clip and feeding it into TGMC, then it's probably not by accident.)

[Revgen]

^Thanks. That's the way it works in TDeint, so I just wanted to be sure.

[Terka]

Didee,
regarding the clips where the VCrep function cant catch the mvtools errors:
1.what about build the repair function based on mmask?
2.comparsion of vectors from 2 vectors search is not possible in mvtools for now.
(mean use your recalculate idea and apply it where the 1st search vec. differ from 2nd vectors search by more than threshold.
this means where 2nd search is 'more' different from 1st one, use 2nd. because usually they should be +-pixel the same.)

[Didée]

1.what about build the repair function based on mmask?
That's the Chicken-vs-Egg problem, once again. The issue takes place in stage1. No motion data is available at that point. After the motion data has been computed in stage2 (based on the possibly-erroneous result of stage1), it is not reliable to catch errors of stage1.


where 2nd search is 'more' different from 1st one, use 2nd. because usually they should be +-pixel the same.)
I.e., making some sort of self-validation. That's not a bad idea in general. Basically, it even is a rather nice idea. Be surprised or not, pretty much that is what I have tried already. Precisely, years back when I was fiddling with MCBob ... and as much as I like the principle, I didn't get the method to work out.

[Terka]

1. mean like this:
# IF rep2=true: Allow only bob-typical vertical differences
stage2 = (rep2!=0) ? stage2.VCRep(edi,ed=ed2,od=od2) : stage2

but do this on seachclip. so the 'final' searchclip will be done from
2 searchclips, classical tg and not preprocessed.


2.
why you didnt?

[translucent]

First off, thanks to Didée for such a useful script. Just had to point out this (seemly longstanding) bug:
# cheap halo-reduction for sharp pel modes (for Lmode=2|4)
cx1=comp_fw1.width()
cx3=comp_fw3.width()
cy1=comp_fw1.height()
cy3=comp_fw3.width() #!?!?

[henryho_hk]

Is it a bug or a feature? lol

[Terka]

Didee,
remember the grass problem with the dogs clip?
(For the ones who dont know the clip:
realatively static clip, handheld camera. People on grass filmed from 10m. On the static grass after tempgauss appeared large up/down moving areas.)
this helped:
searchclip=searchclip.HQdn3D(4,3,6,3)
its line before
# Get motion vectors

(the idea was stolen from TemporalDegrain)
tested on tr2=1 where most visible.

Could please other tgmc users test this tweak? Thank you, Terka.

[Didée]

That's also a "you win here, you loose there" game. It'll work out in quasi-static areas. But if you have, for example, a panning shot where the top half of the frame shows a cloudy sky, then it is very likely to harm.

(In TemporalDegrain, the according "HQ" option better should be labelled "BF" ... because this trick is not "high quality", but rather "brute force".)

[Terka]

yes.
but if we know that:
we win in area X with wapon A
we win in area Y with wapon B
lets use proper weapons in proper areas
>we can make overlay of searchclip based on vector lenght.
(know that 2 searches are needed)

[Didée]

Hurdy-gurdy ...

When 1st search is done before the bruteforce-calming: MVTools may find long vectors where it should not ==> ain't work

When 1st search is done after the bruteforce-calming: MVTools may "static" vectors where in fact there is motion ==> ain't work

[loekverhees]

Some rough speed numbers I got on the Core-2 machine were these:

TGMC(2,2,1,EdiMode="NNEDI2") : approx. +16%
TGMC(1,1,1,EdiMode="NNEDI2") : approx. +21%
TGMC(1,1,0,EdiMode="bicubic") : approx. +40%


Beta2 is slower than beta1 for me. I used this code:

MPEG2Source("25i.d2v")
assumetff()
ConvertToYV12(interlaced=true)
tempgaussmc_beta1(EdiMode="nnedi2")
#tempgaussmc_beta2(EdiMode="nnedi2")


25i.d2v is a 314 frames video. With beta1 it takes 126 seconds and with beta2 it takes 133 seconds to export. I save as Huffyuv v2.1.1 in VirtualDub. How should I add multicore support in the code? Will that make it faster?

[LoRd_MuldeR]

I'm trying to use TempGaussMC_beta2() and my script is really minimalistic:

AVISource("TallShip_lag_YUY2_5.1.avi")
AssumeTFF()
TempGaussMC_beta2(edimode="eedi2")

However what I get is:
http://i41.tinypic.com/mj4i8n.png

And ideas on what is going wrong? Thanks in advance!

[poisondeathray]

I'm trying to use TempGaussMC_beta2() and my script is really minimalistic:

AVISource("TallShip_lag_YUY2_5.1.avi")
AssumeTFF()
TempGaussMC_beta2(edimode="eedi2")

However what I get is:
http://i41.tinypic.com/mj4i8n.png

And ideas on what is going wrong? Thanks in advance!


ConvertToYV12(interlaced=true)

[LoRd_MuldeR]

Stephen R. Savage and poisondeathray, thanks!

But now I have another problem: "RemoveGrain: invalid mode 20". Do I have a wrong version of RemoveGrain?

[Stephen R. Savage]

You probably need the "pre-release" version of RemoveGrain.

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

[LoRd_MuldeR]

You probably need the "pre-release" version of RemoveGrain.

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

That did the trick :)

[LoRd_MuldeR]

While everything seemed to work now, I had to notice that the resulting file only contains ~500 frames of content.

All the rests looks like this:
http://i43.tinypic.com/2qio7za.jpg

The scrip I used is:
AVISource("TallShip_lag_YUY2_5.1.avi", Audio=False)
AssumeTFF()
ConvertToYV12(interlaced=true)
TempGaussMC_beta2(edimode="eedi2")
Spline36Resize(1280,720)

Any ideas? Where should I start to search for the cause of problem? :o

[MatLz]

Any ideas? Where should I start to search for the cause of problem? :oHi my Lord, as I don't have the source and as tempgaussmc is too slow for my pc:(, the only advice I can give you is to remove ALL unnecessary plugins and functions in your Avisynth plugins folder. (Some dll like warpsharp, edeen...(even unused) are known to do things like that).

[Didée]

~Perhaps~ it's a plugin issue.

But first, what's that source like? Some "smallish" SD-PAL, or rather a 1080i HD beast? (-> could be out-of-memory issues ...)

[MatLz]

~Perhaps~ it's a plugin issue.

But first, what's that source like? Some "smallish" SD-PAL, or rather a 1080i HD beast? (-> could be out-of-memory issues ...)Seems it is a HD Beast....it is one of the sources used to make the first X264 bluray disc

[LoRd_MuldeR]

the only advice I can give you is to remove ALL unnecessary plugins and functions in your Avisynth plugins folder.

If it was that easy. TGMC uses almost any plugin that I'm aware of :D

~Perhaps~ it's a plugin issue.

Is there a specific one you would suspect to make trouble?

But first, what's that source like? Some "smallish" SD-PAL, or rather a 1080i HD beast? (-> could be out-of-memory issues ...)

It's the "Tallship" sequence, as used on the x264 demo BluRay disc. ~20.000 frames of "high-detail" 1080i footage:
http://forum.doom9.org/showpost.php?p=1394015&postcount=606

(The source is compressed lossless, with the "lagarith" Codec, using YUY2 colorspace)

[MatLz]

If it was that easy.Sometimes it is, sometimes it is.....but now I have a doubt...warpsharp or awarsharp?...I don't remember...

[Didée]

Sorry don't really have the time rightnow ... a quick way to see if it works with small sized source:

AVISource("TallShip_lag_YUY2_5.1.avi", Audio=False)
AssumeTFF()
crop(0,0,720,576)
ConvertToYV12(interlaced=true)
TempGaussMC_beta2(edimode="eedi2")
#Spline36Resize(1280,720)

Works, or works not?

If this works, it's RAM ressources.

If it works not, then it's probably a faulty plugin.

[LoRd_MuldeR]

Okay. I will check this when I'm back home...

[Reuf Toc]

It may also be an issue with lagarith decoder, I've already had problem with this codec (my two cents)

[Robert Martens]

Is there a specific one you would suspect to make trouble?

I can't speak for the particular error message you're receiving, but you may want to check that you don't have fauxD (http://forum.doom9.org/showthread.php?t=143855) installed while you're trying to run TempGauss.

Trying out a few test clips with my personal favorite TGMC settings, specifically using

AVISource("testclip.avi")
AssumeBFF()
ConvertToYV12(interlaced=true)
TempGaussMC_beta2(1,1,3,0,0,0,EdiMode="NNEDI2",sharpness=1.0,Smode=1,SLmode=0,Sbb=0,SVthin=0.0)

and going through VirtualDub to a YV12 Lagarith AVI nets me about five, maybe five and a half frames per second single threaded. SetMTmode(2,0) works wonders, and gets me closer to nine or ten fps.

That is, as long as fauxD isn't in my autoload directory. As soon as I install it, and configure fauxD.avsi to use the proper directories (for fauxD.dll and MVtools2.dll), the same script starts at barely more than one frame per second, multithreaded or not, and slowly drops to 0.3 and slower, if it even makes it that far; most of the time I get an MVTools exception after only a few hundred frames.

I tried getting rid of SEt's Avisynth 2.5.8 MT, and reinstalling the standard 2.5.8 release, but I got the same results. Just over five fps without fauxD, less than one with it.

[LoRd_MuldeR]

It may also be an issue with lagarith decoder, I've already had problem with this codec (my two cents)

I re-encoded from Lagarith to HuffYUV. Completed just fine. Will now use the HuffYUV file for future attempts...

[LoRd_MuldeR]

Sorry don't really have the time rightnow ... a quick way to see if it works with small sized source:

AVISource("TallShip_lag_YUY2_5.1.avi", Audio=False)
AssumeTFF()
crop(0,0,720,576)
ConvertToYV12(interlaced=true)
TempGaussMC_beta2(edimode="eedi2")
#Spline36Resize(1280,720)

Works, or works not?

Works not :(

But this time I got ~1700 frames before the "CAVIStreamSynth: System exception" starts...

Another thing I noticed:
If I open the AVS in VirtualDub and then exit VirtualDub, the window disappears, but I get a VirtualDub.exe hanging in the background with a constant CPU load of 25%.

Any more suggestions? :)

[LoRd_MuldeR]

Okay, I deleted all the DLL's and all the .avsi's from my Avisynth 2.5.8 directory. Ready for a fresh install!

Now the only things I have installed are:

TempGaussMC_beta2.avsi [version from here (http://forum.doom9.org/showpost.php?p=1378526&postcount=338)]
EEDI2.dll [06/07/2006 v0.9.2]
mt_masktools-25.dll [v2.0a40]
mvtools2.dll [v2.5.10]
RemoveGrainSSE2.dll [v1.0 "beta"]
RepairSSE2.dll [v1.0 "beta"]
VerticalCleanerSSE2.dll [version from here (http://home.arcor.de/kassandro/prerelease/VerticalCleaner.rar)]

Does that look right ???

EDIT: At least it seems the "hang" in VirtualDub is gone now. So I started yet another attempt, again at 720x576...

[MatLz]

Aren't the sse3 versions in the removegrain package now free of bugs?
You could try them if it is slow...

[LoRd_MuldeR]

Aren't the sse3 versions in the removegrain package now free of bugs?

I wanted to stay on the safe side this time. Even thought about using the "generic" versions :)

First I need to get it running stable. Then I can worry about speed. So far the SSE2 versions keep on running...

[Didée]

Alas I can't reproduce your scenario (yet), the possibilities on my 8-year-old Celeron /w 512MB RAM are quite limited. [Am building a shiny new rig currently, but it's not yet ready to burn.]

So, meanwhile, I try throwing ideas:

- What's your RAM usage when monitoring with taskmanager & Co, and how much RAM do you have at all?

- are you just rendering the script, or by any chance directly encoding with x264? (RC-lookahead most probably being the final ressource killer when feeding ressource-hungry Avisynth scripts...)

- Lagarith is multi-threaded, nay? Perhaps it's not the most failsafe codec option when instability is encountered ...


All I can say for sure is: with the limited complexity that my system allows, there is no such problem with TGMC. It may come down to a crawl when the ressource limits are used to the brim, but it'll always complete the job. Sidenote is I don't use Lagarith for intermediates, I always use ff-Huffy.

[LoRd_MuldeR]

- What's your RAM usage when monitoring with taskmanager & Co, and how much RAM do you have at all?

I got 4 GB of physical RAM + 8 GB of swap file. So if it's a memory issue, then it's the 2 GB per process limit. Global memory limit shouldn't be an issue ;)

- are you just rendering the script, or by any chance directly encoding with x264? (RC-lookahead most probably being the final ressource killer when feeding ressource-hungry Avisynth scripts...)

I'm encoding to ffvhuff. Using avs2avi.exe by Moitah + latest ffdshow. Also tried to do it with ffmpeg.exe earlier.

- Lagarith is multi-threaded, nay? Perhaps it's not the most failsafe codec option when instability is encountered ...

This was suggested before. So I have converted the source to HuffYUV already (size went up from 15 GB to 20 GB) and I will use the HuffYUV source for future attempts.

At the moment it's still running. Hopefully the re-install (http://forum.doom9.org/showpost.php?p=1395016&postcount=422) has fixed the issue. 10000 of 20000 frames completed already....

[LoRd_MuldeR]

Alright, I have good news. The 720x576 encode completed successfully. So it seems the clean-up and re-install really fixed it :)

It's too late to start the full resolution encode this evening. But I will start it tomorrow morning...

[LoRd_MuldeR]

Alright, I have good news. The 720x576 encode completed successfully. So it seems the clean-up and re-install really fixed it :)

It's too late to start the full resolution encode this evening. But I will start it tomorrow morning...

Okay, I have no successfully processed all 20116 frames at full 720p resolution with TempGaussMC :cool:

Conclusion: One of the plugins I had installed was broken. Not sure which one though. Maybe it even was some unfortunate combination...

[MatLz]

Well doneConclusion: One of the plugins I had installed was broken. Not sure which one though.as you have the VirtualDub issue, you could remove half of your plugins, see if it happens. if not, that means faulty plugin is in the half you removed....if it happens again that means the faulty plugin is still in the directory.....repeat the operation until you identify the guilty...

[LoRd_MuldeR]

Well doneas you have the VirtualDub issue, you could remove half of your plugins, see if it happens. if not, that means faulty plugin is in the half you removed....if it happens again that means the faulty plugin is still in the directory.....repeat the operation until you identify the guilty...

Well, now that it works (removing everything and only installing the Plugins I really need to get TMGC working fixed the issue for me) I don't want to change anything. You know, never change a running system (if you don't have to time to fix it afterwards). Maybe one day when I have more time, I will try to successively re-add the Plugins I had installed before and see with which one the trouble starts...

[MatLz]

That would take 5 minutes maximum....less if you are lucky....but I understand you are busy.

[LoRd_MuldeR]

It would certainly take much longer. I had about 20 plugins installed before.

And if I it cannot be tracked down to a single plugin, I would need to test for "bad" plugin combinations. Then the number of combinations to test becomes n^2.

So ~400 combinations to test, at least :(

[MatLz]

20plugins?
If it is only one which bug tgmc and its needed plugins, you just have to remove half of the others plugins at each try to isolate it.....2 min clock in the hand.
But yes, if it is a combination of 2 or more, you will need a little more attempts or luck.
Can you post your plugins list?

[Didée]

I had about 20 plugins installed before.
Well ... doing a quick DLL count, I have almost 150 Plugins "installed" - or better said "not installed", since I do NOT use auto-loading of plugins. Auto-loading is fast, easy, lazy, ... and in case of doubt, makes nothing but problems. ;)

[LoRd_MuldeR]

Can you post your plugins list?

I can... when I'm back home. Anyway, you have to take into account that when I did the re-install, I updated some plugins to the latest versions.

It might even be that an "old" plugin caused problems, but stopped doing so after the update. Reconstruction which version I had installed at which moment may be difficult ^^

Well ... doing a quick DLL count, I have almost 150 Plugins "installed" - or better said "not installed", since I do NOT use auto-loading of plugins. Auto-loading is fast, easy, lazy, ... and in case of doubt, makes nothing but problems.

That's right. From now on I won't keep any DLL in my "plugins" folder, except for those I use all the time :)

[Gavino]

20plugins?
If it is only one which bug tgmc and its needed plugins, you just have to remove half of the others plugins at each try to isolate it.....2 min clock in the hand.
Bear in mind that LoRd_MuldeR's problem only showed up after encoding a certain number of frames, so it's not a simple matter of loading the script and seeing if it fails.

It seems unlikely to me that an unused plugin could cause this sort of behaviour - after auto-loading, plugins are unloaded until needed. So I expect the most likely cause was an old version of some needed plugin which has now been replaced with a working one.

[MatLz]

Bear in mind that LoRd_MuldeR's problem only showed up after encoding a certain number of frames, so it's not a simple matter of loading the script and seeing if it fails.../...It seems unlikely to me that an unused plugin could cause this sort of behaviourHe also speak about a vdub issue which is directly seekable.../...that was my first suggestion

:D

[Terka]

Didee,
in principal, TGMC tgmc is some kind of 'superresolution'.
Its results are nice - because of different position of the lines in adjacent frames.
The upsize factor is (width,height) = (0,2)
Do you expect some WORTH quality (respective speed) improvements, if the upsize factor is bigger (respective lower)
As you remember, Ive tried factor 4 with BAD results.
Now i tried the factor 3 using fast ultradirty mod with border = false and changed code like
dbob = clp.nnedi2(field=-2).Spline36Resize(ox,oy)
edi=dbob
return( last.Spline36Resize(ox,oy*2/3)

on "psi" (dogs) clip the results are somewhere better, mostly for moving areas, didnt have the parkrun, where the factor 4 totally failed.

[Terranigma]

Updated Didée's TempGaussMC_Beta2 script to support nnedi3, and for the heck of it, I updated mcbob along with it (only a few parameters wording) which is included in the package.


You can download it here (http://www.zshare.net/download/761723983e5708ad/), and additionally tritical's nnedi3 filter can be downloaded here (http://forum.doom9.org/showthread.php?t=147695).

[Keiyakusha]

Any estimates how much slower TGMC with nnedi3 compared to nnedi2?

[LoRd_MuldeR]

Any estimates how much slower TGMC with nnedi3 compared to nnedi2?

Like 7 vs. 4 fps for me ;)

[Terka]

do you see any quality improvements using nnedi3 over nnedi2?
which speed improvements you see using new version of nnedi2?

[Terka]

do you see any quality improvements using nnedi3 over nnedi2?
which speed improvements you see using new version of nnedi2?

[txporter]

Like 7 vs. 4 fps for me ;)

Can I ask how you run your script? I think I have a pretty similar rig to you (Q6600, 4gb, Vista64) but I am seeing 2.2fps with nnedi3 (and nearly the same for nnedi2 actually).

Script that I am using is fairly basic:
setmtmode(5,0)
MPEG2Source("D:\Temp\test\PAL\test.d2v")
setmtmode(2)
TempGaussMC_beta2u(1,1,1,edimode="nnedi3",Smode=1,SLmode=1,Sbb=0,SVthin=0.0)
repal()
removegrain(1)

more info:
Avisynth 2.5.8 MT (set)
Using Repair/RemoveGrain.dll (not SSE2, was getting unknown function when using RepairSSE2.dll and RemoveGrainSSE2.dll -maybe wrong package?)
MVtools2 - 2.5.10

update:
wasn't using the pre-release version of RemoveGrain/Repair. SSE2 version works now. Will have to try on my Q6600 at home. Not noticeable difference on Duo Core laptop here between version.

update2:
Looks like I was using an older version of masktools-25 as well. a36, I think, instead of a43. Newer version is much faster on my laptop (~1.6fps to ~2.1fps). Hopefully will see a nice speed up on home machine as well. The lack of bob flicker is wonderful compared to the standard yadif bob, but I was hoping to shave SOME time off the ~8 hr conversion time for 1 Doctor Who episode...

[2Bdecided]

... I was hoping to shave SOME time off the ~8 hr conversion time for 1 Doctor Who episode...Doctor Who isn't interlaced! Not the 21st century ones anyway (except the title sequence).

1970s and 80s episodes are part interlaced, part film (progressive), like almost all UK TV from back then. Is that what you're dealing with? If so, you could maybe save a little time by not putting the film sequences through TGMC.

Cheers,
David.

[txporter]

Doctor Who isn't interlaced! Not the 21st century ones anyway (except the title sequence).

1970s and 80s episodes are part interlaced, part film (progressive), like almost all UK TV from back then. Is that what you're dealing with? If so, you could maybe save a little time by not putting the film sequences through TGMC.

Cheers,
David.

Hmm. Well....possibly. I have NTSC disks and was originally processing them with a yadif(mode=1, order=1).repal() script. Is there a way to do this with TIVTC instead of bobbing and repal'ing? I guess most of my work lately has been with a Torchwood clip, but I would assume that both Dr. Who (recent) and Torchwood are the same as far as progressive/interlaced, right? I was seeing bob flicker which was eliminated with TGMC, but maybe I simply induced that myself with yadif?

[2Bdecided]

Ah, I see. They're originally progressive 25p (PAL). Goodness knows what they've done to them converting them to NTSC! Could be anything, and could well be interlaced (so may include bob flickering). You're probably doing about as good a job as can be done with them - though having the UK 25p broadcasts or DVDs would make life far easier!

Both Torchwood (all series IIRC) and the latest series of Doctor Who (currently airing in the UK) are shot in HD. Try to find those if you can. (Hint: when broadcast, they're 25p. When they may it to BluRay, they may be nastily converted to 60i - even the UK releases).

Cheers,
David.

[daimroc]

I am trying to use TempGaussMC_beta2u, vbut when I open the avs in the virtualdubmod I get the followinf error: there is no exist the mt_makediff function.

In which plugin can I get this function?

EDIT: well, in the documentation of mvtoosl2 I see that it has the function, but I load the plugin in my avs and I get the same error.



Thanks.
Daimroc.

[LoRd_MuldeR]

I am trying to use TempGaussMC_beta2u, vbut when I open the avs in the virtualdubmod I get the followinf error: there is no exist the mt_makediff function.

In which plugin can I get this function?



Thanks.
Daimroc.

You need MaskTools v2 ;)

Download:
http://manao4.free.fr/masktools-v2.0a43.zip

More Info:
http://manao4.free.fr/mt_masktools.html

[daimroc]

I am load mvtools2 and masktools, but I get the same error. Also I am load nnedi3.



Thanks.
Daimroc.

[LoRd_MuldeR]

I am load mvtools2 and masktools, but I get the same error. Also I am load nnedi3.



Thanks.
Daimroc.

If it still complains about "mt_makediff" missing, then you obviously haven't installed the "MaskTools v2" plugin yet.

See download link in my previous post...

[daimroc]

Yesm I have all the plugins in the same folder than my avs, so I load the pluging in the following way:

#plugin para desentrelazados
LoadPlugin("nnedi3.dll")
LoadPlugin("mvtools2.dll")
LoadPlugin("MaskTools.dll")
import("TempGaussMC_beta2u.avsi")

is it needed an spacial instalation of the masTools2?



Thanks.
Daimroc

[LoRd_MuldeR]

s it needed an spacial instalation of the masTools2?

Nope. But the MaskTools v2 plugin should be called "mt_masktools-25.dll" or "mt_masktools-26.dll", depending on whether you use the Avisynth 2.5.x or 2.6.x version.

Also: In addition to the plugins you have already loaded, you'll also need RemoveGrain + Repair (http://home.arcor.de/kassandro/RemoveGrain/RemoveGrain.rar) and VerticalCleaner (http://home.arcor.de/kassandro/prerelease/VerticalCleaner.rar) in order to satisfy TempGaussMC_beta2 ;)

[daimroc]

Well, I am downloading MasTools 1.5.8, and in this zip I only have the MaskTools.dll. So I load MasTools.dll, not the specific dll for avisynth 2.5.x or 2.6.x. Really I need the specific dll?

Other problem is with Repair.dll and RemoveGrain.dll. When I try to load the plugin, I get the following error, unable to load RemoveGrain.dll. With the Reapir.dll I get the same error.



Thanks.
Daimroc.

[LoRd_MuldeR]

Well, I am downloading MasTools 1.5.8, and in this zip I only have the MaskTools.dll. So I load MasTools.dll, not the specific dll for avisynth 2.5.x or 2.6.x. Really I need the specific dll?

How often do I need to tell you that you need MaskTools v2 ??? :p

http://forum.doom9.org/showthread.php?p=1402172#post1402172

[daimroc]

When I try to load RemoveGrain.dll and Repair.dll I get the same error, that I can't load RemoveGrain.dll plugin or Repair.dll plugin.

I try with the stable v0.9 and the beta 1.0b. This is the correct version?




Thanks.
Daimroc.

[LoRd_MuldeR]

When I try to load RemoveGrain.dll and Repair.dll I get the same error, that I can't load RemoveGrain.dll plugin or Repair.dll plugin.

I try with the stable v0.9 and the beta 1.0b. This is the correct version?

I think you need the 1.0b version, as v0.9 doesn't support the required modes. And did you try loading "RemoveGrainS.dll" instead ???

[daimroc]

With RepairS.dll and RemoveGrainS.dll it works perfecly.

Finally I can open the video with this.

But I have a question, I see that it ueses a remove grain, so I guess that it is for remove grain. I would Like to know if there is a way to use this without removing grainm becouse I only a smooth deinterlacing.

My intention it's to have an deinterlaced video as closer to the original I can get.



Thanks.
Daimroc.

[LoRd_MuldeR]

With RepairS.dll and RemoveGrainS.dll it works perfecly.

Finally I can open the video with this.

But I have a question, I see that it ueses a remove grain, so I guess that it is for remove grain. I would Like to know if there is a way to use this without removing grainm becouse I only a smooth deinterlacing.

My intention it's to have an deinterlaced video as closer to the original I can get.

Thanks.
Daimroc.

As mentioned by Didée before, TempGaussMC is a denoise function - only optimized to remove deinterlace flicker. Therefore it gives the "stable" result.

Anyway, you can use something like "Noise Bypass" to avoid noise removing:

function TempGaussMC_WithNoiseBypass(clip Source)
{
Denoised = Source.FFT3DFilter(sigma=3, bt=3, interlaced=true)
NoiseOnly = mt_makediff(Source, Denoised, U=3, V=3)
TGMC = Denoised.TempGaussMC_beta2u(edimode="nnedi3")
return mt_adddiff(TGMC, NoiseOnly.DoubleWeave(), U=3, V=3)
}

SomeSource("C:\Some Folder\File.foo")
AssumeTFF()
TempGaussMC_WithNoiseBypass()

Also you could try the "lossless" mode of TempGaussMC_beta2, which keeps the original fields untouched...

[daimroc]

After trying TempGaussMC_beta2u, I see that the problem persist, so if you could say me where I could upload a sample, I can do it.



Thanks.
Daimroc.

[LoRd_MuldeR]

After trying TempGaussMC_beta2u, I see that the problem persist, so if you could say me where I could upload a sample, I can do it.

Thanks.
Daimroc.

Did you try putting either AssumeTFF() or AssumeBFF() before TempGaussMC_beta2u() ???

A good place for hosting files is MediaFire (http://www.mediafire.com/) ;)

[Forteen88]

Nope. But the MaskTools v2 plugin should be called "mt_masktools-25.dll" or "mt_masktools-26.dll", depending on whether you use the Avisynth 2.5.x or 2.6.x version.Hmm, I didn't know that :P What's the disadvantage of using "mt_masktools-26.dll" on Avisynth 2.5.8? It worked for me.

EDIT: Thanks for the answer Gavino.
EDIT2: I took a screenshot with mt_masktools-25.dll and one with mt_masktools-26.dll, and the frames were identical (binary).

[Gavino]

What's the disadvantage of using "mt_masktools-26.dll" on Avisynth 2.5.8? It worked for me.
You got lucky.
See this post.

[dansrfe]

I'm using the bet2u version with nnedi3, nns=3, and lossless=3 and I must say the output is nothing less than magical. I'm using all the SSE3 versions of the plugins but I'm not sure if they are better to use than the SSE2 versions since I've heard many stories in regards to the stability of SSE3. Also I'm curious to know how MCBobUv6 compares to TempGaussMC_beta2u. Thanks! :)

[Leinad4Mind]

Hi there, I have made an update. Use at your own risk :rolleyes:

[WorBry]

With all respect, I would suggest that you change the name of your name of your modification to TempGaussMC_beta2'Something-or-other'.
IMHO, TempGaussMC_beta'x' should be reserved for official updates by the author, Didee. Then there is a clear distinction between official versions and unofficial modifications thereof.....of which there are a number floating about. I'm sure he and others would agree.

[Leinad4Mind]

Yeah u're right... I have fix it. ^^ But personally I will continue using as 3. xD It's more simple to write -.-

[aegisofrime]

Hi there, I have made an update. Use at your own risk :rolleyes:

Can I ask what was changed? It's not immediately obvious.

[Leinad4Mind]

Fixed chroma shifting 'cause in "josey well" MVtools it's not fixed yet, AFAIK, and added a parameter to change rfilter method. It works for me. ^^

Best regards.

[me7]

Since this is still in beta state I was wondering whether it defaults to reasonable values yet. Can I just call "TempGaussMC_beta2()" in my script and get reasonable results, or are input parameters expected?

[Gser]

Hi there, I have made an update. Use at your own risk :rolleyes:

It would have been nice of you to retain the original appereance of the avs, now its a pain in the rear end to read. And perhaps the letter z is not the best choice if someone else wants to add to it as "z" is the last English letter. Try "w".

Since this is still in beta state I was wondering whether it defaults to reasonable values yet. Can I just call "TempGaussMC_beta2()" in my script and get reasonable results, or are input parameters expected?

Look at the script and see what the parameters mean. Then decide if you want to change them. The explanations are quite clear.

[dcrht]

Does anyone know how to deinterlace this one? I can't determine its field order.
http://www.mediafire.com/?mgujn1njrno

[Revgen]

^Looks like a video/telecine hybrid. I'd suggest using TIVTC with Hint=true and experiment with different hybrid modes in tdecimate.

[txporter]

I was replying to a thread over on Videohelp and started doing some testing with TGMC with various settings to determine speed impact. I have the results summarized over on Videohelp (http://forum.videohelp.com/threads/320950-1080-60i-to-720p-%28for-AVCHD-Disk%29-and-480i-%28For-DVD%29?p=1994508&viewfull=1#post1994508) if anyone is interested. I didn't record the final bitrate (which I should have) and didn't look at each of the videos to determine quality. I did look at the default settings and the minimum settings tdeint (#5), as well as a few others. The shimmer that I was trying to get rid of was addressed to my satisfaction with all the ones that I looked at. Obviously, different sources and personal preference will determine what you can live with.

Quick summary here:
1080i PBS HD broadcast of Story of India
converting with x264 (r1602) @ default preset (not x264 limited)
avs file:
setmtmode(5,0)
MPEG2Source("Path\To\Story.of.India.E1-clip.d2v",cpu=3)
setmtmode(2)
lanczosresize(1280, height)
TempGaussMC_beta2(1,1,0,0,0,0,edimode="tdeint",Smode=1,SLmode=1,Sbb=1,SVthin=0.0,pelsearch=1)
srestore(frate=25)
lanczosresize(width, 720)
removegrain(1)

*modified my version of TGMC to use tdeint because 64bit yadif wasn't available at the time

Results table attached.

[txporter]

Ok, I am trying to find an easy way to determine the relative amount of flicker for various deinterlace methods. I saw the example floating around some time ago for the Stockholm sequence (4 horizontally stacked videos). That shows it very well for that sequence since it has only panning motion. On a more normal case (TV show/movie), the flickering isn't always so obvious. I have been playing around with overlay and subtract a bit. If I take a clip that I convert with TGMC (baseline settings) and then subtract another clip that I converted with tdeint or yadif, is it the flashing/strobing luma that is referred to as bob shimmer? If so, that method seems to highlight effect well. Just trying to make sure that I am not misleading myself.

I am hoping to use this method to 'detune' TGMC and compare to a default clip to verify that I haven't lost the de-flickering ability in TGMC.

[txporter]

Ok, did another pass at TGMC fps by settings. This time a little more systemically and without extra filters in avisynth to skew the results.

Most of these tests were run on a Q6600, 4gb RAM, Vista64 using Avisynth64 and x264_r1629_x64. The results for EEDI2, NNEDI and nnedi2 were run on my dual core laptop using Avisynth32 (2.5.8MT) and x264. For some reason the EEDI2 pass on my desktop crashed half way through, so I don't have those results and NNEDI and nnedi2 have not been compiled for 64bit. I re-ran run#6 (defaults with bicubic) and used the fps from that run to interpolate the fps for EEDI2, NNEDI and nnedi2 at dual core speeds. Based on fps results from the halfway point of the 64bit EEDI2 run, it looks like the fps could be ~3% slower on the 32bit system.

At any rate, my avs file was simple as was my x264 command line (speed would be a little faster without the ssim/psnr calls):
setmtmode(5,0)
MPEG2Source("video1.d2v")
setmtmode(2)
TempGaussMC_beta2(2,2,1,4,0,4,edimode="EEDI2",Smode=2,SLmode=2,Sbb=1,SVthin=1.0,pelsearch=2)
x264 --crf 18 --ssim --psnr -o video.mp4 video.avs 2>video.log

TGMC settings were changed as per the following table.
http://img704.imageshack.us/img704/1517/tgmcsettingsfps.jpg (http://img704.imageshack.us/i/tgmcsettingsfps.jpg/)

I have included the fps results from x264 and used the default settings to baseline the change in speed. I have included the resultant bitrate so you can get a feel for compressability and also included x264 ssim and psnr results (for what they are worth). I have also included what I am going to be using as my "default" TGMC settings (run19) for converting NTSC DVDs of PAL video.

Mediainfo on file (NTSC DVD Torchwood clip):
General
Complete name : D:\Temp\test\PAL\TGMC_speed_tests\encode\video.mpg
Format : MPEG-PS
File size : 117 MiB
Duration : 2mn 0s
Overall bit rate : 8 210 Kbps

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Default
Duration : 2mn 0s
Bit rate mode : Variable
Bit rate : 7 436 Kbps
Nominal bit rate : 9 800 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Standard : NTSC
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.718
Stream size : 106 MiB (91%)

Audio
ID : 128 (0x80)
Format : AC-3
Format/Info : Audio Coding 3
Duration : 2mn 0s
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Surround: L R, LFE
Sampling rate : 48.0 KHz
Stream size : 6.41 MiB (5%)

[Terka]

when someone is dealing with small 'unstable areas' (which you could see after using TGMC) you can try following:
put the green code between the bold original TGMC`s code.
functions GlobalMOCO and LUTDeCrawl are needed. I changed the LUTDeCrawl a litte by adding a global motion compensation line to it.
http://www.aquilinestudios.org/scripts/LUTDeCrawl-20081003.avsi
the masking part is stolen from idontknow whos script.
# apply sharpness limiting (SLmode 3|4), or has "draft" been requested?
stage3 = (draft==2) ? t .subtitle("Draft 2")
\ : (draft==1) ? t1 .subtitle("Draft 1")
\ : (SLmode==3) ? ( (SLrad<2) ? stage2.repair(edi,1) : stage2.repair(stage2.repair(edi,12),1) )
\ : (SLmode==4) ? stage2.mt_clamp(pmax,pmin,Sovs,Sovs,U=3,V=3)
\ : stage2

#LUtdecrawl
ythresh=25
cthresh=50
maxdiff=206
GrassDontDance=stage3.LUTDeCrawlGlobalMOCO(ythresh=ythresh,cthresh=cthresh,maxdiff=maxdiff)

#mask the static, use LUtdecrawl on static only
maskp1 = stage3.MMask(fvec1, kind=1, ysc=255).UtoY()
maskp2 = stage3.MMask(fvec2, kind=1).UtoY()
maskp3 = stage3.MMask(bvec1, kind=1, ysc=255).UtoY()
maskp4 = stage3.MMask(bvec2, kind=1).UtoY()
maskf = average(maskp1, 0.25, maskp2, 0.25, maskp3, 0.25, maskp4, 0.25).spline36resize(stage3.width, stage3.height)
stage3=Overlay (GrassDontDance,stage3, mask=maskf)




# "Lossless" stage
#==================

function GlobalMOCO (clip clp, int "prev", int "next", int "subpixel", bool "matchfields", float "pixaspect", bool "info")
{
#input has to be ConvertToYV12()
#
prev = default( prev , 0 )
next = default( next , 1 )
subpixel = default( subpixel , 2 ) #quality of matching 0-2
matchfields = default( matchfields, True ) # xxx todo
pixaspect = default( pixaspect , 1.094 ) #PAL
info = default( info , false ) #PAL

# procedure ##############
mdata = DePanEstimate (clp) #motion data
depa = DePanInterleave(clp, data=mdata, matchfields =matchfields,prev=prev, next=next,pixaspect=pixaspect,subpixel=subpixel,info=info)
return (depa)
}
function LUTDeCrawlGlobalMOCO(clip input, int "ythresh", int "cthresh", int "maxdiff",
\ int "scnchg", bool "usemaxdiff", bool "mask") {

Assert(input.IsYV12(),"LUTDeCrawl: YV12 input only")

cthresh=default(cthresh,15)
ythresh=default(ythresh,10)
cthr=string(cthresh)
ythr=string(ythresh)
scnchg=default(scnchg,25)
sc=string(scnchg)
maxdiff=default(maxdiff,50)
md=string(maxdiff)
usemaxdiff=default(usemaxdiff,true)
org=input

tri=org.GlobalMOCO(1,1)
org_minus=org.Trim(0,-1)+org.Trim(0,org.framecount-1)
org_plus=org.Trim(1,0)+org.Trim(org.framecount,0)

org_minus=tri.selectevery(3,0)
org_plus=tri.selectevery(3,2)


org_y=org.Greyscale()
org_minus_y=org_minus.Greyscale()
org_minus_u=UToY(org_minus)
org_minus_v=VToY(org_minus)
org_plus_y=org_plus.Greyscale()
org_plus_u=UToY(org_plus)
org_plus_v=VToY(org_plus)

average_u=mt_lutxy(org_minus_u,org_plus_u,"x y - abs "+cthr+" < 255 0 ?")
average_v=mt_lutxy(org_minus_v,org_plus_v,"x y - abs "+cthr+" < 255 0 ?")
average_y=mt_lutxy(org_minus_y,org_plus_y,"x y - abs "+ythr+" < x y + 2 / 0 ?")

diffplus_y = mt_lutxy(org_plus_y, org, "x y - abs "+md+" < 255 0 ?")
diffminus_y = mt_lutxy(org_minus_y, org, "x y - abs "+md+" < 255 0 ?")
diffs_y = mt_logic(diffplus_y, diffminus_y, "and").Greyscale()

ymask=average_y.mt_Binarize(threshold=0,upper=false)
ymask=usemaxdiff ? mt_logic(ymask, diffs_y, "and") : ymask
cmask=mt_logic(average_u.mt_Binarize(upper=false),average_v.mt_Binarize(upper=false),"and")
cmask=cmask.PointResize(cmask.Width()*2, cmask.Height()*2)

themask=mt_logic(ymask,cmask,"and")

fixed_y=mt_lutxy(average_y,org_y,"x y + 2 /",y=3,u=2,v=2)

output=MergeChroma(mt_Merge(org_y,fixed_y,themask),org)
output=ConditionalFilter(org, org, output, "YDifferenceFromPrevious()", ">", sc)
output=ConditionalFilter(org, org, output, "YDifferenceToNext()", ">", sc)

return (default(mask,false)?themask: output)

}

you got more stable result, a little blurring in some affected areads, and about 4% better compressibilty on clips i have tested (for --crf 22)
speeddown or speedloss not tested.

[TheSkiller]

Hello guys,

recently I filmed with my MiniDV Camcorder and now, rather accidentally, I noticed some strange artefacts that TempGauss produces. It is a shot of a house, me standing on the other side of the road filming, when a person on a bike rides by. The rim of the bike causes some sort of "temporal smearing" or ghosting.

The footage was filmed with a Sony DCR-TRV 33E at a very high shutter speed (probably above 1/2000), so the motion is without any motion blur and super sharp.

Here is a screen shot of the problem:
http://img268.imageshack.us/img268/6899/bikeod.jpg

Avisource("Bike.avi")
assumeBFF() #just to make sure
TempGaussMC_beta2(2,2,0, 4,0,4, lossless=-1, edimode="nnedi2", SVthin=0)


And here is the clip (DV AVI, unprocessed):
http://www.mediafire.com/?2hxylynmumz

I already tried different TGMC settings, but nothing really helped too much.

I don't really need to have this deinterlaced because I'm storing it on DVD, but for scientific purposes - and because I'm curious - I'd like to know if there are any solutions
for this issue. :rolleyes:

[2Bdecided]

Absolutely zero blending on your clip using tempgaussmc_alpha3().

On TempGaussMC_beta2, I see blending just like you.

Cheers,
David.

[Didée]

No time for deeper elaboration.

Basically, MVTools is missing the correct motion on the bike's rims.


@2Bdecided

With "absolutely zero blending", you're leaning a little far out of the window. alpha3 is not 100% free of blending. It's more like 90% only. (But I don't like such percentage numbers.)

And of course, beta2 can do the same. I told that in the past, and the fact hasn't changed since.

-----------------
tempgaussmc_alpha3(2,2,0,edimode="eedi2")
==
tempgaussmc_beta2(2,2,0,12,0,1,"eedi2",SLmode=1)
-----------------

The repair triple "12,0,1" is the exact equivalent of rep0/rep1 hardcoded in alpha3.
SLmode=1 is the limiting mode hardcoded in alpha 3.


OTOH, alpha3 has a lot more bob flicker. (Due to spatial limiting, which is a lame method generally.)


Suggestion: (not much tested, just a quick try)

-----------------
tempgaussmc_beta2(2,2,0,12,12,0,"eedi2",SLmode=2,search=5,searchparam=8,dct=5)
-----------------

This avoids blending as alpha3 does, but has less bob shimmer than alpha3, and (slightly) more/sharper/morestable detail.

[2Bdecided]

Didée, I know you told me before - I haven't forgotten - but I'd already tried two approaches to find one that worked - further experimentation was left as an exercise for the reader! :) I knew you'd be along soon enough to give good advice.

Cheers,
David.

[Didée]

Comparison of beta2 and alpha3: >LINK (http://www.mediafire.com/?gmqldzqmz5e)< (MediaFire, ~15 MB)

Sorry I forgot to Subtitle(). beta2 is to the left, alpha3 is to the right.

( Clip has been processed with Xvid settings that I use to watch out for bob shimmer: Hi-bitrate matrix, *no* B-frames. These settings are very sensitive to [differences in] bob shimmer, even when the eye can't notice easily.

Compressed individually, beta2 is 20% smaller than alpha3. That's an obvious indication that alpha3 has more bob shimmer. Exactly as expected. )

[der_groschi]

I'm following the discussion for some time now and i've read a lot about TGMC not being well suited as an input for srestore.
However, i still use it to feed srestore (with a simple TDeint(Mode=1) as detection clip) since with many sources where TDeint+EEDI2 and similar filters fail badly, TGMC still gives me a sharp, stable and flicker-free result.
Now my two questions are:
1) What about other advanced Bobbers (MVBob, MCBob, etc.)? Is there any good alternative to treat field-blended material?
2) Are there any tweaks for TGMC to make it work better for that purpose?

[txporter]

I'm following the discussion for some time now and i've read a lot about TGMC not being well suited as an input for srestore.
However, i still use it to feed srestore (with a simple TDeint(Mode=1) as detection clip) since with many sources where TDeint+EEDI2 and similar filters fail badly, TGMC still gives me a sharp, stable and flicker-free result.
Now my two questions are:
1) What about other advanced Bobbers (MVBob, MCBob, etc.)? Is there any good alternative to treat field-blended material?
2) Are there any tweaks for TGMC to make it work better for that purpose?

I am glad that you posted your question. I hadn't seen the threads indicating why it was incorrect to use TGMC to bob field-blended material that needs to be srestore'd. I have been doing exactly that and I find the output to be good. After you posted, I tried to search for this subject and I found this thread (http://forum.doom9.org/showthread.php?t=151932) and then this post (http://forum.doom9.org/showpost.php?p=1362315&postcount=11) by Didee.

This is the script that he recommended using. I don't know exactly what each piece of it means. Maybe Didee will step through it?? (please :) ) It looks like he is using TGMC to create the final output, but using a thrice bobbed clip to detect which frames are blended. I don't understand what is happening with the 3 bobs.
mpeg2source("VTS_02_5.d2v")
o = crop(0,56,-0,-56)
tgmc = o.tempgaussmc_beta1u(1,1,1,edimode="nnedi2",blocksize=16,sharpness=1.33,SVthin=1.25,truemotion=true)
bob1 = o.bob(0,0.5)
bob2 = bob1.clense(reduceflicker=false).merge(bob1,0.5)
bob3 = bob2.mt_adddiff(mt_makediff(bob2,bob2.clense(reduceflicker=false),U=3,V=3),U=3,V=3)

tgmc.Srestore(frate=25.0,dclip=bob3)

[Gavino]

It looks like he is using TGMC to create the final output, but using a thrice bobbed clip to detect which frames are blended. I don't understand what is happening with the 3 bobs.
...
bob1 = o.bob(0,0.5)
bob2 = bob1.clense(reduceflicker=false).merge(bob1,0.5)
bob3 = bob2.mt_adddiff(mt_makediff(bob2,bob2.clense(reduceflicker=false),U=3,V=3),U=3,V=3)
...
There's only one bob in there. ;)

[txporter]

There's only one bob in there. ;)

Ok, right. I see that. Still don't understand what is happening there exactly.

Clense is a function of RemoveGrain that performs temporal min-mix clipping for RemoveGrain, correct? I can't find any good information on the input parameters for Clense.

The merge function is used to then average (0.5) the luma and chroma channels of the two clips (the straight bob'd clip and the bob'd version that has been processed through clense), right? What is this actually doing?

Then bob3, seems to take bob2 (bob1 that has been clensed) and then clense it again, and then take the difference between the singly clensed and doubly clensed clip. I think that the U=3 and V=3 means that both luma and chroma should be processed. THEN, the difference between the singly clensed and doubly clensed clip is merged into the singly clensed clip. Why? Isn't this just the doubly clensed clip? This is where I have the most confusion.

The final srestore arguments, I think are more straightforward. It looks like it uses the TGMC clip as the output clip but srestore uses the clensed/bob'd clip to determine which frames to throw out/keep. What I don't understand totally (besides what I have shown to be beyond my comprehension above) is why the TGMC clip itself isn't suitable for the srestore function all on its own.

[Revgen]

^Unless you are using lossless mode, TGMC doesn't retain the original fields. The bobber you use needs to retain the original fields in order to use SRestore.

[txporter]

What are the benefits of using the bob/clense chain than simply bobbing with yadif or tdeint and using that for blend detect and then using tgmc for the interpolation?

[der_groschi]

^Unless you are using lossless mode, TGMC doesn't retain the original fields. The bobber you use needs to retain the original fields in order to use SRestore.
You mean because the blend-detection will get screwed up? That's what the TDeint'ed detection clip is for. But from what i remember, TGMC's motion compensation is a little useless on fieldblended sources.

[txporter]

Also interested to hear. I ran a clip (PAL=>NTSC) through TGMC.Srestore(frate=25) and again through TGMC.Srestore(frate=25, dclip=yadif) with yadif=Yadif(mode=1, order=1). I then did a Stackhorizontal on the two clips. I don't see any obvious issues with just running without the detection clip. Even when stepping through using the following comparison script. Some stuff highlights as different, but nothing that I can visually notice as a problem.

a=mpeg2source("video-1.d2v")
b=mpeg2source("video-2.d2v")

sub = a.subtract(b)
substrong = sub.levels(122,1,132,0,255)

return StackVertical(StackHorizontal(a.subtitle("TGMC.Srestore"),b.subtitle("TGMC.Srestore(dclip=Yadif)")),
\ StackHorizontal(sub.subtitle("Difference"),substrong.subtitle("Difference amplified")))

If you are interested, you can download the 2 different stacked videos here (http://txporter.tonidoid.com:10001/app/websharepro/share/TGMC%20test/).
stack-2plots.mp4 = TGMC vs TGMC(dclip=yadif)
stack-4plots.mp4 = same + differences

[der_groschi]

Also interested to hear. I ran a clip (PAL=>NTSC) through TGMC.Srestore(frate=25) and again through TGMC.Srestore(frate=25, dclip=yadif) with yadif=Yadif(mode=1, order=1). I then did a Stackhorizontal on the two clips. I don't see any obvious issues with just running without the detection clip. Even when stepping through using the following comparison script. Some stuff highlights as different, but nothing that I can visually notice as a problem.

Interesting videos. While both clips appear to look equally good in a quick visual comparison, every small difference means that srestore picked a different frame or made a different decision in its duplicate detection. Since (from my experience) TGMC tends to make blends almost dissappear, it's actually very hard to tell if srestore picked the right frames. Thanks to your nice demonstration, i can see it does not. So i would definitly say it's safer to feed srestore with a clean detection clip. From that point of view, didee's suggestion looks very reasonable to me.

[aegisofrime]

Didee: Would it be safe to say that now that you have a multicore PC yourself, there might be a multithreaded 64-bit version of TGMC in the works? :)

[txporter]

Didee: Would it be safe to say that now that you have a multicore PC yourself, there might be a multithreaded 64-bit version of TGMC in the works? :)

TGMC is just an avisynth script that uses other plugins. There was some talk in the ThreadRequest thread about attempting to incorporate that into the script itself, but that isn't limited to 64-bit. I wouldn't expect TGMC to be overhauled just because Didee has a new rig and a 64-bit system. Perhap, he will be able to tweak things a bit better because he has access to a machine with multiple cores. /shrug

[txporter]

Redid the speed comparison tests using AVS2AVI rather than x264 and included testing on a 480i and 1080i clip.

Test machine:
Q6600 cpu
4GB Ram
Avisynth 2.5.8 MT 32-bit (set)
Vista Home 64
AVS2AVI v1.39 (had to use LAGS encoding since I was getting crashes with null, so still not perfect)

Both clips were 2mins of source material [MPEG2].
aviscript (default settings example - NO setmtmode was used on any of the runs):
MPEG2Source("video1.d2v")
TempGaussMC_beta2(2,2,1,4,0,4,edimode="EEDI2",Smode=2,SLmode=2,Sbb=1,SVthin=1.0,pelsearch=2)
Table key:
fps [?x] default - speed comparison to default settings
%fps improvement - speed comparison to default for edimode changes, and then speed comparison to previous run for various bicubic edimode runs. Zero sharpening was compared to Smode/SLmode=1 run.

I included conversion time for folks to get an idea how long they can expect conversions to take.

Two highlighted percentages are the two settings that show the largest difference in fps for HD source vs SD source

Order of speed improvement gains:
SD HD
1. edimode=bicubic 1. tr1 2=>1
2. edimode=Yadif 2. edimode=bicubic
3. tr1 2=>1 3. edimode=Yadif
4. edimode=nnedi2 4. edimode=nnedi2
5. edimode=nnedi 5. edimode=nnedi
6. SLmode 2=>1 6. rep2 4=>0
7. tr2 1=>0 7. SLmode 2=>1
8. sbb 1=>0 8. tr2 1=>0
9. pelsearch 2=>1 9. sbb 1=>0
10.rep2 4=>0 10.rep0 4=>0
11.no sharpening 11.pelsearch 2=>1
12.rep0 4=>0 12.no sharpening
13.SVthin 1.0=>0 13.SVthin 1.0=>0
14.tr0 2=>1 14.tr0 2=>1
15.Smode 2=>1 15.Smode 2=>1
http://img251.imageshack.us/img251/9243/tgmcavs2avispeed.jpg (http://img251.imageshack.us/i/tgmcavs2avispeed.jpg/)

[txporter]

What are the benefits of using the bob/clense chain than simply bobbing with yadif or tdeint and using that for blend detect and then using tgmc for the interpolation?

I think I found some answers to this question in this post (http://forum.doom9.org/showpost.php?p=1380815&postcount=22) from Didee and perhaps a bit more in this one (http://forum.doom9.org/showpost.php?p=1172296&postcount=22). As I understand it, it seems that ReduceFlicker/Clense are used to combat the bob shimmer that is seen in basically every bobber (except TGMC) so that srestore has as clean a detection clip as possible to pick out the correct frames.

[txporter]

Interesting videos. While both clips appear to look equally good in a quick visual comparison, every small difference means that srestore picked a different frame or made a different decision in its duplicate detection. Since (from my experience) TGMC tends to make blends almost dissappear, it's actually very hard to tell if srestore picked the right frames. Thanks to your nice demonstration, i can see it does not. So i would definitly say it's safer to feed srestore with a clean detection clip. From that point of view, didee's suggestion looks very reasonable to me.

I am still trying to understand what is best for the detection clip. I encoded the same clip using a simple bob(0,0.5) as dclip, using yadif(mode=1, order=1) as dclip, using the 3 stage bob parameters as dclip (couldn't get reduceflicker=false to work so had to kill that part), and using only the tgmc bob input.

Stack of those 4 clips + source + avs can be found here (http://txporter.tonidoid.com:10001/app/websharepro/share/dclip/). I included the frame number on each frame so that we can see which frame was chosen by srestore. I do see that sometimes a different frame is chosen for the TGMC input and sometimes different for yadif and sometimes different for bob(0,0.5) and other combinations. It looks to be picking either the odd or even frame. I don't know which is right.... I don't see blends in any of the outputs. Using a detection clip definitely results in faster detection for Srestore though (compared to using the TGMC bob as input).

update: moved this discussion to the Srestore thread (http://forum.doom9.org/showthread.php?p=1415749#post1415749)

[Didée]

The following settings (all together) fixed the issue:

blocksize=8,
search=5,searchparam=4,dct=5,
SCth1=270,SCth2=144

I can't evaluate right now which is the most responsible ... my guess is that the scenechange detection was triggering when it shouldn't. But it would need closer examination to nail it down.

* * * *

Couldn't really look at the content yet, but ... isn't that MFlowFPS-style deformation in there?

[Redsandro]

I'm getting tired of it, so throw it out in the wild ...

TempGaussMC, version beta-2 (http://www.mediafire.com/file/ykyg5ymmzyw/TempGaussMC_beta2.rar).

Just like to say thanks, this is pretty awesome!
It does a very nice job on faster motion footage. On low motion footage it's a bit too clean for my taste. Feels like it's removing some valuable high frequency data. Makes the oldskool method tempting, but overall this is very nice!

The oldskool tdeint method is the other way around. Higher motion removes high frequency data probably because of ugly interpolating or something that looks like it.

The smoothing/cleaning on TempGaussMC can probably be toned down, but I am too lazy to read through the different topics about this.

For reference purposes, here's what I used:

SetMemoryMax(1024)
AviSource("test.avi")

ColorMatrix(dest=2,hints=false,interlaced=true)
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\nnedi2\nnedi2.dll")
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\mvtools\mvtools2.dll")
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\VerticalCleaner\VerticalCleaner.dll")

AssumeTFF()
TempGaussMC_beta2(2,2,3,EdiMode="NNEDI2",qual=3)


Oldskool:

## RED DGDecode Template 2008-04 (last update: 2009-11-28) http://www.Redsandro.com
# Keep it down, dunno if it helps, I don't notice swapping if set to 1 and I don't know optimal value for HD content.
SetMemoryMax(8)
AviSource("test.avi")

# Deinterlace
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\TDeint\TMM.dll")
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\TDeint\TDeint.dll")
LoadPlugin("D:\Program Files (x86)\AviSynth 2.5\plugins\nnedi2\nnedi2.dll")
AssumeTFF() # HDV
# Normal
tDeint(order=-1, emask=TMM(length=6),edeint=nnedi2())
# Double Frame rate
#tDeint(mode=1, emask=TMM(mode=1), edeint=nnedi2(field=-2))