PDA

View Full Version : deinterlace using depan


Terka
25th October 2009, 13:04
anyone tried depan for deinterlace?
idea:
instead od spatial use temporal to fill missing fields.
for moving areas use spatial.
this could improve static areas beeing calm.

scharfis_brain
25th October 2009, 13:22
that is, what mcbob and tempgaussmc already do.
using depan with it global only motion compensation will lead to lesser accuracy.

Terka
25th October 2009, 13:39
correct me, i thought TG does it spatial and afterwards denoise?
i mean do global, so maybee there are less errors IN STATIC than full mo-comp. afterwards by masking static use weave for static.

Didée
25th October 2009, 14:07
What errors in static areas?

Terka
25th October 2009, 14:14
full mo-comp isnt perfect, it has errors

scharfis_brain
25th October 2009, 14:24
global motion compensation isn't perfect either.
I isn't able to cope with lens distortions. It works best with a long tele lens.
With wide angle shots you'll have lots of mismatches in the outer areas of the image due to barrel or planar geometry of the lenses.

Didée
25th October 2009, 14:26
Sure, mo-comp has always errors. But if I get you right, you're talking about errors in *static*, i.e. motion-less areas. I'm not aware of serious mocomp-errors in static areas. Care to show some of those errors?

Terka
25th October 2009, 14:39
yes, u are right, no serious errors but there exists moving areas after TGMC where no motion should be.
we had several discussions about tgmc, you proposed new points of view (eg. vectors coherence...), so i wanted to try temporal filling instead of spatial.
of course the err. in temporal filling are MUCH WORSE than spatial,
so the masking is crutial for use on static part only.

Didée
25th October 2009, 14:56
I remember you had mentioned such issues. I don't remember to have seen them. IIRC you first talked about it in reference to the grass areas in the Psi clip (with the cute dogs) ... point out some frame/field number, to make known what to look for?

***

For the Depan suggestion: I don't quite see the breakthrough in the suggestion. Broken down to the bare bone:

a) Deinterlacers using motion compensation are already there
b) The suggestion is to use another kind of motion compensation
c1) The currently-used technique of motion compensation has little problems with static areas
c2) But it might have problems with tricky, hard-to-compensate motion
d) Depan could fit for the c1) case (that IMO doesn't need improvement), but it does not fit at all for the problematic c2) case

Also, how would you go to differentiate if any big pixel differences are due to detail, or due to motion?

Really, the last bit biting back is alwys this: deciding if a given difference between some pixels is "for real", or if it is artificial.

^That^ is THE question of all. It was, it is, and will be. Depan does not give any additional clue to answer this question.

Terka
25th October 2009, 17:01
The tgmc with nnedi2 and mvdegrain3 and all other at default looks best in most cases.
You are right, that the 'small areas movements' are really minor. If i tried to remove them (by mdegrainx etc), then they made bigger areas with motion, which was even worse.
psi frame 21-22-23 left bottom corner, 22-23 bottom middle. its visible in vdub, zoom150%.
the following is teoretical it is not proved
so i wanted to try the global motion mo-co
1. followed by deinterlacer. -> more areas are weaved because the global motion is covered -> better static & global motion areas
2. or to use global motion mo-co for denoising or limiting in tgmc.

Didée
25th October 2009, 17:14
I'll have a look at those spots.

There's something else that TMN nobody has implemented for Avisynth yet: Use existing deinterlacers like TDeint by feeding them with compensated neighbors.
I had this on my mind years ago - but instead, I went for inventing MCBob, back then.

Quasi-code:

----------------------------------------
forward2 = [by-method-of-choice]
forward1 = [by-method-of-choice]
backward1 = [by-method-of-choice]
backward2 = [by-method-of-choice]


interleave( forward2, forward1, source, backward1, backward2 )

Make_appropriate_weave_of_fields

TDeint

Make_appropriate_select
----------------------------------------

This constructs a clip where the neighbor fields of the current field are made "static" (as good as the MV engine will manage to do). Then let the deinterlacer do its usual job - if the deinterlacer is up to its claims, then it should use (weave) the good parts of the compensations, and should discard the bad parts of the compensations, using inbuilt interpolation.
If the deinterlacer is not up to its claims, you'll get artifacts nonetheless.


Have fun implementing something new! :)

