[MPlayer-dev-eng] new deinterlace filters

[Michael Niedermayer]

Hi

On Thursday 23 January 2003 17:15, D Richard Felker III wrote:
[...]
> > > So, presumably the solution is to do some sort of fancier
> > > interpolation with the surrounding pixels to the left and right. And
> > > here's where we get to the questions... Do you have any ideas or
> > > recommendations on good 2d interpolation algorithms that should be
> > > used here?
> >
> > hmm, yes, see: http://mountains.ece.umn.edu/~guille/inpainting.htm
> > the algorithms on the papars there can replace missing image regions, and
> > it looks quite impressive even for large regions, so i guess it should be
> > real nice if it has to replace only every 2nd line
>
> Hmm, I believe I've had this url thrown at me a few times before, and
yes

> 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, 
thats why i posted the url, the stuff described there shouldnt blur lines, 
allthough it might be too slow for practical use, dunno

>
> (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, 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 :)

[...]

Michael