theora dev - Nov 2007 - yuv - rgb conversion without contrast decrease.

Hello list,

When I convert an yuv pixel into rgb using the recipies in
http://www.fourcc.org/fccyvrgb.php I get an accurate color conversion
but the contrast seems to be decreased. If i write, e.g., the pixel
directly into an sdl yuv_overlay, I get a well-contrasted frame,
however, if I convert the pixel to rgb and call SDL_MapRGB, I get a
contrast-decreased frame.

Thanks,
Ribamar

On Tue, Nov 20, 2007 at 02:32:58PM -0200, Ribamar Santarosa de Sousa wrote:
> When I convert an yuv pixel into rgb using the recipies in
> http://www.fourcc.org/fccyvrgb.php I get an accurate color conversion
> but the contrast seems to be decreased. If i write, e.g., the pixel
> directly into an sdl yuv_overlay, I get a well-contrasted frame,
> however, if I convert the pixel to rgb and call SDL_MapRGB, I get a
> contrast-decreased frame.
This is complicated. Could be gamma, could be the reduced dynamic range 
of broadcast oriented colorspaces. There's a chapter in the spec which 
explains how to convert the two calibrated colorspaces; you might check 
if either of them reduce to any of the recipies you found. Of course, 
most video is encoded without a specific colorspace marked, so you're 
"free" to do whatever looks good.

There's also yuv2rgb code in liboggplay you can look at.

 -r

2007/11/20, Ribamar Santarosa de Sousa
<ribamar.santarosa@gmail.com>:
> When I convert an yuv pixel into rgb using the recipies in
> http://www.fourcc.org/fccyvrgb.php I get an accurate color conversion
> but the contrast seems to be decreased.
I'm not sure, but maybe this is related to the fact that there are two
similar but incompatible YUV formats: the first is used mostly for
JPEG images and uses the full 0-255 range for each component, while
the second one (commonly used for video, including Theora) has smaller
valid ranges (16-235 for Y and 16-240 for U and V).

Slightly increased or decreased contrast is often a symptom of passing
an image in one of the two formats to a library that expect the other
one, without proper conversion.

-- 
Lino Mastrodomenico
E-mail: l.mastrodomenico@gmail.com

Hi,

I've run into an interesting problem in the "player_example" on a
PowerPC system.  It manifests as a pattern of "dots" on part of the
screen at the beginning of a video... they are somewhat coordinated with
the image and are regularly spaced.  I've included an example frame.

Interestingly, they are not present on the output of the "dump_video"
example program running on the same system.  This gave me something to
work with and I was able to isolate the problem a bit... one difference
between the player_example code and the dump_video code is that the
dump_video program does not modify the "PPLEVEL" with
"theora_control".
If I comment out all the "theora_control(&td, TH_DECCTL_SET_PPLEVEL,
&pp_level, sizeof(pp_level))" like calls then I do not see the
artifact.

I'm running the libtheora-1.0beta2 release.

I'm cross-compiling on a x86 CentOS 4.5 Linux system using a GCC 3.4.4
based compiler.

I've attached a screen shot showing the artifact.

Any ideas?

-- Jim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.png
Type: image/png
Size: 131855 bytes
Desc: bug.png
Url :
http://lists.xiph.org/pipermail/theora-dev/attachments/20071219/a851802b/bug-0001.png

Mayer, Jim wrote:
> Any ideas?
Could you try hard-coding pp_level_max to the values between 2 and 7
(replace the TH_DECCTL_GET_PPLEVEL_MAX call to retrieve it from the
library), and let me know the first one which exhibits the problem? That
should narrow down the code in question to one or two functions.

And before you try the previous suggestion, see if the attached patch
fixes the problem (also now in svn with some additional simplifications
of the code).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.patch
Type: text/x-patch
Size: 1085 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/theora-dev/attachments/20071222/4bd162af/bug.bin