Terka
25th October 2009, 18:38
ive tried depan -> tdeint, yadif today. (only 1 forward comp.)
yadif failed, tdeint not, but im not much familiar with it, the weave/bob should be balanced well.
Make_appropriate_select -> not yet finished.

what is tmn?

Terka
25th October 2009, 18:47
tried:
separatefields (sf)
sf-moco (using depan)
weave together
but not good result

so i made bob, select bottom fields
make depanestimate search on them and mo-co on sf.
was a little better
problem to feed it to tdeint was that i wasnt able to use the thresholds for static togeter with edeint=nnedi2

Terka
28th October 2009, 14:48
dont have much time this week,
fast try:tried simple denoising using depan on deinterlaced footage (same as example on depan page+prefilter from TG)
the result (avoided from borders) looks quite good.


i = ConvertToYV12()
mdata = DePanEstimate(i)
x=DePanInterleave(i, data=mdata,subpixel=2,matchfields=true)


mo_denoiseAB ( x, x.calmii(), refframes=3,thSAD=20 )
#b=SelectEvery(3, 1) .ConvertToYUY2()
b=SelectEvery(3, 1)
#stackhorizontal(a,b,Overlay(a,b, mode="difference", pc_range=true).tweak(sat=3.75))
b
a



function mo_denoiseAB (clip denoise,clip calm , int "idx", int "blksize", int "overlap", int "blksize", int "sharp", int "thSAD", int "refframes")
{
clp=denoise
idx = default(idx,20) # idx
blksize = default(blksize,4) # blksize value (4, 8 or 16)
overlap = default(overlap,blksize/2) # overlap value (0 to half blksize)
sharp = default(sharp,2) # 0=bilinear softest, 1=bicubic, 2=Wiener sharpest
#thSAD = default(thSAD,400) # higher risks motion ghosting and swimming, lower risks blotchy denoising
thSAD = default(thSAD,500) # higher risks motion ghosting and swimming, lower risks blotchy denoising
refframes = default(refframes,5) # 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 calmii (clip)
{
rep0=0
dbob=clip.bob(0,0.5)
ox = clip.width()
oy = clip.height()
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)
t=t1
t2 = (rep0!=0) ? t1 : t
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)
searchclip.temporalsoften(2,255,255,28,2)
return(last)
}

Terka
5th November 2009, 11:28
Because of not having much time, pasting the uncomplete version below.
could someone help with masking please?

############################################################################
#
# A try to make an deinterlacer based on global motion compensation (provided by depan)
# The benefit over nnedi2 is?? (or could be) in areas where depan sucessfully matches the global motion.
# This areas are weaved instead of bobbed.
# So the procedure could improve details in this areas.
#
############################################################################
# idea:
# 1. separate fields (sf)
# 2. create global motion compensation BACKWARD and FORWARD (sfBwd,sfFwd)
# 3. weave them with original (interleaveBwd,interleaveFwd)
# 4a. get mask by compare sfBwd,sf (maskBwd)
# 4b. get mask by compare sf,sfFwd (maskFwd)
# note: maskBwd, maskFwd could be totaly different, because depan can match totaly different part of picture!
#
# 5. use the masks where global motion compensation succeeds, to overlay over nnedi2
# fixedBwd=Overlay(interleaveBwd, nnnedi2, mask=maskBwd, opacity=1) #put interleaveBwd over nnedi
# fixedBOTH=Overlay(interleaveFwd,fixedBwd, mask=maskFwd, opacity=1) #put interleaveFwd over fixedBwd
# or maybee if intersection of maskBwd, maskFwd is not empty, use some averagings of them
################################################################################
left=2*62 right=2*104 top=2*100 bottom=2*0 #ball in psi.avi
clp = avisource("c:\Program Files\AviSynth\plugins\volejbal.avi").Crop(left,top,-right,-bottom)

# 1.- 3. +-done
sf = clp.SeparateFields().number()
nn = clp.nnedi2(field=-2).number()
#depan settings
matchfields =false
#create of global mo-compensated fields
sfBwd = sf.GlobalMOCO(prev=1,next=0,matchfields =matchfields).Subtitle("sfBwd").SelectEvery(2,0) #urcite dobre
sfFwd = sf.GlobalMOCO(prev=0,next=1,matchfields =matchfields).Subtitle("sfFwd").SelectEvery(2,1) #urcite dobre

