Plain deinterlacing or Bob+SelectEvery: what do you prefer and why?

[Didée]

Good (awfully) test clip indeed. Reveals there is work left to do.

Why did you vertically resize for the comparison? That's less than ideal, in order to check for the raw deinterlace performance.

Your result with MVBob I cannot reproduce at all. With the latest version, just "MVBob()" gives me this:



And that's pretty much the performace I'm getting always of it. Only rescue is to reduce "correctth" so much that the whole thing becomes almost a no-op.
You surely didn't mix up something? Could you please state the exact settings used?

[WorBry]

Didee,

Yeah, you are right, in my haste I duplicated the frame grab from the SecureDeint encode, instead of MVBob. Here’s the ‘correct’ MVBob frame 102 (at 720x544).

http://rapidshare.com/files/268836/F...ob_14.9.06.jpg

These are the scripts I used – nothing fancy, with both MVBob and SecureBob at default.

AVISource("C:\... Test 576i25 TFF YV12 3sec.avi")
AssumeTFF()
MVBob() or SecureBob()
LanczosResize(720,544)

AVISource("C:\... Test 576i25 TFF YV12 3sec.avi")
AssumeTFF()
interp = separatefields().eedi2(field=2)
tdeint(mode=1,order=1,edeint=interp)
LanczosResize(720,544)

AVISource("C:\... Test 576i25 TFF YV12 3sec.avi")
AssumeTFF()
SmoothDeinterlace(tff=true, doublerate=true)
LanczosResize(720,544)

The MVBob (and SecureBob) version used is this one (14th Sept 2006):

http://home.arcor.de/scharfis_brain/mvbob/mvbob.rar

I resized to 720x544 because that’s the resolution I normally use for MPEG-4 encodes for PC playback, but I receive your point about it being more difficult to accurately assess deinterlacing performance. Here are the grabs again without resizing:

http://rapidshare.com/files/269028/F...06_720x576.jpg

http://rapidshare.com/files/269095/F...ob_720x576.jpg

http://rapidshare.com/files/269170/F...I2_720x576.jpg

http://rapidshare.com/files/269138/F...ce_720x576.jpg

[Didée]

WorBry -
You also messed up the TDeint+EEDI2 deinterlacing: you've to use "eedi2(field=-2)" to let eedi2 automatically adapt to the actual fieldorder, or field=3 to manually set it up for TFF. field=2 is just plain wrong, here.
Used correctly, result looks like this.

Moreover, those obvious motion artefacts should be possible to catch by using the AP feature of TDeint. Didn't try that, though.

Anyhow, if you zoom in & look close, do you still hold up with the finding about which deinterlacers avoid residual combing? I see lots of it, everywhere ...

For the new toy, this clip surely forces to make some modifications. That half-transparent static overlay is a stinker.

But results are already getting better. And when compairing to this or this or this, I feel quite comfortable with getting this instead. Feels a bit like quadrature of the circle.

A test version is here - usage at own risk only. Keeps changing.

[foxyshadis]

I spot four separate eedi2 calls (although three are pp-only), and chunks of mvbob. I would expect no less, but see if you can throw a fifth in - these new dual cores might be able to get over a half an fps right now, and you wouldn't want to ruin your reputation.

[Pookie]

Originally Posted by foxyshadis

I spot four separate eedi2 calls (although three are pp-only), and chunks of mvbob. I would expect no less, but see if you can throw a fifth in - these new dual cores might be able to get over a half an fps right now, and you wouldn't want to ruin your reputation.

LimitedSharpen and SeeSaw are peppy - fast enough for real time processing during playback.

[WorBry]

You also messed up the TDeint+EEDI2 deinterlacing: you've to use "eedi2(field=-2)" to let eedi2 automatically adapt to the actual fieldorder, or field=3 to manually set it up for TFF. field=2 is just plain wrong, here.

Yep, that was plain stupid of me. In my initial tests I reversed the field order to BFF (with ReverseFieldDominance) but with some weird results. On reverting back to TFF I overlooked to change the EEDI2(field) from 2 to 3.

Anyhow, if you zoom in & look close, do you still hold up with the finding about which deinterlacers avoid residual combing? I see lots of it, everywhere ...

