Re: [Algorithms] RGB to XYZ conversion
Brought to you by:
vexxed72
From: Sam M. <sam...@ge...> - 2008-04-24 15:42:44
|
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 |