MoComped deinterlace... don't know why i didn't think of this approach before.

[Mug Funky]

just had a flash of inspiration. it's obvious, really.

the main problem with making a motion compensated deinterlacer with MVtools is you need a good bob to start with, and if you work just with separated fields, the compensation screws up the half-pixel offset that odd and even fields have.

so...

i wondered what would happen if i motion-compensated field-separated video, but got my vectors from a bob?

the result is pretty good! to make things smoother, i've use forward and backward compensation and mixed them together.

it runs surprisingly fast.

however...

there's no protection from bad matches at this very early stage (this can be added pretty easily, but i can't be arsed doing it now - i want this script's concept tested first).

also, chroma doesn't get compensated at the moment (i've just used MVcompensate as is). this could be added as well, or you could do it manually by using my script on 3 clips, Y, U, and V.

here's the script:

function MVbob(clip c)
{
	order=(c.getparity==true)? 1:0
	
	bobd=c.kernelbob(order=order).verticalreduceby2()
	fields=c.separatefields()
	mvf=bobd.mvanalyse(sx=4,sy=4,pel=1,isb=false)
	mvb=bobd.mvanalyse(sx=4,sy=4,pel=1,isb=true)
	
	even1=c.separatefields().selecteven()
	odd1a=fields.mvcompensate(mvf).selecteven()
	odd1b=fields.mvcompensate(mvb).selecteven()
	odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)
	
	even2=c.separatefields().selectodd()
	odd2a=fields.mvcompensate(mvf).selectodd()
	odd2b=fields.mvcompensate(mvb).selectodd()
	odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd1b,0.5)
	
	even=interleave(even1,odd1).weave()
	odd=interleave(even2,odd2).weave()
	
	interleave(even,odd)
}

hopefully this can give some other people ideas on how to prevent errors leaking through, because as it is now, this script should not be used if you want a good result

[edit]

hehe... this thing eats camera pans for breakfast! all it needs is a few kinks ironed out and it'll be rocking.

[scharfis_brain]

wow!
this thing is really cool!
and it is fast!

but it suffers from mvtools lacking sub-pixel accuracy.
manao? will this feature be included in one of the future versions?

could it be combined with this experimental global-motion-compensated deinterlacer?

avisource("doom9.avi").assumetff()
bob()
showframenumber(scroll=true)
i=converttoyv12()
m=depanestimate(i,zoommax=1,improve=false,pixaspect=0.94)
i.DePanInterleave(data=m,pixaspect=0.94,prev=1,next=0)
separatefields()

selectevery(8,0,3,5,6)
weave()
stackhorizontal(last.subtitle("depan-bob"),i.subtitle("bob()"))

[scharfis_brain]

I played with mug funky's mvbob() a little bit, and found how to add some little subpixel accuracy:

function MVbob1(clip c)
{
order=(c.getparity==true)? 1:0

bobd=c.kernelbob(order=order,threshold=8).verticalreduceby2().lanczos4resize(c.width,c.height)

fields=c.separatefields().tomsmocomp(-1,-1,0) 
mvf=bobd.mvanalyse(sx=4,sy=4,pel=1,isb=false,lambda=2000)
mvb=bobd.mvanalyse(sx=4,sy=4,pel=1,isb=true,lambda=2000)

even1=c.separatefields().selecteven()
odd1a=fields.mvcompensate(mvf).selecteven()
odd1b=fields.mvcompensate(mvb).selecteven()
odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)

even2=c.separatefields().selectodd()
odd2a=fields.mvcompensate(mvf).selectodd()
odd2b=fields.mvcompensate(mvb).selectodd()
odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd1b,0.5)

even=interleave(even1,odd1.separatefields().selecteven()).weave()
odd=interleave(even2,odd2.separatefields().selectodd()).weave()

interleave(even,odd)
}

it works with edge-directed upsampled fields now
first I tried a pure kernelbob, but its jaggy output made the MC going worse. so I decided using verticalreduceby2.lanczos4

this mvbob1 has the downside, that small movements tend to produce slight bobbing, but the overall quality is better, cause now its has the double pixel accuracy.

[Manao]

