Deinterlace or Separatefields?

[15081947]

I have a pure interlaced NTSC DVD source. I am playing around with various options to deinterlace it. Since there are no "perfect" deinterlacers, I wonder if separating fields give as good or a better result.

Here are the screenshots.

No processing
http://img132.imageshack.us/img132/4937/print2wu.png

KernelDeint(order=0)
http://img436.imageshack.us/img436/8409/prkernel7hy.png

assumebff()
SeparateFields()
Selecteven()
Lanczos4Resize(720,480)
http://img306.imageshack.us/img306/43/prseparate2ux.png

Infact, some artifacts that are visible in kerneldeint() version are smoothed out in separatefields() version.

Thank you in advance for your comments and suggestions.

[Boulder]

When you separate the fields and the select one of them, you are throwing away half of the information.

Are you sure you have a BFF video?

[foxyshadis]

The entire reason deinterlacing exists is because dumb bob is just barely good enough. If you're going to do that, at least use something like eedi2, which is designed to reconstruct a missing field; lanczos just makes it all blurry and sometimes jagged.

Even if that actually is BFF, some are just pathological and need a lot of playing around with thresholds and post-processing (use tdeint in that case). Fast pans like that require a high search radius. Or try mvbob with its slow advanced motion compensation.

Using tdeint(edeint=separatefields.selecteven.eedi2) combines both methods.

[15081947]

I am not sure if it is TFF or BFF.
I tried kerneldeint() with both options and picked the one with, I felt, has least artifacts.

Here are the screenshots for TFF
Kernaldeint(order=1)
http://i1.tinypic.com/n3orib.png


assumetff()
SeparateFields()
Selecteven()
Lanczos4Resize(720,480)
http://i1.tinypic.com/n3orpz.png

I know that I am throwing away half of the information, but I am surprised by the fact that the de-interlaced frame and separatefield frame look very similar.

[foxyshadis]

That's because, in this area, it falls back on primarily using one field, resized. The motion is simply much too high here to enable any good matches with a simple kernel like kerneldeint's, and the artifacts show up where it mistakenly thinks it should compensate rather than resize.

[15081947]

Using tdeint(edeint=separatefields.selecteven.eedi2) combines both methods.

Thank you. I will try that.

[foxyshadis]

Well, that was a sample, what you'll actually need is:

interp = SeparateFields().SelectEven().EEDI2(field=0)
TDeint(order=0,field=0,edeint=interp)

iirc.

[Guest]

Well, that was a sample, what you'll actually need is:

interp = SeparateFields().SelectEven().EEDI2(field=0)
TDeint(order=0,field=0,edeint=interp)
Yes, but there's a different invocation for TFF and BFF and the OP stated:

"I am not sure if it is TFF or BFF."

[foxyshadis]

Well, then I'll throw the other one in too, TFF:

Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=interp)

Definitely step through and find out for sure first.

[LocalH]

I'm an advocate of leaving true interlaced material fully interlaced and using the deinterlacer of choice during postprocessing. The only other method that retains full temporal resolution is to double the frame rate and use an intelligent bobber, otherwise you will be throwing nearly half of the temporal resolution away (depending on the deinterlacing method). I'd also use this method if one had a hybrid interlaced/telecined NTSC source with more true interlaced footage than telecined.

[midelic]

Try tweak a little kerneldeinterlace with different threshold.
-------------------------
kerneldeint(1,0,sharp=true)
---------------------

[Manao]

I'm an advocate of leaving true interlaced material fully interlaced and using the deinterlacer of choice during postprocessing.You complicates the job of the codec, and if you really plan to deinterlace it, you prevent yourself from using top of the art deinterlacers that might not process in realtime.

So imho not that good an idea.

[Kika]

If i'm using eedi2, i prefer this methode:

separatefields().eedi2(field=3).selecteven()

[LocalH]

I said "true interlaced". If it's true interlaced footage (and not telecined or otherwise based from progressive footage), then the only feasible way to retain all the temporal resolution is to leave the video interlaced and use some sort of bobber on playback (I'm a fan of simple dumb bobbing, but I know others prefer smart bobbers that remove the vertical jittering on still details). Sure, you could apply a smart bob and encode the final output at double the framerate, but that will also increase the CPU requirements for playback, and you're probably not really going to benefit that much on the compression end as compared to an interlaced encode.

I agree, if the footage is telecined or progressive-based, then it's almost always preferable to work towards reconstructing the progressive footage. But, with true interlaced material, if you do any deinterlacing other than bobbing during your processing, then you're irretrieveably throwing out half of your temporal resolution.