[vdr] Re: ANNOUNCE: OSD Picture-in-Picture (vdr-osdpip-0.0.2)

[Reinhard Nissl <rnissl@gmx.de>]

Hi,

Sascha Volkenandt wrote:

> > As my xine plugin doesn't have the OSD memory limitation, I wanted to patch
> > your plugin. But I didn't find the location, where this is handled.
> >
> > Or am I totally wrong about that and there is a different reason, why the
> > quality decreases so much for an uncropped (0, 0, 0, 0) osdpip at scale 3x?
> >
> > 	http://home.vr-web.de/~rnissl/osdpip2x.png
> > 	http://home.vr-web.de/~rnissl/osdpip3x.png
> Looks like something with the palette. I guess there is another color used for 
> transparent or background if the scaled picture doesn't fit the window 
> completely. I have some ongoing changes in that area anyways...
I don't understand what you were going to explain :-(

> BTW the location you mentioned, what do you mean exactly? Where the conversion 
> is done? Where the depth is set? I could imaging XINE could also display the 
> original truecolor image instead of the 8-bit dithered version (well to 
> achieve that, VDR's palette handling would have to be changed)
No. Each of xine's OSD objects (i. e. each VDR window) can have a 256 color 
palette. Currently, there is no OSD API in xine that could handle true color 
images. Only a post-processing plugin could achieve that.

Yesterday, I only found places, where the colordepth (4 or 8) is only 
depending on grayscale respectively color mode. As the quality decreases with 
the size of the image, I was looking for a dependency on size, but didn't find 
one. That's why I asked.

So it seems, that this is a dither issue of libmpeg2. What do you think about 
that?

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@gmx.de




--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.