Re: [Algorithms] RGB to XYZ conversion

[Adrian B. <ad...@gm...>]

"anything that's a linear op will work."

Your assertion about a+b=1 implies you meant affine op.  Now _that's_
a technicality :-).

On Fri, Apr 25, 2008 at 8:57 AM, Sam Martin <sam...@ge...> wrote:
> 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
>
>
>  -------------------------------------------------------------------------
>  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/javaone
>  _______________________________________________
>  GDAlgorithms-list mailing list
>  GDA...@li...
>  https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>  Archives:
>  http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>