[MPlayer-dev-eng] design for motion-adaptive deinterlacer

[Arpi]

Hi,

> > > I've been thinking about writing a good motion-adaptive deinterlacer,
> > > since they all seem to suck. So I'm sending a few ideas to the list
> > 
> > hmm, my favourite topic :)
> 
> :)
> 
> > btw, it should be a combined temporal denoise & deinterlace filter.
> 
> Hmm, you mean apply strong temporal denoise to areas with no motion,
> and none to other areas to avoid ghost artifacts? IMO it's a pretty

no.
it's teh current result-effect of denoise3d/hqdn3d filters.
the goal would be doing ME and then MC of back-frame and do
temporal filtering afterwards. So it will filter moving objects
properly, without causing ghost effects.
Current temporal filters either do not filter moving parts, or
cause ugly ghosting. None of them can filter moving parts properly.

I know that temp. filtering and deinterlace are 2 different topics,
but they could share some code, ie. motion detection, estimation,
compensation...  also the combing detection part could work better
using filtered image (less noise).

> good idea, but temporal denoise can still cause strange fixed textures
> to appear in animation (where you have large regions of almost solid
> color) that don't move when the object moves... :( Any idea how to

it doesnt matter. if they look stable, they will be filtered as
being stable. so the result will be solid noiseless zone.

> work around that? IMO it requires identifying the whole "object" as
> moving rather than just the parts that change at the edges (this
> happens naturally in live action but not so well in animation).

you mean the edge of objects?
hqdn3d/denoise3d fliters do adaptive filtering, ie. doesnt touch
high-contrast pixels, to avoid blurring the edges.

> > > 1. Identify areas of motion.
> > > 
> > > Using a simple difference threshold pixel-by-pixel is no good. If the
> > > threshold is too low you'll get tons of motion from temporal noise,
> > > while if it's too high, you'll miss slow changes in the low frequency
> > > components which cause very ugly noticable combing (think of gradual
> > > change in light level).
> > 
> > I've made some weighted group of pixels, in my g2 filter "madei"
> > (see video/vf_madei.c).
> 
> Yeah, I remember that, but for some reason I never actually tried it.
> I'll take a look.

it was inspired by some hardware, called GrandTec ViewTV, an external
tv tuner & pal/vga converter designed to use with high-resolution monitors.
(i'm using a 21" EIZO monitor for tv watching, at 720x576x150hz or 1024x768x75hz)
this device has builtin motion-adaptive (and imho even motion compensating?)
deinterlacing. at leats it can do smooth scrolls in CNN and such news-bar
sites, without decreasing image resolution (ie. no blending fields).

(the suprise is that this device is too cheap (~80$) to do something big
magic with heavy dsp and so, like done in 10000$ broadcast-level
deinterlacers)


A'rpi / MPlayer, Astral & ESP-team

--
PyMaViS - my answer to worm storm - http://mplayerhq.hu/~arpi/pymavis/