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