#weave the original and mo-compensated fields together
interleaveFwd=Interleave(sf,sfFwd).weave()
interleaveBwd=Interleave(sf,sfBwd).weave()

#4a, 4b
#create motion mask by comparing original and depaned field #has to be tuned
#get mask by compare sfBwd,sf (maskBwd)
#because of comparing fields, apply some blur

Didée
5th November 2009, 17:14
Welcome in the club of time lackers.

The only problem-to-solve is point#4, the rest is/are technical finger exercise/s.

Want to hear the old boring story? Here you go.

When compairing motion-compensated fields, you'll find there are differences. Looking closer, there are "good" differences, and there are "bad" differences. The good differences are those which provide useful information. The bad differences are just bad.
The trcky part is tell which is which, and the problem is that you can't tell for sure.

First one who tried was scharfis_brain (in MVBob, that's why we have the Corrector() filter by now). That approach was insufficient.
Later, I tried in MCBob. My approach was more complicated, but still insufficient.

(Finally in TGMC, I decided to leave that road, mostly because I could not come up with any sufficient approach.)

So, you're in need of an ingenious strike. I suggest to sleep much. :)


***

While I'm at the keyboard, notes about the jumping-blocks artifacts:
(BTW thanks for pointing them out, they were easy to find when you know where to look.)

Indeed, it's mostly a problem of the motion vectors getting a little "life on their own", in places where you wouldn't expect. I didn't manage to eliminate the issue, but it got a good bit better with different settings for MVAnalyse:
(truemotion=true,blocksize=8,search=8,pelsearch=8,lambda=4^8) # slegge hamma
Less penalty for zero vectors could help also. (I didn't try, and what was that parameter again...)

However, let me tell about the visibility of the problem ...
(Note I can pointresize-zoom my whole desktop to 100-200-400% via hotkey, a godsend for pixel examination.)

100% zoom, 1.0 speed: I can't see the issue.
200% zoom, 1.0 speed: I cant see the issue.
200% zoom, 0.5 speed: I can't see the issue. (well, subliminal glance, but only when biased by prior knowledge of the issue.)
200% zoom, 0.25 speed: a small inkling of some instableness.

200% zoom, less than quarter speed or single-step: Aaaahh, there is the issue!


So yes, you're fully right about those artifacts, they are there.

And I couldn't care less, since the artifact is pretty much invisible under normal viewing conditions. Also, it is a known fact that as soon as you do frame-by-frame comparisons, you are entering artifact land. That's perfectly normal.

Terka
5th November 2009, 20:00
Another nice lesson. But if im in same club as you ;) ...
so you think point#4 is not able to be solved well (the wrong/good information story)?

Didée
5th November 2009, 20:30
Quite sure a solution is possible - our brain solves the question in an ease! How to get such performance by just compairing a few raw numbers, that's the thrill.

In any case, it's not as easy as the old-school "small diff is OK, big diff is NOK".

Or, find the magic Apply_Claims_Of_PDF() filter. :D

Terka
6th November 2009, 13:59
1. search=8?
2. if the masking is not ok, anyway the result can go to TG

Didée
6th November 2009, 15:14
Oops, I meant searchparam=8. Anyway, those aren't any dedicated/sophisticated/well-chosen settigs. It's just "turn all knobs to max" hesitation. :)

Regarding error reckognition, one of the most promising attempts in the past was this:
1) Make motion search
2) Make compensation
3) Reconstruction: Just use the compensation, weave it with original fields (no error check, we can't tell anyway)
4) Take result of 3), and make compensation of it (vectors from 1) )
5) Check error of compensation from 4), compare with error of compensation of 2)

If error from 2) is big, but error from 4) is low, it's probably error due to detail, and should be OK. Use 3).
If error from 4) is still big, then it's probably related to tricky motion or false compensation, and is NOK. Use fallback interpolation.

