[theora] YCbCr <-> RGB conversion question

[Ondrej Certik]

On Mon, Jun 15, 2009 at 8:25 PM, Conrad Parker<conrad at metadecks.org> wrote:
> 2009/6/16 Ondrej Certik <ondrej at certik.cz>:
>> Hi,
>>
>> I coded some routines for YCbCr <-> RGB conversion, both using
>> floating point numbers and using integer arithmetics, code is
>> attached.
>>
>> Let's say I want to convert from RGB to YCbCr and back. First the
>> integer arithmetics:
>>
>> In [1]: from colors import *
>>
>> In [2]: a = [255, 0, 255]
>>
>> In [3]: RGB2YCbCr(a)
>> Out[3]: (107, 202, 222)
>>
>> In [4]: YCbCr2RGB(RGB2YCbCr(a))
>> Out[4]: array([255,   1, 255])
>>
>>
>> As you can see, the G component was increased from 0 to 1. Those
>> routines are the same as here:
>>
>> http://msdn.microsoft.com/en-us/library/ms893078.aspx
>>
>> Now let's try floating point conversions:
>>
>> In [3]: RGB2YCbCr_precise(a)
>> Out[3]: array([106, 202, 222], dtype=uint8)
>>
>> In [4]: YCbCr2RGB_precise(RGB2YCbCr_precise(a))
>> Out[4]: array([255,   0, 254], dtype=uint8)
>>
>> This time the B component was decreased by 1... Those floating point
>> routines were done by me, and I followed the theora spec.
>>
>> So my questions are:
>>
>> * does anyone here have a code, that can convert back and forth
>> without loosing precision?
>> * does it make sense for those routines to work back and forth exactly?
>>
>> I am new to this, so I am not sure what the common practise is, but it
>> seems weird to me, that if I convert the picture from YCbCr to RGB and
>> back couple times, the image will slowly deteriorate.
>
> Have you compared to the code in liboggplay?

I looked now -- I only found YUV -> RGB conversion, is there the other way too?

>
> (speaking of which, python bindings to liboggplay would be elite --
> that would add audio, sync and seeking support :-)

We'll see. :)



On Tue, Jun 16, 2009 at 7:26 AM, dos386<dos386 at gmail.com> wrote:
>> does anyone here have a code, that can convert back and
>> forth without loosing precision?
>> does it make sense for those routines to work back and forth exactly?
>
> AFAIK impossible.

Right, I also think it's impossible, because when you have an image in
RGB and convert to YCbCr, one gets floating point numbers, and once I
round it, I am already loosing precision. Then, when I convert back, I
have to round again, and I loose precision again, which sometimes
amounts to the difference by 1.

The only workaround seems to me to use lookup tables, or figure out
some better conversion, maybe run tests to find triples RGB for which
it is known to produce different results and put just those into a
lookup table, or something.
But I think I'll just leave this as it is for now.

Ondrej