Thread: [Algorithms] RGB to XYZ conversion
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Dan G. <dan...@gm...> - 2008-04-21 04:55:13
|
Dear colour space experts What matrix should I being using to convert RGB values to CIE XYZ? Christer Ericson (http://realtimecollisiondetection.net/blog/?p=15) gives the following matrix: M = [0.497,0.339,0.164] [0.256,0.678,0.066] [0.023,0.113,0.864] to be used in [X Y Z] = [R G B]*M and I assume this comes from Greg Ward's paper. Charles Poynton's ColorFAQ and wikipedia's article on CIE 1931 give different formulations for the conversion. Bruce Lindbloom's site (http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html) gives more than a dozen different conversion matrices, one of which is labelled "sRGB" and leads me to believe this should be used for images authored to sRGB. My question to people more knowledgeable than I: Which of the conversions should I be using? thanks DanG -- Dan Glastonbury, Dan dot Glastonbury at gmail dot com `Pour encourjay lays ortras' |
|
From: Jon O. <jon...@gm...> - 2008-04-21 06:02:04
|
Hi Dan, This website has a good list of color space conversions. http://www.easyrgb.com/math.html Enjoy! Best, Jon Olick On Sun, Apr 20, 2008 at 11:54 PM, Dan Glastonbury <dan...@gm...> wrote: > Dear colour space experts > What matrix should I being using to convert RGB values to CIE XYZ? > Christer Ericson (http://realtimecollisiondetection.net/blog/?p=15) > gives the following matrix: > > M = [0.497,0.339,0.164] > [0.256,0.678,0.066] > [0.023,0.113,0.864] > > to be used in [X Y Z] = [R G B]*M and I assume this comes from Greg > Ward's paper. Charles Poynton's ColorFAQ and wikipedia's article on > CIE 1931 give different formulations for the conversion. > > Bruce Lindbloom's site > (http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html) > gives more than a dozen different conversion matrices, one of which is > labelled "sRGB" and leads me to believe this should be used for images > authored to sRGB. > > My question to people more knowledgeable than I: Which of the > conversions should I be using? > > thanks > DanG > > -- > Dan Glastonbury, Dan dot Glastonbury at gmail dot com > `Pour encourjay lays ortras' > > ------------------------------------------------------------------------- > 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 > |
|
From: Dan G. <dan...@gm...> - 2008-04-21 06:25:55
|
On Mon, Apr 21, 2008 at 4:02 PM, Jon Olick <jon...@gm...> wrote: > This website has a good list of color space conversions. > > http://www.easyrgb.com/math.html Hi Jon, I've seen this site before during my web travels. They list the sRGB with a white point of D65 conversion for RGB->XYZ and from further reading on the web (http://en.wikipedia.org/wiki/D65), D65 looks to be the choice when calculating conversion matrices. thanks DanG -- Dan Glastonbury, Dan dot Glastonbury at gmail dot com `Pour encourjay lays ortras' |
|
From: Wolfgang E. <wol...@gm...> - 2008-04-21 16:12:00
|
Other than this, this is a nice way to change the look of the game ;-) -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Dan Glastonbury Sent: Sunday, April 20, 2008 11:26 PM To: Game Development Algorithms Subject: Re: [Algorithms] RGB to XYZ conversion On Mon, Apr 21, 2008 at 4:02 PM, Jon Olick <jon...@gm...> wrote: > This website has a good list of color space conversions. > > http://www.easyrgb.com/math.html Hi Jon, I've seen this site before during my web travels. They list the sRGB with a white point of D65 conversion for RGB->XYZ and from further reading on the web (http://en.wikipedia.org/wiki/D65), D65 looks to be the choice when calculating conversion matrices. thanks DanG -- Dan Glastonbury, Dan dot Glastonbury at gmail dot com `Pour encourjay lays ortras' ------------------------------------------------------------------------- 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/javao ne _______________________________________________ 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 |
|
From: <chr...@pl...> - 2008-04-21 17:04:36
|
Dan Glastonbury wrote: > Dear colour space experts > What matrix should I being using to convert RGB values to CIE XYZ? > Christer Ericson (http://realtimecollisiondetection.net/blog/?p=15) > gives the following matrix: > > M = [0.497,0.339,0.164] > [0.256,0.678,0.066] > [0.023,0.113,0.864] > > to be used in [X Y Z] = [R G B]*M and I assume this comes from Greg > Ward's paper. Charles Poynton's ColorFAQ and wikipedia's article on > CIE 1931 give different formulations for the conversion. Good question Dan, and I for one don't know the answer. I asked myself the same question when I wrote that blog post and first worked out the code. Everywhere you look, there's another subtly different matrix given. As we didn't end up using any logluv encodings, I never tried to find out what's the "correct" matrix. As you correctly assumed, I just used the values given in Greg Ward's paper for the blog post. Christer Ericson, Director of Tools and Technology Sony Computer Entertainment, Santa Monica http://realtimecollisiondetection.net/blog/ |
|
From: Wolfgang E. <wol...@gm...> - 2008-04-21 17:24:57
|
I used this for PostFX. The equation I use is different from yours. The color values that go in there are already gamma 1.0. I posted my numbers on my blog Diaryofagraphicsprogrammer.blogspot.com I can't remember how I came up with them but it was probably not a scientific way. Sent from my iPhone On Apr 21, 2008, at 10:04 AM, chr...@pl... wrote: > > Dan Glastonbury wrote: >> Dear colour space experts >> What matrix should I being using to convert RGB values to CIE XYZ? >> Christer Ericson (http://realtimecollisiondetection.net/blog/?p=15) >> gives the following matrix: >> >> M = [0.497,0.339,0.164] >> [0.256,0.678,0.066] >> [0.023,0.113,0.864] >> >> to be used in [X Y Z] = [R G B]*M and I assume this comes from Greg >> Ward's paper. Charles Poynton's ColorFAQ and wikipedia's article on >> CIE 1931 give different formulations for the conversion. > > Good question Dan, and I for one don't know the answer. I asked myself > the same question when I wrote that blog post and first worked out the > code. Everywhere you look, there's another subtly different matrix > given. As we didn't end up using any logluv encodings, I never tried > to find out what's the "correct" matrix. As you correctly assumed, I > just used the values given in Greg Ward's paper for the blog post. > > > Christer Ericson, Director of Tools and Technology > Sony Computer Entertainment, Santa Monica > http://realtimecollisiondetection.net/blog/ > > > --- > ---------------------------------------------------------------------- > 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 |
|
From: Marco S. <mar...@gm...> - 2008-04-21 17:34:33
|
Umh..interesting, why did you use CIE XYZ for your post processing pipeline? Regarding the original question: small variations in the colour transform don't really make any significant difference if you are using CIE XYZ just to store your data in a different way (ie HDR data in 4 bytes per pixel or less), as you have to go back to RGB to display your image anyway. While working on Heavenly Sword I played with slightly different matrices and even artists couldn't notice any difference. Marco On Mon, Apr 21, 2008 at 10:24 AM, Wolfgang Engel <wol...@gm...> wrote: > I used this for PostFX. The equation I use is different from yours. > The color values that go in there are already gamma 1.0. > I posted my numbers on my blog > > Diaryofagraphicsprogrammer.blogspot.com > > I can't remember how I came up with them but it was probably not a > scientific way. > > Sent from my iPhone > > On Apr 21, 2008, at 10:04 AM, chr...@pl... > wrote: > > > > > Dan Glastonbury wrote: > >> Dear colour space experts > >> What matrix should I being using to convert RGB values to CIE XYZ? > >> Christer Ericson (http://realtimecollisiondetection.net/blog/?p=15) > >> gives the following matrix: > >> > >> M = [0.497,0.339,0.164] > >> [0.256,0.678,0.066] > >> [0.023,0.113,0.864] > >> > >> to be used in [X Y Z] = [R G B]*M and I assume this comes from Greg > >> Ward's paper. Charles Poynton's ColorFAQ and wikipedia's article on > >> CIE 1931 give different formulations for the conversion. > > > > Good question Dan, and I for one don't know the answer. I asked myself > > the same question when I wrote that blog post and first worked out the > > code. Everywhere you look, there's another subtly different matrix > > given. As we didn't end up using any logluv encodings, I never tried > > to find out what's the "correct" matrix. As you correctly assumed, I > > just used the values given in Greg Ward's paper for the blog post. > > > > > > Christer Ericson, Director of Tools and Technology > > Sony Computer Entertainment, Santa Monica > > http://realtimecollisiondetection.net/blog/ > > > > > > --- > > ---------------------------------------------------------------------- > > 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 > |
|
From: Wolfgang E. <wol...@gm...> - 2008-04-21 18:03:45
|
The luminance transform for the tone mapper. With those numbers I can transform back and forth without visible quality loss on my hardware platform ... I can switch on and off the tone mapper and I would not see a difference with neutral tuning values. That is important for the artists as a starting point. Sent from my iPhone On Apr 21, 2008, at 10:34 AM, "Marco Salvi" <mar...@gm...> wrote: > Umh..interesting, why did you use CIE XYZ for your post processing > pipeline? > > Regarding the original question: small variations in the colour > transform don't really make any significant difference > if you are using CIE XYZ just to store your data in a different way > (ie HDR data in 4 bytes per pixel or less), > as you have to go back to RGB to display your image anyway. > > While working on Heavenly Sword I played with slightly different > matrices and even artists > couldn't notice any difference. > > Marco > > On Mon, Apr 21, 2008 at 10:24 AM, Wolfgang Engel <wol...@gm... > > wrote: > I used this for PostFX. The equation I use is different from yours. > The color values that go in there are already gamma 1.0. > I posted my numbers on my blog > > Diaryofagraphicsprogrammer.blogspot.com > > I can't remember how I came up with them but it was probably not a > scientific way. > > Sent from my iPhone > > On Apr 21, 2008, at 10:04 AM, chr...@pl... > wrote: > > > > > Dan Glastonbury wrote: > >> Dear colour space experts > >> What matrix should I being using to convert RGB values to CIE XYZ? > >> Christer Ericson (http://realtimecollisiondetection.net/blog/?p=15) > >> gives the following matrix: > >> > >> M = [0.497,0.339,0.164] > >> [0.256,0.678,0.066] > >> [0.023,0.113,0.864] > >> > >> to be used in [X Y Z] = [R G B]*M and I assume this comes from Greg > >> Ward's paper. Charles Poynton's ColorFAQ and wikipedia's article > on > >> CIE 1931 give different formulations for the conversion. > > > > Good question Dan, and I for one don't know the answer. I asked > myself > > the same question when I wrote that blog post and first worked out > the > > code. Everywhere you look, there's another subtly different matrix > > given. As we didn't end up using any logluv encodings, I never tried > > to find out what's the "correct" matrix. As you correctly assumed, I > > just used the values given in Greg Ward's paper for the blog post. > > > > > > Christer Ericson, Director of Tools and Technology > > Sony Computer Entertainment, Santa Monica > > http://realtimecollisiondetection.net/blog/ > > > > > > --- > > > ---------------------------------------------------------------------- > > 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 |
|
From: Sam M. <sam...@ge...> - 2008-04-23 08:10:03
|
Out of interest, did you try exposing the YCoCg colour space to your artists at all? It's nice and simple, but I'm wondering if anyone has had any issues with it in practice?
<snipped from the first hit in google:>
We recall from [1] that the direct YCoCg color space transform is defined by:
[y,Co,Cg]' = [1/4, 1/2, 1/4].[r,g,b]'
[1/2, 0, 1/2]
[1/4, 1/2, 1/4]
and the inverse YCoCg color space transform is:
[1, 1, 1]
[1, 0, 1]
[1, 1, 1]
</snip>
Cheers,
Sam
From: gda...@li... [mailto:gda...@li...] On Behalf Of Marco Salvi
Sent: 21 April 2008 18:35
To: Game Development Algorithms
Subject: Re: [Algorithms] RGB to XYZ conversion
Umh..interesting, why did you use CIE XYZ for your post processing pipeline?
Regarding the original question: small variations in the colour transform don't really make any significant difference
if you are using CIE XYZ just to store your data in a different way (ie HDR data in 4 bytes per pixel or less),
as you have to go back to RGB to display your image anyway.
While working on Heavenly Sword I played with slightly different matrices and even artists
couldn't notice any difference.
Marco
On Mon, Apr 21, 2008 at 10:24 AM, Wolfgang Engel <wol...@gm...> wrote:
I used this for PostFX. The equation I use is different from yours.
The color values that go in there are already gamma 1.0.
I posted my numbers on my blog
Diaryofagraphicsprogrammer.blogspot.com
I can't remember how I came up with them but it was probably not a
scientific way.
Sent from my iPhone
On Apr 21, 2008, at 10:04 AM, chr...@pl...
wrote:
>
> Dan Glastonbury wrote:
>> Dear colour space experts
>> What matrix should I being using to convert RGB values to CIE XYZ?
>> Christer Ericson (http://realtimecollisiondetection.net/blog/?p=15)
>> gives the following matrix:
>>
>> M = [0.497,0.339,0.164]
>> [0.256,0.678,0.066]
>> [0.023,0.113,0.864]
>>
>> to be used in [X Y Z] = [R G B]*M and I assume this comes from Greg
>> Ward's paper. Charles Poynton's ColorFAQ and wikipedia's article on
>> CIE 1931 give different formulations for the conversion.
>
> Good question Dan, and I for one don't know the answer. I asked myself
> the same question when I wrote that blog post and first worked out the
> code. Everywhere you look, there's another subtly different matrix
> given. As we didn't end up using any logluv encodings, I never tried
> to find out what's the "correct" matrix. As you correctly assumed, I
> just used the values given in Greg Ward's paper for the blog post.
>
>
> Christer Ericson, Director of Tools and Technology
> Sony Computer Entertainment, Santa Monica
> http://realtimecollisiondetection.net/blog/
>
>
> ---
> ----------------------------------------------------------------------
> 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
|
|
From: Simon F. <sim...@po...> - 2008-04-23 10:14:06
|
Sam Martin wrote: > Out of interest, did you try exposing the YCoCg colour space to your > artists at all? It's nice and simple, but I'm wondering if anyone has > had any issues with it in practice? > 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. Simon |
|
From: Jon O. <jon...@gm...> - 2008-04-23 14:49:55
|
Hi Simon, YCoCg is not lossless. You need an extra bit in order to be lossless which is called YCoCg-R. Also, when using DXT texture compression, putting the Y in the alpha channel and then the Co and Cg in the color channels gives better quality compression. Decompression in a fragment program is only a few instructions and can be well worth it for the quality improvement. Best, Jon Olick On Wed, Apr 23, 2008 at 5:14 AM, Simon Fenney <sim...@po...> wrote: > Sam Martin wrote: > > Out of interest, did you try exposing the YCoCg colour space to your > > artists at all? It's nice and simple, but I'm wondering if anyone has > > had any issues with it in practice? > > > > 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. > > Simon > > > ------------------------------------------------------------------------- > 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 > |
|
From: Simon F. <sim...@po...> - 2008-04-24 08:53:32
|
Minor technicality :-) ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of Jon Olick Sent: 23 April 2008 15:49 To: Game Development Algorithms Subject: Re: [Algorithms] RGB to XYZ conversion Hi Simon, YCoCg is not lossless. You need an extra bit in order to be lossless which is called YCoCg-R. Ahh, That's a trivial technicality :-) |
|
From: Sam M. <sam...@ge...> - 2008-04-24 09:47:14
|
>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 |
|
From: Jon O. <jon...@gm...> - 2008-04-24 14:50:03
|
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 > |
|
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 |
|
From: Jon O. <jon...@gm...> - 2008-04-24 16:56:53
|
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<http://research.microsoft.com/%7Emalvar/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 > |
|
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 |
|
From: Jon W. <hp...@mi...> - 2008-04-24 21:57:51
|
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 |
|
From: Willem H. de B. <wi...@wh...> - 2008-04-25 09:27:06
|
> 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 Doh, you are very right. The second paragraph in my previous post is utterly wrong. Willem |
|
From: Jon O. <jon...@gm...> - 2008-04-25 14:38:47
|
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/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 > |
|
From: Marco S. <mar...@gm...> - 2008-04-25 15:07:30
|
While there's no doubt that from a mathematical standpoint (linearly) interpolating colours in RGB or YCoCg doesn'tmake any difference, artifacts might be introduced by shortcuts hardware guys took while designing interpolation units for RGBA8/DXTn textures. I wonder if these artifacts are consistent on different hardware architectures. Have you guys tried to interpolate FP64 YCoCg textures or to implement bilinear filtering in the fragment shader with half or full precision math? Not that I would consider these options viable solutions :) Marco On Fri, Apr 25, 2008 at 7:38 AM, Jon Olick <jon...@gm...> wrote: > 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/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 > |
|
From: Sam M. <sam...@ge...> - 2008-04-25 15:58:21
|
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
|
|
From: Adrian B. <ad...@gm...> - 2008-04-26 01:46:00
|
"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
>
|
|
From: Adrian B. <ad...@gm...> - 2008-04-26 01:51:00
|
Or you could have been referring to the linearity of the color space
affine transformation (Rx + t). That would work too.
On Fri, Apr 25, 2008 at 6:46 PM, Adrian Bentley <ad...@gm...> wrote:
> "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
> >
>
|
|
From: Jon W. <hp...@mi...> - 2008-04-23 17:58:24
|
Sam Martin wrote: > We recall from [1] that the direct YCoCg color space transform is defined by: > [y,Co,Cg]' = [1/4, 1/2, 1/4].[r,g,b]' > [1/2, 0, 1/2] > [1/4, 1/2, 1/4] > That can't be right, as it collapses RGB into equal values for y and Cg. You can't possibly reconstruct RGB from that. sincerely, jw |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X