I once played with that, in the late MCBob age. The method showed reasonable potential, but was very slow, and of course, there still were issues. (Like e.g. an error in compensation for next or previous frame will disturb the evaluation of the current frame's interpolation. Or: if there are *similar* errors in prev/curr/next compensations, then those errors appear to be "good", though they are not.)

Or you may just try the loooose check of TGMC (VCRep function): take all error, allow what could be reasonable (vertical hi-freq error), and ditch what can't be reasonable (the remaining freq's.)

Terka
6th November 2009, 17:35
Ufff, slowly with me.
In following text i will write will instead probably will, can etc.
There are now 2 things (maybee similar):
A. depan method-masking.
In theory- if depan puts the data on the right place ( Mask has to be done by comparing the 2 fields.) so more stict masking means we still have nnedi, so the method could be better than nnedi alone.


B. error reckognition promising method.
Have problems to understand, lets take point by point
1.,2. clear
what is the difference between 2 and 3? 3=2 in my eyes.
4. i cant understand.
compensation=the act of shifting a block A to a new location B, by 100% of the length of its attached motion vector. Lets call it A'.
the vectors from 1 are A->B (pointing to B). so you want to do A -> A' ->A'' (same translation twice? on A? - makes no sense to me.)
A->A' and A<-A' ?

Didée
6th November 2009, 18:36
I clariefied a bit the wording: "Just use the compensation, weave it with original fields"

The idea simply is a back-checking of the result with itself. You start with some estimated values (the initial spatial interpolation), then apply a certain procedure [P] (the motion compensation). Then you're faced with the problem to nail down whether any given error of the compensation is due to false motion estimation, or due to the uncertainty of the correctness of the initial interpolation.

