Thread: RE: [Algorithms] YUV rendering.
Brought to you by:
vexxed72
From: Tom F. <to...@mu...> - 2003-10-27 16:04:18
|
> Certainly things like blending and antialiasing don't work > reasonably in > YUV - if you have a nearly black part in your image, Y is > zero but U and > V are undefined. When you blend that with white, instead of > getting grey, > you get an essentially random set of pinks, baby-blues and > pale greens. It sounds like I'm thinking of a different colourspace. YIQ maybe - something that is simply a 3x3 transform of RGB. So black has a perfectly well-defined value, and blends and indeed all linear operations Just Work, because it is just a linear transform of RGB. Of course cross and dot products won't "work", but I don't think anyone ever does those anyway, except maybe for finding the brightness of an RGB vector, which is really just finding Y anyway :-) Clamping of colours needs to be done of course, but IMHO only right at the end of the pipeline. These days that's a doddle. And indeed you have to do it already because there's certain RGB colours that (still) drive TVs and encoders mad. One problem is clamping mid-pipeline - for example you want to turn lights down, but not actually have them subtract from the scene lighting. Clamping the colour in this space would have no good meaning. But again I think people mostly calculate a scalar brightness, clamp that, then multiply it by the light colour. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Stephen J Baker [mailto:sj...@li...] > Sent: 27 October 2003 14:56 > To: gda...@li... > Subject: Re: [Algorithms] YUV rendering. > > > Tom Forsyth wrote: > > > Anyone actually tried this? > > Back in the early 1980's, I worked on a paint program for the > television > industry (it was intended to be a competitor to the Quantel > PaintBox). For > various hardware-related reasons, we decided that it would > work directly > in YUV space. > > Certainly things like blending and antialiasing don't work > reasonably in > YUV - if you have a nearly black part in your image, Y is > zero but U and > V are undefined. When you blend that with white, instead of > getting grey, > you get an essentially random set of pinks, baby-blues and > pale greens. > > The math to correctly blend two YUV's is ugly - so we just > converted YUV > to RGB, did the blend in RGB space - then converted back into YUV. > > Another problem is that some YUV colours are illegal (because they > generate negative values for some of the RGB components). We had > to avoid these like the plague because television broadcast systems > sometimes use them to send control commands to video equipment...also, > it's somewhat undefined what colour any given television set > will produce > for those illegal colours. Most just clamp the negative > component - but > others do something funky...you can't rely on the results to > look the same > everywhere. (Or at least you couldn't back in the 1980's - > maybe modern TV's > don't have that problem anymore.) > > YUV is a great encoding system for storing and transmitting > colour - you > can use lower precision and lower bandwidth for U and V than > for Y. However, > YUV *sucks* for doing any kind of math in colour space - it's > extremely > ill-behaved. > > If you only use 24 bits for YUV - then there are definitely > some 24bit RGB > colours that you can't reach...beware! > > -------------------------------------------------------------- > --------- > The second law of Frisbee throwing states: "Never precede any maneuver > by a comment more predictive than "Watch this!"...it turns out that > this also applies to writing Fragment Shaders. > -------------------------------------------------------------- > --------- > Steve Baker (817)619-2657 (Vox/Vox-Mail) > L3Com/Link Simulation & Training (817)619-2466 (Fax) > Work: sj...@li... http://www.link.com > Home: sjb...@ai... http://www.sjbaker.org |
From: Simon F. <si...@vi...> - 2003-10-27 23:25:00
|
> >> Certainly things like blending and antialiasing don't work >> reasonably in >> YUV - if you have a nearly black part in your image, Y is >> zero but U and >> V are undefined. When you blend that with white, instead of >> getting grey, >> you get an essentially random set of pinks, baby-blues and >> pale greens. > >It sounds like I'm thinking of a different colourspace. YIQ maybe - >something that is simply a 3x3 transform of RGB. YIQ and YUV are very similar - the former is the one used in NTSC and the latter, PAL. IIRC, because you are distorting a cube you can still get "funny values" when you map back into RGB. The way light interacts with objects surely depends on all frequencies of the spectrum but we can usually get away with the simplification to just RGB due to the 3 colour sensors in the eye. It's been a while since I read it but Glassner's "Principles of Digital Image Synthesis" covers these aspects in some detail. I don't it's worth going all the way to Yxx just because of some chance order of evolution :-) (B&W vision evolved first, followed by a red/Green discrimination(?), with Blue tacked on later in primates). Simon |
From: Stephen J B. <sj...@li...> - 2003-10-30 13:50:54
|
Simon Fenney wrote: > I don't it's worth going all the way to Yxx just because of some chance > order of evolution :-) (B&W vision evolved first, followed by a red/Green > discrimination(?), with Blue tacked on later in primates). (That's Red/Green to help distinguish between ripe and unripe fruit - and blue to help in distinguishing food that's going bad.) ----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |
From: Willem H. de B. <Wi...@mu...> - 2003-10-28 09:14:34
|
>It sounds like I'm thinking of a different colourspace. YIQ maybe - >something that is simply a 3x3 transform of RGB. So black >has a perfectly >well-defined value, A linear transformation (which is represented by a 3x3 matrix in this case) is not necessarily one-to-one. Which means that there can be values that are mapped to the same value (black in RGB space), by the inverse transformation (YUV/YIQ -> RGB). Going one way, from RGB to YUV, will have the black colour mapped to black. But going the other way: there are many YUV triplets that represent black. In fact any triplet which has its Y value set to 0, represents black. So the null-space of the inverse transformation consists of all YUV triplets with Y=0. So, black is perfectly defined one way, [ie RGB(0,0,0) is mapped to YUV(0,0,0)]. But not so perfectly defined the other way. - Willem |
From: Jonathan B. <jo...@nu...> - 2003-10-28 15:34:31
|
> A linear transformation (which is represented by a 3x3 matrix in this > case) is not necessarily one-to-one. Which means that there can > be values that are mapped to the same value (black in RGB space), Because a linear transformation is linear, the only way it can be not one-to-one is if you drop entire dimensions. So in the case you're talking about, you'd be converting 3D to 2D or lower, which would make for a color space that is not particularly useful for rendering. The standard colorspaces that are 3x3 transforms from RGB are 3-dimensional themselves. |
From: Willem H. de B. <Wi...@mu...> - 2003-10-28 09:48:13
|
Hmm, actually, looking at the YIQ/YUV matrices more closely, you'd expect the null-space of the inverse transformation to consist of all YUV/YIQ triplets with Y=0, but in fact, it's not. It seems that even when Y=0, the inverse transform maps these (what you'd expect to be black colours) to non-zero RGB triplets. Weird. I don't know if you'd want that. - Willem >-----Original Message----- >From: Willem H. de Boer >Sent: 28 October 2003 09:13 >To: 'gda...@li...' >Subject: RE: [Algorithms] YUV rendering. > > > >It sounds like I'm thinking of a different colourspace. >YIQ maybe - > >something that is simply a 3x3 transform of RGB. So black > >has a perfectly > >well-defined value, > >A linear transformation (which is represented by a 3x3 matrix in this >case) is not necessarily one-to-one. Which means that there can >be values that are mapped to the same value (black in RGB space), >by the inverse transformation (YUV/YIQ -> RGB). Going one way, >from RGB to YUV, will have the black colour mapped to black. But >going the other way: there are many YUV triplets that >represent black. >In fact any triplet which has its Y value set to 0, represents >black. So the null-space of the inverse transformation consists of >all YUV triplets with Y=0. > >So, black is perfectly defined one way, [ie RGB(0,0,0) is mapped to >YUV(0,0,0)]. But not so perfectly defined the other way. > >- Willem > |
From: Simon F. <si...@vi...> - 2003-10-28 14:25:30
|
Willem H. de Boer [mailto:Wi...@mu...] wrote > > >It sounds like I'm thinking of a different colourspace. YIQ maybe - > >something that is simply a 3x3 transform of RGB. So black > >has a perfectly > >well-defined value, > >A linear transformation (which is represented by a 3x3 matrix in this >case) is not necessarily one-to-one. Which means that there can >be values that are mapped to the same value (black in RGB space), >by the inverse transformation (YUV/YIQ -> RGB). Going one way, >from RGB to YUV, will have the black colour mapped to black. But >going the other way: there are many YUV triplets that represent black. But, in this case, I'm sure the transformation matrix from from YUV to RGB is NOT singular and so you can go back and forth (as long as you don't clip the values). IIRC, the problem is that some 'regions' of YUV space don't map to legal RGB values. Simon ______________________________________________________________________ Simon Fenney Principal Design Engineer PowerVR Technologies A Division of Imagination Technologies Ltd Home Park Estate, Kings Langley, Herts, WD4 8LZ, UK ph:+44 1923 260511 mailto:sim...@po... http://www.powervr.com ______________________________________________________________________ "Your work is both good and original. Unfortunately the part that is good is not original and the part that is original is not good." - Samuel Johnson |
From: Willem H. de B. <Wi...@mu...> - 2003-10-28 15:47:27
|
If you are saying that a linear transformation from a 3-dimensional space to a 3-dimensional space is always invertible: This is not necessarily true. A linear transformation T, from a vector-space to itself, need not have a non-zero null-space (ie, it is not injective), or it might not be onto (it, it is not surjective; the range of T does not equal the codomain itself). In other words a linear transformation from R^3 to R^3, need not be one-to-one, in which case it is not invertible. It is easy to check using the 3x3 transformation matrix: If the columns are linearly dependent, the matrix is not invertible, and is therefore either not injective or not surjective. - Willem >-----Original Message----- >From: Jonathan Blow [mailto:jo...@nu...] >Sent: 28 October 2003 15:31 >To: gda...@li... >Subject: Re: [Algorithms] YUV rendering. > > >> A linear transformation (which is represented by a 3x3 >matrix in this >> case) is not necessarily one-to-one. Which means that there can >> be values that are mapped to the same value (black in RGB space), > >Because a linear transformation is linear, the only way it can be >not one-to-one is if you drop entire dimensions. So in the >case you're >talking about, you'd be converting 3D to 2D or lower, which >would make >for a color space that is not particularly useful for rendering. > >The standard colorspaces that are 3x3 transforms from RGB >are 3-dimensional themselves. > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Jonathan B. <jo...@nu...> - 2003-10-28 17:52:05
|
We're saying the same thing here, we're just thinking about it differently. Suppose you have a linear transformation from a 3D space to another "3D space" (in quotes for a reason I'll get to), yet the rank of that transform is only 2. So it's not invertible, as you suggest. This transform has a 1-dimensional nullspace. What that means is that the "3D space" that is the output of your transform is really only 2D. It's oriented in a certain way in a 3D embedding, but it is 2 dimensional -- the apparent 3rd dimension is just a distraction. This is what I meant by "dropping a dimension"... even though you are using 3 coordinates to represent your output color space, there are only 2 degrees of freedom, which just doesn't seem to give you enough colors to be interesting. You cannot have a non-invertible linear transform that doesn't also lose dimensions like this, i.e. the dimension of the nullspace is going to be greater than 0. That is a basic property of linearity. My favorite linear algebra book, "Linear Algebra Done Right", makes this all very clear. -Jonathan. ----- Original Message ----- From: "Willem H. de Boer" <Wi...@mu...> To: <gda...@li...> Cc: <jo...@nu...> Sent: Tuesday, October 28, 2003 9:40 AM Subject: RE: [Algorithms] YUV rendering. > If you are saying that a linear transformation from a 3-dimensional > space to a 3-dimensional space is always invertible: > This is not necessarily true. A linear transformation T, from > a vector-space to itself, need not have a non-zero null-space > (ie, it is not injective), or it might not be onto (it, it is > not surjective; the range of T does not equal the codomain > itself). > In other words a linear transformation from R^3 to R^3, need > not be one-to-one, in which case it is not invertible. It is > easy to check using the 3x3 transformation matrix: If the columns > are linearly dependent, the matrix is not invertible, and is > therefore either not injective or not surjective. > > - Willem > > >-----Original Message----- > >From: Jonathan Blow [mailto:jo...@nu...] > >Sent: 28 October 2003 15:31 > >To: gda...@li... > >Subject: Re: [Algorithms] YUV rendering. > > > > > >> A linear transformation (which is represented by a 3x3 > >matrix in this > >> case) is not necessarily one-to-one. Which means that there can > >> be values that are mapped to the same value (black in RGB space), > > > >Because a linear transformation is linear, the only way it can be > >not one-to-one is if you drop entire dimensions. So in the > >case you're > >talking about, you'd be converting 3D to 2D or lower, which > >would make > >for a color space that is not particularly useful for rendering. > > > >The standard colorspaces that are 3x3 transforms from RGB > >are 3-dimensional themselves. > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: SF.net Giveback Program. > >Does SourceForge.net help you be more productive? Does it > >help you create better code? SHARE THE LOVE, and help us help > >YOU! Click Here: http://sourceforge.net/donate/ > >_______________________________________________ > >GDAlgorithms-list mailing list > >GDA...@li... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 |
From: Sergey <as...@kr...> - 2003-10-28 17:53:12
|
> It is > easy to check using the 3x3 transformation matrix: If the columns > are linearly dependent, the matrix is not invertible If the columns are linearly dependent, then there is at least one vector that can be expressed as a linear combination of the other two. It means that all three vectors (for a 3D case) are all on the same plane (or line). So it is the case of dropping entire dimension, i.e. mapping 3d to a 2d plane. Sergey. |
From: Charles B. <cb...@cb...> - 2003-10-28 15:47:32
|
There's something that might be appropriate in this case, which is a lossless "YUV" transform; I can't seem to find it at the moment, but it's all integer and based on the concepts of "lifting"; I saw it once in a lifting wavelet image compression paper. It goes something like : Y = (R+G+B)/3 Cb = R - Y Cr = B - Y B = Cr + Y R = Cb + Y G = 3*Y - R-B Though I think that Y maybe isn't quite right, there's a funny lifting way to make sure you get the bottom bits back correctly. -------------------------------------------------------------------------------------------- Charles Bloom email "cb" http://www.cbloom.com |
From: Ivan-Assen I. <as...@ha...> - 2003-10-28 16:13:21
|
> Though I think that Y maybe isn't quite right, there's a > funny lifting way to make sure you get the bottom bits back correctly. To get your bottom bits back correctly, you need to do what codec people call "Analysis by Synthesis", AbS - your encoder (RGB -> YCrCb code in this case) essentially is built around the decoder and verifies that the latter will output the best possible signal. In this case, you calculate Y, you calculate Cr, and then choose the Cb in such a way that your reverse YCrCb->RGB code will reconstruct the original RGB triplet. |
From: Willem H. de B. <Wi...@mu...> - 2003-10-28 15:52:56
|
Anyway, if it wasn't for this list suddenly having become painfully slow, here's a mail I sent earlier: Hmm, actually, looking at the YIQ/YUV matrices more closely, you'd expect the null-space of the inverse transformation to consist of all YUV/YIQ triplets with Y=0, but in fact, it's not. It seems that even when Y=0, the inverse transform maps these (what you'd expect to be black colours) to non-zero RGB triplets. Weird. I don't know if you'd want that. - Willem >-----Original Message----- >From: Willem H. de Boer [mailto:Wi...@mu...] >Sent: 28 October 2003 15:40 >To: gda...@li... >Cc: jo...@nu... >Subject: RE: [Algorithms] YUV rendering. > > >If you are saying that a linear transformation from a 3-dimensional >space to a 3-dimensional space is always invertible: >This is not necessarily true. A linear transformation T, from >a vector-space to itself, need not have a non-zero null-space >(ie, it is not injective), or it might not be onto (it, it is >not surjective; the range of T does not equal the codomain >itself). >In other words a linear transformation from R^3 to R^3, need >not be one-to-one, in which case it is not invertible. It is >easy to check using the 3x3 transformation matrix: If the columns >are linearly dependent, the matrix is not invertible, and is >therefore either not injective or not surjective. > >- Willem > > >-----Original Message----- > >From: Jonathan Blow [mailto:jo...@nu...] > >Sent: 28 October 2003 15:31 > >To: gda...@li... > >Subject: Re: [Algorithms] YUV rendering. > > > > > >> A linear transformation (which is represented by a 3x3 > >matrix in this > >> case) is not necessarily one-to-one. Which means that there can > >> be values that are mapped to the same value (black in >RGB space), > > > >Because a linear transformation is linear, the only way it can be > >not one-to-one is if you drop entire dimensions. So in the > >case you're > >talking about, you'd be converting 3D to 2D or lower, which > >would make > >for a color space that is not particularly useful for rendering. > > > >The standard colorspaces that are 3x3 transforms from RGB > >are 3-dimensional themselves. > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: SF.net Giveback Program. > >Does SourceForge.net help you be more productive? Does it > >help you create better code? SHARE THE LOVE, and help us help > >YOU! Click Here: http://sourceforge.net/donate/ > >_______________________________________________ > >GDAlgorithms-list mailing list > >GDA...@li... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Tom F. <to...@mu...> - 2003-10-28 16:44:22
|
The thing is that Y=luminance _only_ if R,G,B are all positive. So if Y=0, then that is black but only if all components are positive. So the RGB colour ( 1, -1, 0) is not black (though I have no idea what it _is_), but its Y is 0. When clipped to the gamut of either monitors or TVs, then yes, black is the only valid colour for Y=0. But we've already discussed how RGB [0,1] isn't even a valid gamut for TVs anyway, so rendering pipelines do need to be able to render out-of-gamut stuff, and with HDR and floating-point surfaces they are already doing that. So when talking about YUV/YIQ, colours like (0,1,0) are distinct from (0,0,1), but neither is valid for a TV, and I suspect most displays/convertors will actually show both as black (or go bonkers). So Y=0 is only black in a practical sense - nothing to do with the maths. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Willem H. de Boer [mailto:Wi...@mu...] > Sent: 28 October 2003 15:48 > To: gda...@li... > Subject: RE: [Algorithms] YUV rendering. > > > Anyway, if it wasn't for this list suddenly having become painfully > slow, here's a mail I sent earlier: > > Hmm, actually, looking at the YIQ/YUV matrices more closely, you'd > expect the null-space of the inverse transformation to consist of > all YUV/YIQ triplets with Y=0, but in fact, it's not. It seems that > even when Y=0, the inverse transform maps these (what you'd expect > to be black colours) to non-zero RGB triplets. Weird. I don't know > if you'd want that. > > - Willem > > >-----Original Message----- > >From: Willem H. de Boer [mailto:Wi...@mu...] > >Sent: 28 October 2003 15:40 > >To: gda...@li... > >Cc: jo...@nu... > >Subject: RE: [Algorithms] YUV rendering. > > > > > >If you are saying that a linear transformation from a 3-dimensional > >space to a 3-dimensional space is always invertible: > >This is not necessarily true. A linear transformation T, from > >a vector-space to itself, need not have a non-zero null-space > >(ie, it is not injective), or it might not be onto (it, it is > >not surjective; the range of T does not equal the codomain > >itself). > >In other words a linear transformation from R^3 to R^3, need > >not be one-to-one, in which case it is not invertible. It is > >easy to check using the 3x3 transformation matrix: If the columns > >are linearly dependent, the matrix is not invertible, and is > >therefore either not injective or not surjective. > > > >- Willem > > > > >-----Original Message----- > > >From: Jonathan Blow [mailto:jo...@nu...] > > >Sent: 28 October 2003 15:31 > > >To: gda...@li... > > >Subject: Re: [Algorithms] YUV rendering. > > > > > > > > >> A linear transformation (which is represented by a 3x3 > > >matrix in this > > >> case) is not necessarily one-to-one. Which means that > there can > > >> be values that are mapped to the same value (black in > >RGB space), > > > > > >Because a linear transformation is linear, the only way > it can be > > >not one-to-one is if you drop entire dimensions. So in the > > >case you're > > >talking about, you'd be converting 3D to 2D or lower, which > > >would make > > >for a color space that is not particularly useful for rendering. > > > > > >The standard colorspaces that are 3x3 transforms from RGB > > >are 3-dimensional themselves. > > > > > > > > >------------------------------------------------------- > > >This SF.net email is sponsored by: SF.net Giveback Program. > > >Does SourceForge.net help you be more productive? Does it > > >help you create better code? SHARE THE LOVE, and help us help > > >YOU! Click Here: http://sourceforge.net/donate/ > > >_______________________________________________ > > >GDAlgorithms-list mailing list > > >GDA...@li... > > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > >Archives: > > >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: SF.net Giveback Program. > >Does SourceForge.net help you be more productive? Does it > >help you create better code? SHARE THE LOVE, and help us help > >YOU! Click Here: http://sourceforge.net/donate/ > >_______________________________________________ > >GDAlgorithms-list mailing list > >GDA...@li... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Troy G. <Tr...@cs...> - 2003-10-28 17:53:22
|
> It sounds like I'm thinking of a different colourspace. YIQ > maybe - something that is simply a 3x3 transform of RGB. So > black has a perfectly well-defined value, and blends and > indeed all linear operations Just Work, because it is just a > linear transform of RGB. Of course cross and dot products > won't "work", but I don't think anyone ever does those > anyway, except maybe for finding the brightness of an RGB > vector, which is really just finding Y anyway :-) Correct me if I'm wrong, but if Y (or any component) is luminance, then you will always have "ambigous" colors like black (luminance/Y = 0) because at that point the other two components are essentially "free variables". Troy Gilbert Developer Relations Criterion Software www.csl.com |
From: Stephen J B. <sj...@li...> - 2003-10-30 14:00:03
|
Troy Gilbert wrote: >>It sounds like I'm thinking of a different colourspace. YIQ >>maybe - something that is simply a 3x3 transform of RGB. So >>black has a perfectly well-defined value, and blends and >>indeed all linear operations Just Work, because it is just a >>linear transform of RGB. Of course cross and dot products >>won't "work", but I don't think anyone ever does those >>anyway, except maybe for finding the brightness of an RGB >>vector, which is really just finding Y anyway :-) > > > Correct me if I'm wrong, but if Y (or any component) is luminance, then you > will always have "ambigous" colors like black (luminance/Y = 0) because at > that point the other two components are essentially "free variables". That's true - so let's forget about utterly black colours. The practical problems still happen *close* to black - where U and V are well-defined. If Y is 0.01 - then U and V can still have pretty wild values and the resulting colour will be almost perfectly black. However, there is a huge gamut of these near-blacks - all of which look pretty much identical. However, when you blend them 50/50 with white, instead of getting a bunch of almost-grey's (as you would in RGB space), you get a bunch of fairly vivid pastel colours. What looks like a simple case of mixing black with white gets you a random colour instead of grey! This is just completely undesirable in a colour system. ----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |
From: Willem H. de B. <Wi...@mu...> - 2003-10-29 09:12:56
|
>My favorite linear algebra book, "Linear Algebra Done Right", >makes this all very clear. It does. It's one of my favourites as well! :) >-----Original Message----- >From: Jonathan Blow [mailto:jo...@nu...] >Sent: 28 October 2003 17:45 >To: gda...@li... >Cc: jo...@nu... >Subject: Re: [Algorithms] YUV rendering. > > >We're saying the same thing here, we're just thinking about >it differently. > >Suppose you have a linear transformation from a 3D space to another >"3D space" (in quotes for a reason I'll get to), yet the rank of that >transform is only 2. So it's not invertible, as you suggest. This >transform has a 1-dimensional nullspace. > >What that means is that the "3D space" that is the output of >your transform >is really only 2D. It's oriented in a certain way in a 3D embedding, >but it is 2 dimensional -- the apparent 3rd dimension is just a >distraction. This is what I meant by "dropping a dimension"... >even though you are using 3 coordinates to represent your >output color space, there are only 2 degrees of freedom, which >just doesn't seem to give you enough colors to be interesting. > >You cannot have a non-invertible linear transform that >doesn't also lose >dimensions like this, i.e. the dimension of the nullspace is going >to be greater than 0. That is a basic property of linearity. > >My favorite linear algebra book, "Linear Algebra Done Right", >makes this all very clear. > > -Jonathan. > >----- Original Message ----- >From: "Willem H. de Boer" <Wi...@mu...> >To: <gda...@li...> >Cc: <jo...@nu...> >Sent: Tuesday, October 28, 2003 9:40 AM >Subject: RE: [Algorithms] YUV rendering. > > >> If you are saying that a linear transformation from a 3-dimensional >> space to a 3-dimensional space is always invertible: >> This is not necessarily true. A linear transformation T, from >> a vector-space to itself, need not have a non-zero null-space >> (ie, it is not injective), or it might not be onto (it, it is >> not surjective; the range of T does not equal the codomain >> itself). >> In other words a linear transformation from R^3 to R^3, need >> not be one-to-one, in which case it is not invertible. It is >> easy to check using the 3x3 transformation matrix: If the columns >> are linearly dependent, the matrix is not invertible, and is >> therefore either not injective or not surjective. >> >> - Willem >> >> >-----Original Message----- >> >From: Jonathan Blow [mailto:jo...@nu...] >> >Sent: 28 October 2003 15:31 >> >To: gda...@li... >> >Subject: Re: [Algorithms] YUV rendering. >> > >> > >> >> A linear transformation (which is represented by a 3x3 >> >matrix in this >> >> case) is not necessarily one-to-one. Which means that >there can >> >> be values that are mapped to the same value (black in >RGB space), >> > >> >Because a linear transformation is linear, the only way >it can be >> >not one-to-one is if you drop entire dimensions. So in the >> >case you're >> >talking about, you'd be converting 3D to 2D or lower, which >> >would make >> >for a color space that is not particularly useful for rendering. >> > >> >The standard colorspaces that are 3x3 transforms from RGB >> >are 3-dimensional themselves. >> > >> > >> >------------------------------------------------------- >> >This SF.net email is sponsored by: SF.net Giveback Program. >> >Does SourceForge.net help you be more productive? Does it >> >help you create better code? SHARE THE LOVE, and help us help >> >YOU! Click Here: http://sourceforge.net/donate/ >> >_______________________________________________ >> >GDAlgorithms-list mailing list >> >GDA...@li... >> >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> >Archives: >> >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> > >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: SF.net Giveback Program. >> Does SourceForge.net help you be more productive? Does it >> help you create better code? SHARE THE LOVE, and help us help >> YOU! Click Here: http://sourceforge.net/donate/ >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Tom F. <to...@mu...> - 2003-10-30 15:01:54
|
> If Y is 0.01 - then U and V can still have pretty wild values and the > resulting colour will be almost perfectly black. But where did those wild out-of-gamut colours come from in the first place? Not from a texture - you'd make sure your textures didn't have that. They didn't come from shading - any scalar-scaling would lerp towards (0,0,0), which is always in gamut whereever you start (I believe all gamuts in these spaces are are convex polyhedra). Ditto lerps - always in gamut. Not 100% sure about colour modulation. Maybe that can fall out of gamut even if the two starts are in gamut. If you're doing subtractions or adds - yeah, they'd get wierd. Additive alpha would be fine as long as you clipped to gamut on screen present, and never rendered any effects over additive alpha. Which you rarely do anyway. I guess there's cases where it could still go wierd. I think it really needs some experimentation to see if these are real problems or not :-) Tom Forsyth - ex-Muckyfoot bloke and Microsoft MVP. Muckyfoot is the product of your deranged imagination, and does not in any way imply existence of the company. > -----Original Message----- > From: Stephen J Baker [mailto:sj...@li...] > Sent: 30 October 2003 14:04 > To: gda...@li... > Subject: Re: [Algorithms] YUV rendering. > > > Troy Gilbert wrote: > >>It sounds like I'm thinking of a different colourspace. YIQ > >>maybe - something that is simply a 3x3 transform of RGB. So > >>black has a perfectly well-defined value, and blends and > >>indeed all linear operations Just Work, because it is just a > >>linear transform of RGB. Of course cross and dot products > >>won't "work", but I don't think anyone ever does those > >>anyway, except maybe for finding the brightness of an RGB > >>vector, which is really just finding Y anyway :-) > > > > > > Correct me if I'm wrong, but if Y (or any component) is > luminance, then you > > will always have "ambigous" colors like black (luminance/Y > = 0) because at > > that point the other two components are essentially "free > variables". > > That's true - so let's forget about utterly black colours. > The practical > problems still happen *close* to black - where U and V are > well-defined. > > If Y is 0.01 - then U and V can still have pretty wild values and the > resulting colour will be almost perfectly black. > > However, there is a huge gamut of these near-blacks - all of > which look > pretty much identical. However, when you blend them 50/50 > with white, instead > of getting a bunch of almost-grey's (as you would in RGB > space), you get > a bunch of fairly vivid pastel colours. What looks like a > simple case of > mixing black with white gets you a random colour instead of grey! > > This is just completely undesirable in a colour system. > > -------------------------------------------------------------- > --------- > The second law of Frisbee throwing states: "Never precede any maneuver > by a comment more predictive than "Watch this!"...it turns out that > this also applies to writing Fragment Shaders. > -------------------------------------------------------------- > --------- > Steve Baker (817)619-2657 (Vox/Vox-Mail) > L3Com/Link Simulation & Training (817)619-2466 (Fax) > Work: sj...@li... http://www.link.com > Home: sjb...@ai... http://www.sjbaker.org |
From: Gareth L. <GL...@cl...> - 2003-10-30 15:08:49
|
> Muckyfoot is the product of your deranged imagination, > and does not in any way imply existence of the company. Only a brit could have that kind of humor :) |
From: Simon F. <si...@vi...> - 2003-10-30 15:08:53
|
Stephen J Baker [mailto:sj...@li...] wrote: > >If Y is 0.01 - then U and V can still have pretty wild values and the >resulting colour will be almost perfectly black. I'm getting the feeling that, perhaps, many here don't know what the YUV definition (or better still for the digital environment, YCrCb) actually is. According to "Video Demystified" the YCrCb colour space (which is a scaled and offset version of YUV) is defined (for computer graphics values of 0..255) as.... Y601 = 0.275 R' + 0.504 G' + 0.098 B' + 16 Cb = -0.148 R' - 0.291 G' + 0.439 B' + 128 Cr = 0.439 R' - 0.368 G' - 0.071 B' + 128 with the inverse transform: R' = 1.164(Y601 - 16) + 1.596(Cr-128) G' = 1.164(Y601 - 16) - 0.813(Cr-128) - 0.391(Cb-128) B' = 1.164(Y601 - 16) + 2.018(Cb-128) ...where R'G'B are gamma correct values. You *do* have to clamp your resulting values to the 0..255 range since the colour cube in one space will be distorted in the other. In YCrCb "black" clearly corresponds to {16, 128, 128}. White (assuming I haven't mistyped on the calculator) is {239, 128, 128}. >However, there is a huge gamut of these near-blacks - all of which look >pretty much identical. I can't see that there are any more than with RGB (except if you've deliberately moved a value out of range) >However, when you blend them 50/50 >with white, instead >of getting a bunch of almost-grey's (as you would in RGB >space), you get >a bunch of fairly vivid pastel colours. I don't understand what you are saying. Both colour spaces are linear. If you've mapped colours A and B from RGB to YUV, do a 30:70 blend and map back to RGB, you'll get exactly the same results as if you stayed in RGB to start with. Or have I misunderstood the debate? Simon ______________________________________________________________________ Simon Fenney Principal Design Engineer PowerVR Technologies A Division of Imagination Technologies Ltd Home Park Estate, Kings Langley, Herts, WD4 8LZ, UK ph:+44 1923 260511 mailto:sim...@po... http://www.powervr.com ______________________________________________________________________ "Your work is both good and original. Unfortunately the part that is good is not original and the part that is original is not good." - Samuel Johnson |
From: Tom H. <to...@ve...> - 2003-10-30 17:09:58
|
At 07:08 AM 10/30/2003, you wrote: >I'm getting the feeling that, perhaps, many here don't know what the YUV >definition (or better still for the digital environment, YCrCb) actually is. So far, everyone seems to know what it is ;) >According to "Video Demystified" the YCrCb colour space (which is a scaled >and offset version of YUV) is defined (for computer graphics values of >0..255) >as.... The differences between YUV, YIQ, YCbCr and the variants of each are all within the coefficients, and practically speaking are mostly irrelevant unless you're going to an actual video source with them. Some have ranges of 16-239, others are full 0-255. >You *do* have to clamp your resulting values to the 0..255 range since >the colour cube in one space will be distorted in the other. If you map the full range of RGB values to YUV values you end up with all resulting values in the 0-255 domain in YUV. If you map the full range of YUV value to RGB values, you get a rotated cube with a great deal of the values outside of the 0-255 range of RGB. I'm sticking with YUV for my comments since there's at least one variation that uses 0-255 range ;) >In YCrCb "black" clearly corresponds to {16, 128, 128}. In YUV {0, x, y} is black for any values of x or y. Please note, that assuming finite precision, the conversion from RGB to YUV and back is _not_ lossless. The redundant black information at Y = 0 makes it pretty clear that you have fewer bits available in YUV for expressing RGB values than in native RGB. This isn't a real problem, but it just another side-effect of the mis-matched gamut between the two color spaces. >White (assuming I haven't mistyped on the calculator) is {239, 128, 128}. Yes, that is the only white. > >However, there is a huge gamut of these near-blacks - all of which look > >pretty much identical. > >I can't see that there are any more than with RGB (except if >you've deliberately moved a value out of range) See my comment above. If Y = 0, you get black for all chroma values. > >However, when you blend them 50/50 > >with white, instead > >of getting a bunch of almost-grey's (as you would in RGB > >space), you get > >a bunch of fairly vivid pastel colours. > >I don't understand what you are saying. Both colour spaces are >linear. If you've mapped colours A and B from RGB to YUV, do a 30:70 blend >and map back to RGB, you'll get exactly the same results as if you stayed in >RGB to start with. > >Or have I misunderstood the debate? I believe you have. He's saying that if you have a value near black (Y = 1), and then interpolate between that and white in a chroma color space, you'll get vastly different results depending on the chroma values in the near black color. This is different from RGB where if you have a color near black and interpolate between that and white you'll always get a result that is very near gray. This makes sense as the YUV value we're talking about interpolating from can't exist in the RGB space. Oddly enough, I'm wondering if this isn't a "good" thing with chroma based color spaces for 3D rendering purposes. One of the issues with doing lighting in RGB space is that you can't make a dark scene brighter as you've lost all the color information when it's black (or near black). With YUV, the color information would be preserved in dark areas, which could make the idea of rendering a scene with color first, and then adding in lights to the scene possible. Maybe this doesn't work out right for colored lights, I'd have to think about it some more. Even if this worked, I'm not certain that this provides a real benefit .. it was just something that came to mind ;) Tom |
From: Tom F. <tom...@bl...> - 2003-10-30 21:32:15
|
> From: Tom Hubina > > In YUV {0, x, y} is black for any values of x or y. No, it isn't. (0,0,0) is defined as black, any other values (0,x,y) are well-defined as being out of gamut and not "real" colours (one or more of R,G,B are negative). They're not black, they're.... Something Else (insert lightning and spooky laughter). > Please note, that assuming finite precision, the conversion > from RGB to YUV > and back is _not_ lossless. The redundant black information > at Y = 0 makes > it pretty clear that you have fewer bits available in YUV for > expressing > RGB values than in native RGB. This isn't a real problem, but it just > another side-effect of the mis-matched gamut between the two > color spaces. Well there's two things here. With finite precision the conversion is lossy, but that's obvious. With infinite precision, the transform is lossless. You can convert back and forth all day, as long as you don't clamp to the gamut of the output device. > See my comment above. If Y = 0, you get black for all chroma values. No, you don't. You get some positives for some colours, negatives for others. They're not black, they're Not Colours, which is a totally different thing. TomF - Muckyfoot mourner. |
From: Alen L. <ale...@cr...> - 2003-10-31 06:31:44
|
> Oddly enough, I'm wondering if this isn't a "good" thing with chroma based > color spaces for 3D rendering purposes. One of the issues with doing > lighting in RGB space is that you can't make a dark scene brighter as > you've lost all the color information when it's black (or near black). With > YUV, the color information would be preserved in dark areas, which could > make the idea of rendering a scene with color first, and then adding in > lights to the scene possible. Maybe this doesn't work out right for colored > lights, I'd have to think about it some more. Even if this worked, I'm not > certain that this provides a real benefit .. it was just something that > came to mind ;) Actually, the real problem in adding lights later is not in the colorspace or in framebuffer precision, but in the operations not being associative in the order we'd like them to be. You have to sum all lights and then multiply with texture: result = texture * (light1 + light2 + ... + lightN + lightExtra) = texture * (light1 + light2 + ... + lightN) + texture * lightExtra != texture * (light1 + light2 + ... + lightN) + lightExtra So, once you store the result in the framebuffer, you can't add one more light, unless you map the texture again. So this would fail even if you are only using grayscale, and even with infinite precision. I don't think a change in colorspace can help here. Just chattering... Alen |
From: Simon F. <si...@vi...> - 2003-10-31 08:33:58
|
Tom Hubina [mailto:to...@ve...] wrote: >Simon wrote: >>I don't understand what you are saying. Both colour spaces are >>linear. If you've mapped colours A and B from RGB to YUV, do >>a 30:70 blend and map back to RGB, you'll get exactly the same >>results as if you stayed in >>RGB to start with. >> >>Or have I misunderstood the debate? > >I believe you have. He's saying that if you have a value near >black (Y = 1), and then interpolate between that and white in a chroma >color space, you'll get vastly different results depending on the chroma >values in the near black color. That's impossible. In YUV/YIQ/YCrCb there is no "squeezing" of the colour space as you get closer to "Y=0". YUV<->RGB is a straight forward linear mapping and what you are saying implies a non-linear (or perhaps homogeneous space) transformation. >This is different from RGB where if you have >a color near black and interpolate between that >and white you'll always get a result >that is very near gray. This makes sense as the YUV value >we're talking >about interpolating from can't exist in the RGB space. You might be thinking of the HLS (Hue, Luma, Saturation) or HSV colour spaces which definitely are non-linear wrt RGB. With HSV, for example, you can get blends like cyan-to-red that go through white!! Simon |
From: Tom H. <to...@ve...> - 2003-10-31 09:56:00
|
At 12:33 AM 10/31/2003, you wrote: >That's impossible. In YUV/YIQ/YCrCb there is no "squeezing" of the colour >space as you get closer to "Y=0". YUV<->RGB is a straight forward linear >mapping >and what you are saying implies a non-linear (or perhaps homogeneous >space) transformation. I'm not implying anything. I'm describing exactly what happens. YUV1 = 1,128,0 (near black, but ever so slightly has a color .. I think it's red, but maybe I'm off .. I don't feel like doing the conversion) YUV2 = 255, 0, 0 (white). If you interpolate 50% between those values, you get YUV3 = 128, 64, 0 which is like some reddish (orange?) color. As you change the chroma values in YUV1 you get vastly different results after interpolation, even though the starting colors where all very near to black. You can bang your head about linear mappings all day long (which it is, but I don't think that tells the whole story), but run the numbers yourself and tell me what happens. That said, if you start with two valid RGB colors, convert them to YUV, and do an interpolation between them you'll get the same result (minus conversion errors) as if you'd done the interpolation in RGB. I guess the point here is, you can create colors in YUV that don't exist in RGB, and when you interpolate between those and the closest thing you could get in RGB (clamped after conversion) you get vastly different results. Why does all this matter? I don't think it does really, but it's something you need to be cognizant of if you're going to try to create a 3D renderer in YUV space for eventual display in RGB space. Side note - When going from RGB to YUV, all values of RGB map into the valid range of YUV. However, there is a compression of those values (due to things like the redundant blacks) so multiple RGB colors will map to the same YUV value (quantization). The only time you get into gamut trouble is when you try to map YUV back into RGB space, or try to send a YUV signal with "bad" values out to a display (since the TV converts the YUV to RGB in order to send a signal to the CRT). Maybe another way of looking at it is that you can represent a wider range of colors in YUV than RGB, but at a coarser granularity. Tom |