[MPlayer-dev-eng] new deinterlace filters

[D Richard Felker III]

On Thu, Jan 23, 2003 at 06:22:12PM +0100, Michael Niedermayer wrote:
> > although I haven't waded through all the papers yet, I imagine it's a
> > good bit more elaborate and cpu-intensive than what's needed for
> > deinterlacing (since it can fill in much larger gaps). Perhaps a
> > bilinear or bicubic filter would be sufficient. I suppose I could do
> > some simple tests by scaling down to half height with nearest neighbor
> > then scaling back up with the various software scalers and see which
> > (if any) fill in the missing lines well.
> this wont look any better then the cubic or linear deinterlace filters as its 
> identical, bilinear & bicubic ipol suck at sharp lines ->they get blurred, 

Well it's not so much the blurring that's the problem... Rather, when
they have low slope they get segmented looking -- bogus gradients
appear in the line going back between light and dark.

> thats why i posted the url, the stuff described there shouldnt blur lines, 
> allthough it might be too slow for practical use, dunno

Hmm. Actually, I was looking a bit at the 2xSaI code to see if it
could be adapted for primitive, fast inpainting (right now it seems
useless for movies because it checks equality instead of similarity of
pixels), but it's painful to read. Something like that could work
well, though...

> > (BTW, this is yet another reason it would be nice to have -sws be
> > configurable per-instance. In the mean time I might just make a video
> > filter that doubles all strides...)
> per instance -sws is planned (since a long time) ...

Yeah... If you have in mind a good syntax for it, I'd be happy to
implement it. Perhaps we should wait til after 0.90 though.

> > Yeah, I read the postproc code for the first time yesterday when I
> > went to see how the median deinterlacer worked (and found that the C
> > code was missing so I implemented it), and I like the design a lot.
> > The advantage of interleaving filters like this should be huge. Also I
> > figured it might be nice to keep all the deinterlacers together in
> > postproc so they could be used in other projects, but maybe it's
> > simpler just to make a separate filter. I don't want to go polluting
> > libpostproc with nonsense.
> more filters are not nonsense :)

OK. :)

Rich