Re: annoying E effects on horizontally moving items

[Matthias Oelmann <moelmann@ixl.com>]

Hi, 

I'm currently working on that problem - the code is not finished yet
though.
De-Interlacing is quite a complex issue if you want to do it right.
The easiest way is to do an interpolation between the lines of 
one field (halfpicture) to get twice as many lines (linedoubling). that
looks
a little better than what we see now, but is far from perfect.

the point is: if you have still pictures or a video that was taken from
film (at least in PAL...) you can just combine the two fields of one
frame
(weaving). For normal video, the 2 fields are 1/50th of a second apart.
If you want to do it right, you weave those parts of the image where
there
is no motion and interpolate the parts with motion...

thats the goal at least. I will post my code as soon as it is working.

> Is it possible to introduce such an algorithm, or would it cost to much CPU or
> maybe just don't fit into the hardware architecture or so?

it's definitely possible if mpeg decoding is done in hardware.
(or you have a plain bt848 video card)

.mao 





Schuett Thomas wrote:
> 
> Hello,
> 
> I had an idea about how to get rid of
> the anoying E effects on horizontally moving items:
> 
> on a-halfpicture do:
>   - write an interpolation between previously stored a-halfpicture
>     and recent a-halfpicture to a-lines on graphics card
>   - store recent a-halfpicture for later use
>   - write b-halfpicture (was previously stored) to b-lines on graphics card
> 
> on b-halfpicture do:
>   - write an interpolation between previously stored b-halfpicture
>     and recent b-halfpicture to b-lines on graphics card
>   - store recent b-halfpicture for later use
>   - write a-halfpicture (was previously stored) to a-lines on graphics card
> 
> => Each halfpicture would be changed all 1/50 sec. (not only all 1/25).
> 
> => On still pictures, an interpolation between previous a-halfpicture with
>      recent a-halfpicture would be the same as recent and the same as
>      previous a-halfpicture. (same true for b-halfpicture).
>      So still pictures would look exactly the same as without this algorithm.
> 
> Is it possible to introduce such an algorithm, or would it cost to much CPU or
> maybe just don't fit into the hardware architecture or so?
> 
> cu,
>   Thomas