Help to improve quality aftetr deinterlaced

[medp7060]

I have a interlaced MPEG-2 clips (720x576, 4:3, top field first) recorded by Sony Video Camera and I want to convert it to Xvid (704x528) using a script like this:


Mpeg2Source("sony.d2v")# at 720x576
#The option that surprided me
AssumeTFF().SeparateFields().selectodd

#or (The option that surprided me)
#AssumeTFF().SeparateFields().selecteven

#or (The one I used to use)
#AssumeTFF().FieldDeinterlace()

BicubicResize(704,528)



here is what I got (croped Frame 40 for each option above):
http://www.geocities.com/medp7060/horse.jpg

My question is why I got better picture when I separated the fields and discarded half of them compared with the one with FieldDeinterlace()?

[neuron2]

My question is why I got better picture when I separated the fields and discarded half of them compared with the one with FieldDeinterlace()? Because you didn't read the FAQ that comes with Decomb!

Try this:

FieldDeinterlace(blend=false)

[medp7060]

Thanks, neuron2. I see.

blend (true/false) will indicate whether interlaced frames will be blended (smoother image and better motion but slight ghosting) or interpolated (sharper, but a little jumpier). The default is blend=true and normally gives better results.

Acually I did, but I believed that "The default is blend=true and normally gives better results". that was why I always use the default. I happened to find this when I was trying to see what SeparateFields() does then restore the frame rate by selecting even/odd frame.

blend (true/false) will indicate whether interlaced frames will be blended (smoother image and better motion but slight ghosting) or interpolated (sharper, but a little jumpier). The default is blend=true and normally gives better results.[/QUOTE]

So the default is not good in this case.

[Dark Shikari]

If you want better quality, use a better deinterlacer.

Fast: Yadif()
Slow: MVBob()
Insanely slow: MCBob()

(all require external plugin(s))

[Chainmax]

Another option for deinterlacing would be TDeint+TMM+NNEDI, which probably would be in a similar league to MVBob regarding speed and quality.

[medp7060]

It seems there are better options. however, decomb is the easist one for me.

I am learning MCbob now. Unfortunately this link is dead: http://home.arcor.de/dhanselmann/_stuff/MCBob_v03c.avs

But why they are better? If I just want the clip deinterlaced to avoid combing?

Edited: I found the avs, but I got an error: no function named "MT_LUT", although I have loaded all the plugins required:

Import("MCBob v0.3.avs")
LoadPlugin("EEDI2.dll")
LoadPlugin("medianblur.dll")
LoadPlugin("mvtools.dll")
LoadPlugin("ReduceFlickerSSE2.dll")
LoadPlugin("MaskTools.dll")
LoadPlugin("RemoveGrainSSE2.dll")

MCBob().SelectEven() # Does it lose half resolution?

[ajk]

But why they are better? If I just want the clip deinterlaced to avoid combing?

They simply involve a more complicated process that better squeezes out all the detail, at the cost of CPU power. But you could try a faster filter than mv/mcbob at first, like yadif() as was already suggested. Usually it does a good job and is at least close to real time. You can find the plugin here (http://avisynth.org.ru/yadif/yadif.html).

[Dark Shikari]

The reason getting rid of interlacing is "hard" is because of the temporal issue:

Normal video (frames), at 30 FPS:

F_F_F_F_F_F_F_F_F_F_F

Each character is 1/60th of a second; each frame is taken at a 1/30th of a second interval.

Interlaced video:

FFFFFFFFFFFFFFFFFFFF

Each field is taken at a 1/60th second interval--so every other field won't match up with a corresponding frame.

Common approaches include simple concepts like blending, to extremely complicated methods like motion compensation. Others simply toss out some of the information; get every other field and resize it, for example.

[medp7060]

So having a photo-quality like frame does not necessarily meant a good quality of a video clip.

the theory sounds too complete for me. Please advise on this:

1) does FieldDeinterlace() discard half field of each frame?
2) I tried MCBob().SelectEven(), which meant that I lose half of the frame (the odd filed), e.g. from 576 to 288. then how MCBob() or yadif() secure a better quality if half information have to throw away in order to keep the original frame rate (25 fps)?

[neuron2]

FieldDeinterlace() uses a heuristic to determine where in the frame combing occurs. For those areas only of the picture, interpolation is used to throw away one field's data and recreate the missing data from the retained field. So, static or barely changing areas are not affected. That is the basic idea of all the adaptive deinterlacers -- change only the areas of the picture that are combed.

There are various heuristics for deciding which areas are combed. There are also various ways of recreating the data. The better ways take more processing and thus time. FieldDeinterlace() was designed to be simple and fast, because it was intended as a postprocessor to catch rare combed frames after IVTC. For real interlaced content, one would probably choose a better, but slower, filter.

Motion compensation takes things to another level entirely. I'll leave it to you to read up on that as it is quite involved to describe.

[medp7060]

So I was not correct in the sense that FieldDeinterlace() keeps the info from both top and bottom filed of a real interlaced source. In another word, it still "throws away" half of the frame and fills-in the missing data in order to decomb it.

therefore, for a real interlaced content, it is impossible to decomb without throwing-away half of the frame (selecteven/odd). that where MCBob or similar comes from? Am I right?

[Dark Shikari]