True, but I wasnt suggesting it was absolute, just "rather more effective". Perhaps I should have chosen my words more carefully - ''reducing'' rather than ''avoiding" residual deinterlacing artifacts

A test version is here - usage at own risk only. Keeps changing.

Cool, thanks

[Didée]

Originally Posted by foxyshadis

I spot four separate eedi2 calls (although three are pp-only), and chunks of mvbob. I would expect no less, but see if you can throw a fifth in - these new dual cores might be able to get over a half an fps right now, and you wouldn't want to ruin your reputation.

Funny.

There are not any chunks of mvbob used. Except for usage of EEDIbob, MCBob was created from bare scratch. The multiframe max'ing of the motion mask is similar, sure ... there are not too much different ways to put a thread through a needle's eye. MCBob uses different yarn, however.

EEDI usage isn't as insane as it might look at first glance. Normally, EEDI is used either only once (EdiPre=1,EdiPost=0, or EdiPre=0,EdiPost=1), or maximally twice (EdiPre=1,EdiPost=1). Post=2 is just experimenting, anyway.
Mind you, it's not "sports" for me to make scripts as slow as possible. I just do what I think that has to be done; and if the result runs at mfps, then it does for a reason. See, the actual MVBob crawls at ~2fps for me ... and that's with MVBob, no offense, being a script doing mostly bare basics ... and looking at the result closely, I see not enough justification for the extensive processing time. Using a fast deinterlacer, out come shimmering and artefacts. Investing much time into MVBob, out come - - shimmering and artefacts ...

So, in order to do better than what we currently have, most probably things will get slower than what we currently have. Simple logic.

Speed is low due to, of course, the overall amount of operations done. In particular:

- Same-parity search requires MVFlow pixel interpolation instead of MVCompensate block compensation. Flow is slower.
(But it has to be done necessarily. Inter-parity ME/MC as in MVBob, by principle can't do much against the main "bobbing" issue: for static parts you don't need MC, and in motion parts ME will just follow the present bobbing. Blurring before searching hardly helps on that matter. Same-parity search surely rises a bunch of other problems, but basically there's no way around using it.)

- The "nothing-new" thingy forces one more set of frame's subpixel interpolation to be stored (ressources), and one more set of motion interpolations to performed (speed). From the idea, it's surely a right thing to do. How much the actual benefit is, has to be seen. It should be mostly benefitial with EdiPre=0, and much less with EdiPre=1, so it should be switchable instead of hardcoded.


Then, there are a bunch of small functions that imo nicely qualify to be coded as (more speedy) plugins:

- Vinverse() is quite handy to kill out residual combing, with visual loss close to zero.

- MinBlur() makes a "best of both worlds" combination of a (more or less) gaussian filter with median filtering. Result reminds a little of a bilateral filter.

- At lines 125~135, there is a scripted variant of MaskTools' in/expand, which also could fit well into MaskTools. The original filters "only" in/expand absolute pixel values. Here, I'm doing the corresponding operation on "difference" maps, i.e. what gets in/expanded is the pixel "magnitude", instead of the absolute value. Or in other words, a "signed" version of in/expand, where "zero" is 128.

- the "STT" thingy already is relatively fast ... originally, I implemented the idea in the way I had "seen" it, with two subsequent 7-tap-with-holes convolutions on the bobbed frames. Then I realized that practically the same could be done with just a blurry bob. Aaah, speed.

[foxyshadis]

I tease, but it looks quite interesting. Honestly, I couldn't see any difference at all in the clip you posted, but on one of my own I did. And the speed difference isn't that much!

Anyway, Vinverse is something I've needed a few times and usually had to rewrite as a custom function each time; this one looks a little nicer than my attempts. That alone is awesome.

[WorBry]

Hi Didee,

Tested MCBob v3.0 (at default settings) with the ‘stinker’ clip - I’m seeing holes and residual comb artifacts in and around the smoke in the area of the car body and wheels (above the semi-transparent strip).

http://img409.imageshack.us/img409/5...720x576ma2.jpg

http://img249.imageshack.us/img249/1...720x576vc7.jpg

http://img249.imageshack.us/img249/8...720x576dq1.jpg

http://img265.imageshack.us/img265/5...720x576fq0.jpg

Certainly, as you suggested, the AP parameter in TDeint is quite effective at removing these residuals. Here's the result with

interp = separatefields().eedi2(field=3)
tdeint(mode=1,order=1,edeint=interp, AP=5, APType=0 )

http://img401.imageshack.us/img401/2...720x576up5.jpg

Is there a similar tweak in MCBob?

[Didée]

@ Worbry

Indeed, I forgot something. Look below:

Originally Posted by foxyshadis

Honestly, I couldn't see any difference at all in the clip you posted, but on one of my own I did.

Jeeze, really not? Load in Vdub, and step through the frames. In the clip bobbed by TDeint+EEDI2, practically all detail is flickering or bobbing up/down. The row of lights in the foreground not only flickers, but in the righthand part also shows the uglyness of EEDI2 errors. MCBob for the most parts is as calm as a lossless bob filter can only do.

[Didée]

I've put up a slight revision of the script: MCBob v0.3b. Still sloppy, but it handles this motoracing clip without (too) obvious errors, while keeping the benefits intact which the whole thing is targetting at.
Also, the included Vinverse() function was updated: there was a small, but not trivial error in it.

For those with tired eyes like foxyshadis , I've uploaded some short samples that should make the difference more obvious:

1) static comparison - a scene showing the effekt of the motion masking procedure