Yes, I plan to make a release tomorrow, and half pixel search will be working correctly. I'll disable the motion interpolators ( I'm currently rewriting it, because they were more than a mess ). It just misses the documentation right now.

However, you'll need to change the syntax a little.

[Mug Funky]

thanks, scharfi... the idea was frighteningly obvious, no? i initially tried using dumb bob, but this would hit unmoving areas. leak's optimised kernelbob is almost as fast and doesn't suffer from that.

now what's needed is some sanity-checking in it. this will involve masking, and will probably slow it down a fair amount. right now it isn't so good with scenechanges, and as you say suffers from lack of subpel accuracy (though if you're downscaling the output it isn't really a big deal).

manao: thanks again for MVtools, masktools, etc. it's scary how useful these tools are

[edit]

scharfi: if you're upscaling, you should probably make the blocksize 8 to avoid too much jumping around of the vectors.

[Chainmax]

Have you tried using TDeint's bobber instead?

[Mug Funky]

didn't see much difference...
considering i want to wrap this thing in masks to stop false-matches coming through, i chose kernelbob for a tradeoff between speed and accuracy on static areas (the dumb-bob shimmer gets confused with motion, so we can't be having that).

[Chainmax]

Didn't Leak say some time ago that his KernelBob had a bug?

[Mug Funky]

well, i haven't noticed... maybe it's a chroma thing? the output is sufficient for this script, and it's definitely fast enough

any bugs on the bob stage will be outshone by artefacting in the deinterlace. (though now manao's released a new MVtools i can go down to half-pel).

[Didée]

No intention to be penetrant, but the method reminds me a little of a comment in this thread:

Originally posted by Didée, 2 months ago

What about te following:

Generally:

- Make a *soft* bob, e.g. TMCbob with "line averaging" active
- calculate fw & bw vectors
- selecteven/selectodd those vector clips
- apply MVCompensate to the original top/bottom field sequences, using those "decimated" vector clips, producing fw and/or bw compensated fields
- try and see if those can be used as-is, or if averaging fw(n-1) with bw(n+1) is better, or ...

Basically, here it is a problem that the vectors are created on a bobbed source with lack of vertical information, thus making the vertical coordinates of the vectors unprecise.
However, using a soft bobber should already dim the problem down. Additionally, one could try either of the following:

- Take the soft-bobbed clip, reduce its height by 2, then calculate the vectors
- Take the soft-bobbed clip, sharpen it vertically, calculate the vectors, apply ^^above procedure on the fields with point-resized doubled height, and reduce them again afterwards

... or something similar.

Vertical precision *might* be a problem, but it should be possible to make it minor enough. The vector lenghts, however, would be correct.

I suppose it could work. Or someone tell me why it obviously can't work.

As long as the idea survives

BTW, what about working on double-height fields and reducing 'em afterwards, instead of VerticalReduce'ing the bobbed clip? I'm under the impression MVanalyse's results get better with increasing framesize.

[scharfis_brain]

TW, what about working on double-height fields and reducing 'em afterwards, instead of VerticalReduce'ing the bobbed clip? I'm under the impression MVanalyse's results get better with increasing framesize.

ermmm....

Did you read my 2nd post of this thread?
(verticalreduceby2() afterwards will only blur and return vertically mis-aligned fields)

[Didée]

ermmm ...

Did you read my post carefully enough. I spoke of reducing the double-heighted fields. This wording leaves room - and so it was intended - for an arbitrary operation. I did not speak of applying VerticalReduceBy2() on them ...

But now I realize I just did it again. I dared to speak about deinterlacing. Heaven help, when will I finally learn to seal my mouth on this topic

[Leak]

Originally posted by Chainmax
Didn't Leak say some time ago that his KernelBob had a bug?

Well, I'm not doing an AssumeFrameBased at the end, which makes it different from Scharfis_Brain's original KernelBob, but after some discussion it turned out to rather be a feature than a bug, and if you like the old behaviour you can just add the AssumeFrameBased after KernelBob and it'll act the same.

So, no, it's not neccessarily a bug.

np: Faction - And Not Very Transparent (Intelligent Toys 2)

[Mug Funky]

aaaah, i remember reading that post, didee... must have sunk into the bottom of my mind and jumped out again

still, the script's out there, so it's all good. feel free to hack at it (it really needs some kind of protection against blocking).

the half-pel search of the latest MVtools helps it quite a lot - near-horizontal lines are less wibbly.

Leak: good to hear there's no bug. i certainly never saw a difference, but i may have missed something because the frames were going by so much quicker with your version

[Leak]

Originally posted by Mug Funky
Leak: good to hear there's no bug. i certainly never saw a difference, but i may have missed something because the frames were going by so much quicker with your version

*g*

Well, you could consider it a bug as without the AssumeFrameBased you can't really use SeparateFields on the output, but as I said, some people thought it should work that way, so I kept it.

np: Triola - Neuland (Im Fünftonraum)

[scharfis_brain]

exept of some minor glitches with heavy, non estimateable motion, this mvbob() rocks.

here are some sample images:

http://home.arcor.de/scharfis_brain/...doublweave.jpg
http://home.arcor.de/scharfis_brain/...-kernelbob.jpg
http://home.arcor.de/scharfis_brain/mvbob/038-mvbob.jpg


http://home.arcor.de/scharfis_brain/...oubleweave.jpg
http://home.arcor.de/scharfis_brain/...-kernelbob.jpg
http://home.arcor.de/scharfis_brain/mvbob/674-mvbob.jpg

I additionally included a weaved image to show the amount of interlacing.

[morsa]

could this be adapted to output 25 fps for Pal and 30 for NTSC ?
May be I'm really lost.....Scharfis.....!!

[scharfis_brain]

just place selecteven() after calling mvbob1()

this little function Mug Funky gave us, is able to make interlaced video looking more like it has been filmed as progressive

[joshbm]

@scharfis_brain:

I've tried mvbob1() and it appears to give very rigid looking output. While mvbob() works quite nicely. Any ideas?

Regards,
Josh

[Mug Funky]

scharfi: i was hoping you'd try it out on that clip it's a pretty good benchmark for deinterlacers.

could it possibly be uploaded somewhere? i suppose anything with pans and stuff would work.

[edit]

MVcompensate's syntax has changed, and kinda broken my script (it stores compensation off the original clip now in it's default mode). here's an updated one.

using blksize=4 and pel=2 makes things very slow, but quite delicious

function MVbob(clip c,int "blksize", int "pel", int "lambda")
{
	order=(c.getparity==true)? 1:0
	
	blksize=default(blksize,8)
	scd=(blksize==8)? 300 : round(300/4)
	pel=default(pel,1)
	lambda=(blksize==8)? default(lambda,2000) : default(lambda,1000)
	
	bobd=c.kernelbob(order=order).verticalreduceby2()
	fields=c.separatefields()
	mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,compensate=false)
	mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true,compensate=false)
	
	even1=c.separatefields().selecteven()
	odd1a=fields.mvcompensate(mvf,mode=1,thscd1=scd).selecteven()
	odd1b=fields.mvcompensate(mvb,mode=1,thscd1=scd).selecteven()
	odd1=mergeluma(odd1a,odd1b,0.5).mergechroma(odd1b,0.5)
	
	even2=c.separatefields().selectodd()
	odd2a=fields.mvcompensate(mvf,mode=1,thscd1=scd).selectodd()
	odd2b=fields.mvcompensate(mvb,mode=1,thscd1=scd).selectodd()
	odd2=mergeluma(odd2a,odd2b,0.5).mergechroma(odd1b,0.5)
	
	even=interleave(even1,odd1).weave()
	odd=interleave(even2,odd2).weave()
	
	interleave(even,odd)
}

"pel" is the same as MVanalyse's pel. either 1 or 2, for fullpel and halfpel respectively.

"blksize" is the same as the new blksize parm in Mvtools. default 8, but 4 will give nice results at slower speed.

"lambda" is a kind of "vector cleaner". it increases the vector field coherence, thus reducing stray vectors. default works okay. it must be doubled for 4x4 blocks i find (or should it be quadrupled? it doesn't have enough of and effect to really worry).