therefore, for a real interlaced content, it is impossible to decomb without throwing-away half of the frame (selecteven/odd). that where MCBob or similar comes from? Am I right?No. The point of MCBob and similar is to use the extra information to create a frame with no combing, but without throwing out any information. Thus, it retains the maximum detail, since you're throwing out the least information.

Yadif() and similar are much more practical than MCBob in most cases, simply due to raw speed.

[neuron2]

So I was not correct in the sense that FieldDeinterlace() keeps the info from both top and bottom filed of a real interlaced source. In another word, it still "throws away" half of the frame and fills-in the missing data in order to decomb it. You didn't listen carefully. In a typical interlaced frame, the motion is confined to a subset of the whole frame, e.g., a car moving across a background. The background is static and will keep the information from both fields. The moving car, however, gets interpolated. Thus it is incorrect to say that half the frame is thrown away. And as our perception of resolution is less acute for moving things, the idea works out nicely.

Be aware that motion compensation works only for simple translation. But combing can be caused by other things, such as covering/uncovering, zooming, fades, rotations, bad edits, pulldown, etc. So even motion compensated deinterlacing needs a postprocessing phase that is similar to FieldDeinterlace(). The hope is that at least some of the information that would otherwise be lost can be retained.

[medp7060]

The truth is that I have been using FieldDeinterlace() to convert my MPEG-2 capture from VHS for a long time. The results, either as Xvid or as DVD, look not bad at all. the reason was that I did (do) not know enough theory about how it works. Although there are many other ways to deinterlace my source, I have not tried yet. I am just trying MCbob() and the speed is very slow and I cannot see any difference compared with FieldDeinterlace(blend=false) in terms of each frame.

I would say FieldDeinterlace(blend=false) only makes the individual frame look better (sharper), when played to TV or computer screen, FieldDeinterlace() and FieldDeinterlace(blend=false) look almost the same to my eyes.

[Chainmax]

Well, the whole point of these procedures and the plethora of option is to find whatever pleases you the most and is more convenient to you.
With that in mind, if you wanted simple, fast and good results, Yadif could have been a good option as it seems to be the default recommendation here for fast and good deinterlacing.

[medp7060]

You are right, Chainmax. I just finish reading all the six pages from here http://forum.doom9.org/showthread.php?t=124284. I tested Yadif(). It is as fast as FieldDeinterlace(). It has been widely suggested. I have no say at the moment, will see if I can make it my first choice for my real interlaced source.
Mpeg2Source("sony.d2v")
Yadif (order=1)

[foxyshadis]

I'd go so far as to say that despite rule 12, Yadif is the best avisynth deinterlacer to start off with all the time. It's about as fast and ranges from at least as good to better than all the other fast ones, plus it works much better than mv/mcbob on messed up sources. Going straight to mcbob is very, very much not recommended in all cases because of strong artifacting.

If you can't recognize a deinterlacer's failings, there were some threads with close-up comparisons, but it really just doesn't matter what you use. Plus I have no idea how you're comparing, but you do need to compare a whole clip at a time, not just one frame.

[scharfis_brain]

yadif itself is pretty fast and stable for general usage.
But tdeint with tmm and nnedi delivers MUCH better quality,
cause it has even more less motion artifacts and a much better interpolation due to nnedi.

[medp7060]

Practically it is not possible to do an eaxct comaprison among the filters around. When pushed to high ends, all look similar. For me, a simple FieldDeinterlace() already works. Now most people recommand Yadif or Yadifmod. The speed and quality are very good for general use.

TDeint+TMM+NNEDI was also mentioned by Chainmax. I have seached and failed to find any good guides on them.

(Edited: The following is NOT TRUE as point out by Didée below)

By the way, the documentation in MCBob.avs says it is not for real interlaced materials!

[Didée]

Going straight to mcbob is very, very much not recommended in all cases because of strong artifacting.
Is this a bug report? (Could be the english area of my brain is asleep, but it sounds like "MCBob = produces always strong artefacts => never use it")


By the way, the documentation in MCBob.avs says it is not for real interlaced materials!
Where did you get THAT from? MCBob is ONLY for "real" interlaced sources! (opposed to telecine, fieldshift, blendedfields, or whatelse)
The versions of MCBob that were put online by me do not contain any such comment. For versions not published by me, I'm not liable.

[medp7060]

I edited my last post to make it correct.

Is this a bug report? (Could be the english area of my brain is asleep, but it sounds like "MCBob = produces always strong artefacts => never use it")


While MCBob still finds its use in somewhere, but it hardly becomes a routine deinterlacer. I bet Yadif is going to be the wiser choice for common users due to its speed and acceptable quality (if not one of the best).

[kumi]

Yadif sure is wonderful, but it is very prone to artifact on fine lines. I asked tritical if he would release his version with "spatially-capped EDI" (I won't pretend to know what that means) that apparently deals with this problem, and he said he would look into it :)

[foxyshadis]

Is this a bug report? (Could be the english area of my brain is asleep, but it sounds like "MCBob = produces always strong artefacts => never use it")

Pulsing light => big patches of wrong color, probably detected as static incorrectly. Tends to only happen on music video or concert dvds, but doesn't trip up tdeint & yadif. Blended fields or low motion => deformed objects, but not serious.

If I can find the scenes that illustrated the first problem I'll post them. The second is probably an inescapable part of mc, isn't too severe a price to pay for extra detail.