Re: [Algorithms] RGB to XYZ conversion
Brought to you by:
vexxed72
Menu
▾
▴
Re: [Algorithms] RGB to XYZ conversion
|
From: Willem H. de B. <wi...@wh...> - 2008-04-24 20:44:40
|
Sam wrote: "I had been expecting interpolation to produce the correct result as it's just a linear operation [...]" Jon wrote: "If you map out the Co Cg as a two dimensional [...]" Hold your horses, it's two different things we're talking about here. Sam is correct to point out that given that the map from RGB to YCoCg space is linear, (bi-)linear interpolation is "preserved" (*) in the sense that it doesn't matter if you linearly interpolate before or after transforming, the result is the same. 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. Cheers, Willem (*) To see this, let c0,c1 be two colours in RGB and y0, y1 be the corresponding colours in YCoCg-space (yi=M*ci). Then t*y0 + (1-t)*y1 = t*M*c0 + (1-t)*M*c1 = M*(t*c0 + (1-t)*c1). Hence linear interpolation is invariant under the mapping M. ----- Original Message ----- From: Jon Olick To: Game Development Algorithms Sent: Thursday, April 24, 2008 5:56 PM Subject: Re: [Algorithms] RGB to XYZ conversion Hi Sam, If you map out the Co Cg as a two dimensional 256x256 texture, you will see that a linear interpolation between different Co and Cg points can sometimes produce variations in color that are undesired, or at least different than interpolating in RGB. This can produce minor visual glitches. You really have to be staring at it to notice it though. We are just writing it off as an acceptable loss for the improved DXT5 compression. Best, Jon On Thu, Apr 24, 2008 at 10:41 AM, Sam Martin <sam...@ge...> wrote: I believe the YCoCg-R version is detailed here: research.microsoft.com/~malvar/papers/JVT-I014r3.pdf I haven't really looked into it though. What sort of errors did you get from bilinear interpolation? I had been expecting interpolation to produce the correct result as it's just a linear operation and doesn't matter if you take linear combinations, ie: If a and b are scalars (your bilinear interpolation values), x any y are colours, and R is the RBG->YUV transform with R' it's inverse: a*x + b*y = R' (a*Rx + b*Ry) = a*R'Rx + b*R'Ry = a*x + b*y However, I fear that I'm missing something ridiculously 'obvious' here and about to make a fool of myself! Cheers, Sam From: gda...@li... [mailto:gda...@li...] On Behalf Of Jon Olick Sent: 24 April 2008 15:50 To: Game Development Algorithms Subject: Re: [Algorithms] RGB to XYZ conversion Hi Sam, I agree, the loss of 1 bit is usually nothing to worry about. Surely we don't here. Just wanted to point it out for correctness. However, I am interested in the variant Simon alluded to which does not require the additional bit. The only artifacts I've seen from using YCoCg as a production format is that when interpolating between different colors the wrong colors can show up in the bilinear interpolation. However, this is usually minor and barely noticeable. Best, Jon Olick On Thu, Apr 24, 2008 at 4:39 AM, Sam Martin <sam...@ge...> wrote: >He missed a few signs: >> [y,Co,Cg]' = [1/4, 1/2, 1/4].[r,g,b]' >> [1/2, 0, -1/2] >> [-1/4, 1/2, -1/4] Yeah, cheers - I was reformatting it from a copied pdf. The signs must have been eaten somewhere in the process. > Out of curiosity, what did you mean by "had any issues with it"? YCoCg > is primarily a replacement for YUV/YCbCr that allows cheaper (and > lossless) transforms between the two colour spaces and typically does a > good job of extracting the correlation in the RGB. If you want to use it > for image compression, then it's a good first step. As other people have commented, I'm also not bothered by the 1-bit 'lossy' precision aspect. That's well below the radar :) I'm actually interested in how this luminance+chroma variant stands up against its equivalents from an art and data 'reduction' point of view. Can you sensibly work as an artist in YCoCg space? How well does it represent the rgb correlation in comparison to its alternatives? I suspect a fair amount of effort went into defining the balance of luminance/chroma in other variants of this and (at least on the surface) YCoCg appears to just throw all that away! Cheers, Sam ------------------------------------------------------------------------- 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 ------------------------------------------------------------------------- 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 ------------------------------------------------------------------------- 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 |