2) motion comparison - a scene showing the effect of same-parity search vs. inter-parity search or no search at all
(lightspots & line structures (green ones!) in the background, top edge of sara's dress on the top, ...)

3) artefacts - a very short sequence with (or without) introduction of artefacts.

The sources are of mediocre quality from the start, consequently the overall look is not exactly impressing. But when compairing them one against each other, it should get pretty obvious where the differences are.

For the moment, that should've been the most part. I'll promise to make up a new thread, once I've settled down on the remaining nitpicks. (Could be Don is already drumming with his fingers, because of thread hijacking )

[Fizick]

may be moderator can split the thread?

[Chainmax]

Originally Posted by Didée

...
I'd say that, in theory, MVBob.SelectEither() should deliver superior image quality compared to the other methods, simply because the technique used for deinterlacing is more advanced.
Note that this doesnt say that the technique is already maxed-out ... MVBob does have its own problems just as well, so it's not necessarily "the best" of the available choices. The current implementation of the more advanced technique still has a few issues left over ... something should be done in that area.

Ok then, would you prefer MCBob.SelectEither() or MCBob.TDecimate(mode=7,rate=initialfps)?

[scharfis_brain]

what is the sense of doing decimation to the half framesrate on pure moving video without dupes?

[Chainmax]

I assume it will give better results than simply throwing away all the even or odd frames.

[Didée]

Wrong assumption. When you use a decimator to halve the framerate, the decimator will do nothing else but throw away half of the frames. Only difference to SelectX() is, if the decimator tries to be "smart", there's a slight chance to get jerkyness in some places.

[foxyshadis]

If you're looking for some kind of motion fluidity boost, you can use mvfps, or mvflowblur.

[halsboss]

Er, I can't reliably locate latest mvfps perhttp://forum.doom9.org/showthread.ph...298#post893298

[WorBry]

Or you could try this, a modification of Scharfis_Brain's mvfpsscd (mvfps with improved scene detection) using MG262(Clouded)'s 'MotionProtectedFPS' script instead of MVConvertFPS.

http://forum.doom9.org/showthread.ph...045#post761045

Gives nice fluidity of motion without too much blurring of slower moving detail. The original mvfps (or mvfpsscd) function is less prone to structural distortions (see the images I put up in that thread) but is much slower.

[Chainmax]

Originally Posted by Didée

Wrong assumption. When you use a decimator to halve the framerate, the decimator will do nothing else but throw away half of the frames. Only difference to SelectX() is, if the decimator tries to be "smart", there's a slight chance to get jerkyness in some places.

I see, thanks for the explanation. Does it make a difference wether the video is TFF or BFF when selecting between using SelectEven() or SelectOdd()?