The outlined method repeats the procedure [P], by taking the result of [P] as new starting value, and executes [P] once more. The difference now is that instead of the initial (spatial) interpolation, we now use the result from the 1st temporal interpolation:
- IF the initial compensation was good, then the error after the 2nd run will be much smaller than before. (Confirmation the error was because the spatial interpolation wasn't a good reflection of the truth.)
- if the initial compensation was NOT good, then the error after the 2nd run will still be big, hopefully.

The method is more or less checking for "consistency" of the result. As said, it showed some good results, but certainly it's not the wholy grail, either. Errors still may sneak through. While the usual checking methods are plagued by the uncertainty of neighborhood similarity (which this method mostly avoids), the plague of this method is that some errors may be "proved as good" by errors in the adjacent frames.


----------------------------
Martin Gardner #1:
You're in a jail with two doors. One door to freedom, one door to execution. There are two guards. One guard speaks always the truth, one guard does always lie.
You don't know which is which, and may pose only one question to only one of the guards.
Which is your question?
----------------------------


Oh c'mon, that's easy. Child's stuff.


----------------------------
Martin Gardner #2:
You're in a jail with two doors. One door to freedom, one door to execution. There are three guards. One guard speaks always the truth, one guard does always lie, and one guard will sometimes lie, and sometimes speak the truth.
You don't know which is which, and may pose only one question to only one of the guards.
Which is your question now?
----------------------------

Oh, sh**, Oh, fu**!


The hole is black.

Terka
6th November 2009, 22:12
Same as #1. But i have 66% instead of 100% :devil:
the above sounds to me like feeding tg with tg.
or to be more precise to overlay the original fields over TG... and put it to TG again. (i tried this it with TG-not better)
not tried with mcbob.

Didée
7th November 2009, 02:08
Quite possible that we're talking at cross purposes. For instance, I'm not fully sure yet if you want to build a full deinterlacer, or want to build a post-processor for other existing deinterlacers. To me, sometimes you sound like the former, and sometimes like the latter.

What I tried to describe is not really related to feeding a deinterlacer with its own result and starting all over. (Though it sounds similar, I agree.) Instead, it targets specifically at the case of weaving mocomp'ed fields with the original fields (which TGMC is not doing at all). And the twist of the proposed method is this: the checking whether the compensation is OK or NOK for weaving is not done via spatial comparisons, but instead via temporal comparisons.

Well, no matter if cross-purposes or same-purposes ... It's not ultimately necessary to foresee each and every possible pitfall in advance. Just go ahead and try out different things. On that way, you *will* stumble in a pitfall or another, and then still is time to think about "why" you got trapped. :D

Terka
7th November 2009, 20:44
is pleasure for me to have this speaches with you, despite of its sometimes dificult for me to get over the language barier (my english is not so good)
and all the time (we say immerwere-you know im from Czech, and German was used here) the technical stuff.
Its not important if i will be in the build process (cause i alone wont be able to built it) of part or full deinterlacer.
and it also does not matter if the original fields will be changed or kept.
need to read all your post when having more time. goodnight.

Terka
9th November 2009, 11:21
D.>the checking whether the compensation is OK or NOK for weaving is not done via spatial comparisons, but instead via temporal comparisons
yes, understand, i sugested similar or the same:
T.>create motion mask by comparing original and depaned field
the question is how. (now not talking about the 'pitfalls' but about the syntax) Could you help my by example?
some:

sfBwd,sf, both to be resized, one probably be shifted by 1pixel, - i can do this
but how to make the intersection properly?
overlay? some mt_luxy - which i dont understand at all?

Thank you, T.
PS: the usage of depaned -> some (not scripted) deinterlacer (maybee tdeint) still comes in question. Or some filter which can recognise the combing for mask creation.

AVIL
10th November 2009, 21:06
Hi,

IMHO, deinterlacing with global motion compensation has no advantages. First, local motion compensation (GMC) can lead to global motion compensation. Second, GMC can't separate static areas from moving ones, or ocluded areas from visible ones.

My two pences, a quick and dirty mocomped deinterlacer. YV12 and YUY2 only.

Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\nnedi2.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\mt_masktools-25.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\mvtools2.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\ssetools.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\vinverse.dll")


x0=avisource("av59_avi.avi").killaudio().assumetff()
z=x0.nnedi2(field=-2,qual=3)
sx0=x0.MSuper(pel=2)
vf1x0=sx0.MAnalyse(delta=1,isb=false,truemotion=true,overlap=4)
mf1x0=x0.mmask(vf1x0,kind=1,ml=25,thscd1=10000)
nf1x0=x0.mmask(vf1x0,kind=0,ml=1,thscd1=10000)

xx=interleave(x0,x0)
mm=interleave(mf1x0,mf1x0)
nn=interleave(nf1x0,nf1x0)

r0=mt_merge(xx.interleaved2planar(),z.interleaved2planar(),mm.interleaved2planar(),chroma="process")
mt_merge(xx.interleaved2planar(),r0,nn.interleaved2planar(),chroma="process").planar2interleaved().vinverse()

Prerlerm73
11th November 2009, 03:54
Ive had mine for over half a year and still cant produce "good" shots on anything other than P mode.

Suggest using P or even Auto given you wont have much time to learn/practice. And for these sort of things, getting something that captures the memory is probably second to technical quality

Didée
11th November 2009, 13:15
@AVIL - I agree about GMC being rather useless for deinterlacing. A quickly build-up deinterlacer (well, bobber) showed lots of mismatches. Especially with handheld-camera footage, there's lots of small mismatches in range of half- or full-pixel, which results in aliasing.

Regarding your function, a nitpick about terminology: that is not a mocomp'ed deinterlacer. (It can't be, since it doesn't actually use motion compensation anywhere - neither directly, nor inherently ala MDegrain.) It just uses vector data to decide where to weave and where to interpolate spatially. Thus, it is a motion adaptive deinterlacer.

Testing with the usual stress test sources (VEQ test sequences, homemovies by WorBry and Terka, interlaced SD selfmade from HD sources [ParkRun, Stockholm, Shields] ), the results are underwhelming ...



@Terka - after all elaborating about that we don't have any reliable method, and that I can't think of any, you're asking "show me how!" ? - I surrender.

(Though there might be hope ... Martin Gardner showed that a possible question for the three-guards-problem exists. My problem was that I couldn't understand his solution. So, probably you've to wait for a brighter mind than me to solve the interlaced-mocomp-matching problem.) ;)


If it's just about calming-down those switching grass blocks which nobody would see anyway, I'd rather suggest to use something simple-fashioned, like

# ... TGMC snipplet ...

