- It's very clever and fast, but it doesn't work well on anything other than 90 and 45 degree angles.
- Thin lines get mangled pretty badly.
- It only looks at a 4x3 block of pixels.
- And it only averages together two of those pixels to find its spatial guess.
With decomb I tried to improve things slightly (whether I actually did is arguable) by switching to cubic interpolation, which considers more pixels when it guesses. I still used the same edge detection, with all its flaws, but pushed out a bit further along those vectors to get more samples.
This helped a little, but there are still lots of jaggies.
Yadid has two parts: a spatial filter and a temporal filter.
The spatial filter -- the part that isn't so great -- looks at the current field and tries to guess the missing one. This gives it a spatial prediction for what its output should be.
Then the temporal filter kicks in, and adjusts that spatial prediction if it thinks it's found a better match in the previous or next field. That part's cool. It's like a poor man's motion compensation.
The geniuses in the AviSynth community figure out a solution -- tritical made yadifmod, a version of yadif that cuts out the spatial prediction and lets you insert another one of your liking.
One of the most popular spatial interpolators to use with yadifmod (or any other AviSynth deinterlacer, particularly tritical's TDeint) is EEDI2, also by tritical. See: http://forum.doom9.org/showthread.php?p ... post744308
EEDI2's niftiness comes from its hard-core approach to the problem. It doesn't just look at a 4x3 window, it gets down to some serious filtering.
It runs an edge detector with a much wider search window than yadif's over the whole field, generating a full resolution bitmap of edging. Then it filters that, with erosion and dilatiion and expansion filters until it's removed the noise and enhanced all the distinct areas of edging. It follows this up with a direction map, that encodes basic spatial vectors for all those edges, to know the directions to interpolate along. Then it upscales all these maps, and refilters them until they're smooth again, and only then does it actually decide which pixels to interpolate from when filling in all the missing lines in the actual image.
It is awesome.
I've shoehorned EEDI2 into decomb.c. When decomb detects a combed frame it wants to filter with yadif, it builds the eedi2 interpolation, and then shunts it to yadif_filter_line to replace its internal spatial_pred.
Patch: http://handbrake.fr/pastebin/pastebin.php?show=344
There is still a lot of work to be done.
- Tritical writes his code for himself. That is, he mostly deals with people using his compiled library, and not other developers hacking on his code. So maintainability and comments and descriptive variable names and white space aren't big priorities for him. They are for me, though, so now that I've got it working I'm going to give the code a serious facelift so people (read: I) can grok what it's doing.
- EEDI2 offers a number of options, but for now I'm just hard coding all of them to the default values.
- The plane copy function is just C, and could definitely be sped up with some assembly on SSE chips.
- For some reason it won't work with DV sources, it's like the stride is wrong; I don't understand why since with r1867 van started to convert them to yuv420, before they hit the filters. EDIT: Van has informed me that this is because DV is BFF. Reversing the tff setting in decomb makes it work great.
- There is a second level of post processing I haven't ported yet, since it's off by default.
- And it'd probably be worth investigating a third set of threads for decomb, to run EEDI2 on all planes simulatneously.
I don't have really great example images yet, but here's a very preliminary test shot I did. This don't demonstrate how the filter will work in regular use. Rather, to test how EEDI2 looked, I set decomb to build EEDI2 interpolations for all frames and passed those through as the output, without including the yadif temporal adjustments. This is what EEDI2 can reconstruct from half the fields of a progressive frame, versus what running --deinterlace="slower" (yadif) would do to it. Also, this doesn't include eedi2's post processing, only its raw (pp=0) interpolation.
original:

yadif:

eedi2:
