Re: [Algorithms] RGB to XYZ conversion

[Sam M. <sam...@ge...>]

I thought for a moment there could be something to do with the range of
the output. I don't think there is, but I've done it now and thought I'd
point this out anyway in case it's helpful:

If your RBG colour components are in the range 0-1 then the YCoCg output
is actually signed:
Y = [0 .. 1]
Co = Cg = [-1/2 .. 1/2]

So if you want to store this in an unsigned 0-1 range texture you need
to shift the CoCg values up, which you can do by adding a 'translation'
colour vector to the YCoCg colours: t = {0,1/2,1/2}. So your transform
is actually (Rx + t) and your inverse is R'(c - t). 

Will this work? Well:

(Setting the rbg interp equal to what happens when you are interpolating
YCoCg with the translation vector)
a*x + b*x = R'(a(Rx + t) + b(Ry + t) - t)

(expanding out the brackets)
  	    = R'(a*Rx + a*t + b*Ry + b*t - t)

(regrouping to separate the t's)
	    = R'(a*Rx + b*Ry) + R'(a*t + b*t - t)
	    = R'(a*Rx + b*Ry) + R'((a+b)*t - t)
	    = a*R'Rx + b*R'Ry + R'((a+b)*t - t)
	    = a*x + b*y       + R'((a+b)*t - t)

So we have the first bit and this extra term involving t's. Now, as long
as a+b = 1 (which they do when you are doing an interpolation), or you
subtract a t appropriately scaled, then the t's will cancel and the
equality will be valid. 

In a nutshell I guess I'm really just demonstrating that anything that's
a linear op will work. Although again, I could have ballsed this up
somewhere :)

Cheers,
Sam



From: gda...@li...
[mailto:gda...@li...] On Behalf Of
Jon Olick
Sent: 25 April 2008 15:39
To: Game Development Algorithms
Subject: Re: [Algorithms] RGB to XYZ conversion

Hi Jon,

So, thats interesting then that the bilinear interpolation of RGB colors
have artifacts. As soon as I get a chance I'll take a closer look at our
assets and both in straight up RGB and DXT5 to verify. After reading
your e-mail, I went over to Jan Pal (our local YCoCg expert) to ask him
about this very interpolation problem and he swears that the
interpolation in YCoCg is not the same as interpolation in RGB. We were
looking at this about 6 months ago now, but we very well could have made
a mistake.

Best,
Jon Olick
On Thu, Apr 24, 2008 at 4:54 PM, Jon Watte <hp...@mi...>
wrote:
Willem H. de Boer wrote:
> But, this doesn't take away from the fact that the interpolation
> can choose colours in between (i.e. for t in [0,1]) that are
> in some ways 'wrong' or at least counterintuitive to what
> we would expect - which is what Jon points out. This is
> a result of the way YCoCg maps out in colour space.
>
Note: that "Jon" was a different Jon than me :-)

It actually does mean that all the interpolated colors will be the same,
because for _any_ "a" and "b" (interpolation values, equal to t and
1-t), a*x + b*y equals R'(aRx +bRy), through mathematic equality. So,
no, there would not be interpolation artifacts based on the math being
in a different space. This is because the two spaces are linearly
equivalent. You don't get interpolation differences until you go to a
non-equivalent space, such as HSV, or a space with a different gamma.

The interpolation of DXT compression, though, is somewhat quantized, and
will generally result in a slight green/purple banding in RGB. That
quantization may cause a different color banding effect in the Y Co Cg
space, because quantization is not a linearly independent operation.

Sincerely,

jw


------------------------------------------------------------------------
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
avaone
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t