stage3 = (draft==2) ? t .subtitle("Draft 2")
\ : (draft==1) ? t1 .subtitle("Draft 1")
\ : (SLmode==3) ? ( (SLrad<2) ? stage2.repair(.....
\ : (SLmode==4) ? stage2.mt_clamp(pmax,pmin,Sovs,Sovs,U=3,V=3)
\ : stage2

# Dancing-grass addendum:
stage3 = stage3.ttempsmooth(2,6,6,2,2,strength=5,pfclip=searchclip)

# if "border" was active, crop it back again
(border) ? stage3.crop(0,4,-0,-4)
\ : stage3

If you want by all means, of course you can extend the ttempsmooth line with appropriate DepanInterleave/ttempsmooth/SelectEvery. :)

Terka
11th November 2009, 13:25
regarding:
show me how ..
..make a motion mask.. nothing less/nothing more. (Until next request :) )
hmm...information noise, anyway could you please help me with building the mask?
Terka:

create motion mask by comparing original and depaned field
the question is how. (now not talking about the 'pitfalls' but about the syntax) Could you help me by example?

now im trying:

clp=Interleave(sfBwd,sf)
clp_super=clp.MSuper()
clp_vectors = MAnalyse(clp_super, isb = true,blksize=bs, overlap=bs/2,truemotion=false)
calm=clp.FFT3DFilter(sigma=5, sigma2=5).FFT3DFilter(sigma=5, sigma2=5)
kind=0
ml = 4
maskc=MMask(clp,clp_vectors, kind=kind,ml = ml)

AVIL
11th November 2009, 15:54
@didée

Thanks for your analysis about my script. Like said is a quick and dirty script (i've done it to learn). Actually I use yadifmod.

Didée
12th November 2009, 15:02
(now not talking about the 'pitfalls' but about the syntax)
I was aware of that nuance. But then, to talk about the "syntax", you first need a "method". Only when it is clear precisely what operation is to be done, only then one can talk about the required syntax.

And the kind of operation still is the point. Doing spatial comparisons between reference field/frame (BTW, *reference*, not "original". That's a difference!) and compensated field/frame is unsure, for the plenty beforementioned reasons.

Now, that way of using MVTools' vectors to get a motionmask is, at least theoretically, not safe enough either. At least not for your purpose. The initial reason for your effort was that you consider MVTools' vectors are not stable enough. But, IF it is so, then you'll have the same not-stableness in that latest approach of checking the depanned field/frame. If MVTools did flutter-around by 0.5~1.5 pixels before, it will still do so now. Nothing's changed.

Now, since *either* method is to be considered unsafe, my answer was "I dunno how". I didn't consider to use one unsafe method as an exchange for another unsafe method.

Though, as always, the only thing that can disprove a good theory is ... practice. When some improvement can be achieved despite all doubts, we are all ears!

Terka
12th November 2009, 16:31
Hard to reply....
Im trying to swim. You know, my way. Its not easy to teach me. Regardless if it will help me to learn the proper style, have some questions:
If MVTools did flutter-around by 0.5~1.5 pixels>i want to expand the mask by 2 pixels? Yes, some 1.5 pixels moving areas can be recognized as non-moving areas => artefacts.

1. How to mask moving objects (by comparing 2 frames/fields)?
2. How expand the mask by few pixels?
3. The mask got from mmask is 100% for whole mask or some binarize is needed to make the mask opacity to 100%?
4. You mention quickly build-up GMC bobber with artefacts-is the code available?

Didée
12th November 2009, 17:19
o = last
bobb = o.bob().assumetff() # any bobber of choice. For plain Bob(), set correct fieldorder manually.
srch = bobb # .temporalsoften(1,255,255,35,2).merge(bobb,0.25)
mdata = srch.depanestimate()

x = bobb.depaninterleave(mdata)

x.clense(reduceflicker=false).selectevery(3,1) # variant 1 ...
#merge(x.selectevery(3,0),x.selectevery(3,2),0.5) # or variant 2

separatefields().selectevery(4,1,2) # get interpolated fields

interleave(o.separatefields(),last) # interleave original and interpolated fields

selectevery(4,0,1,3,2).weave() # weave together. (Frame reordering bcause bob streams have alternating field order)
Without any error checking. Needs to use own eyes to judge which are the good parts and which are the bad parts. (Mine do see lots of the latter, and little of the former.)