----- Original Message ----- From: "Makc" <makc@ukrprombank.kiev.ua> To: <theora-dev@xiph.org> Sent: Friday, June 04, 2004 5:29 PM Subject: [theora-dev] YUV question> The statement I care to make here, is simply that there ain't neither > such thing as "luminance", which details "the eye is more sensitive to", > nor "chromaticity", which details the eye is less sensitive to. What weYes, it's true that luminance and chromaticity are somewhat abstract notations. But it is true that the eye is more sensitive to luminance than to chrominance. The eye has two major types of receptor cells, rods and cones, rods are insensitive to colour, and are more sensitive to luminance than the cones. This is a specialisation which leads to our relatively good night vision. In low light the cones cannot oeprate properly, hence when we are in low light we tend to see only the luminance as only our rods are operating. Hence the feeling that when seeing in low light, things are kind of in "black and white". There are also around 10 times more rods than there are cones. Of the cones there are three types, which detect the major chrominace components. Interestingly only about 2% are sensitive to blue, but blue perception is not as deficient as that would indicate, though it is the most deficient of the three colours.> said: "YUV color is used in... TV broadcasts... Only the Y component of a > color TV signal is shown on black-and-white TVs". Besides TV standards, > nothing holds you fron using something like Y = R/4 + G/2 + B/4, which > would considerably speed up codec, or sticking with good old 12-bit RGB. >I know a bit more about visual perception than about video encoding (though it's been a while), but it appears to me the selection of the coefficients of the function relate to the sensitivity to the different colours. Green tends to be overrepresented because the range of green sensitivity is about 30% wider than for either red or blue. Coupled with the fact that in the electromagnetic spectrum green is between red and blue, hence has the greatest overlap in all but the red and blue colour extremes. I think you'd find if you just used those simple integer coefficients that you would lose more valuable information than with the original coefficients. The green is most imoprtant, that's why it's overrepresented and the blue is least, that's why it's underrepresented. As for 12 bit rgb, i'd imagine that it would not be of the same quality as 12bit yuv, for the reason stated in the articel you quoted. That that will give equal importance to luminance and chrominance. I'm sure someone who knows a bit more about the video side of it could give a better explanation. Zen.> > --- >8 ---- > List archives: http://www.xiph.org/archives/ > Ogg project homepage: http://www.xiph.org/ogg/ > To unsubscribe from this list, send a message to'theora-dev-request@xiph.org'> containing only the word 'unsubscribe' in the body. No subject is needed. > Unsubscribe messages sent to the list will be ignored/filtered. > >
On Fri, 4 Jun 2004, Makc wrote:> Here's what you can find in the net on YUV scheme:Hmm? What prompted this?> The statement I care to make here, is simply that there ain't neither > such thing as "luminance", which details "the eye is more sensitive to","ain't neither"? Double negative, so I take your statement to mean that there *is* such a thing as luminance...:)> nor "chromaticity", which details the eye is less sensitive to. What we > have here is simply packing 8-bit R, G and B values together in 8-bit Y, > which actually downsamples them to 7..5 bits, as it takes only 77, > 151 and 30 unique values for R, G and B, respectively; than two additional > 8-bit values are calculated for values that have suffered downsampling > the most (namely, B and R) - it is obvious that they are necessary to > recover individual R, G and B values from Y. Remarkably, those are these > values, U and V, which hold color "details" (least significant bits of B > and R, respectively, mixed with same data that we already have in Y) - > and that is exactly the reason why they can be safely "sacrificed" in > YUV 4:x:x "color spaces". As for why it is like that, things have been > said: "YUV color is used in... TV broadcasts... Only the Y component of a > color TV signal is shown on black-and-white TVs". Besides TV standards, > nothing holds you fron using something like Y = R/4 + G/2 + B/4, which > would considerably speed up codec, or sticking with good old 12-bit RGB.True, very true. Which is why the creators of Cinepak did just that with their codec over a decade ago... http://www.csse.monash.edu.au/~timf/videocodec/cinepak.txt -- -Mike Melanson
> The statement I care to make here, is simply that there ain't neither > such thing as "luminance", which details "the eye is more sensitive to", > nor "chromaticity", which details the eye is less sensitive to. What we > have here is simply packing 8-bit R, G and B values together in 8-bit Y, > which actually downsamples them to 7..5 bits, as it takes only 77, > 151 and 30 unique values for R, G and B, respectively; than two additional > 8-bit values are calculated for values that have suffered downsampling > the most (namely, B and R) - it is obvious that they are necessary to > recover individual R, G and B values from Y. Remarkably, those are these > values, U and V, which hold color "details" (least significant bits of B > and R, respectively, mixed with same data that we already have in Y) - > and that is exactly the reason why they can be safely "sacrificed" in > YUV 4:x:x "color spaces". As for why it is like that, things have been > said: "YUV color is used in... TV broadcasts... Only the Y component of a > color TV signal is shown on black-and-white TVs". Besides TV standards, > nothing holds you fron using something like Y = R/4 + G/2 + B/4, which > would considerably speed up codec, or sticking with good old 12-bit RGB.Err, well. This is partly a compatibility issue. Black and white television used a single intensity signal to represent the image. When developing colour television, they couldn't just send three separate R,G, and B signal, because that would have looked strange on black and white TVs, so they contructed a artificial intensity signal and broadcast that as normal, with the colour difference information sent in two side channels. That way colour TVs had to reconstruct the RGB signals, but existing black and white TVs could just display the intensity signal as normal. Now, given they were doing this, they could also take advantage of the fact that perceptually the colour difference information was less important than the intensity signal and achieve a kind of analog 'compression' by lowpassing the colour difference (or 'chroma') signals so they required less bandwidth than the intensity (or 'luminance') channel. The chroma subsampling of YUV images common in digital video formats is the digital equivalent of that lowpass, and functions equally well as a compression step. Cameras and displays are all natively RGB, and because of the clamping to fixed output ranges, RGB and YUV have slightly different gamuts: there are RGB colours that can't be represented in YUV and YUV colours that can't be represented in RGB. So some information is lost even without the subsampling. -r
On Fri, Jun 04, 2004 at 12:29:33PM +0300, Makc wrote:> > The statement I care to make here, is simply that there ain't neither > such thing as "luminance", which details "the eye is more sensitive to", > nor "chromaticity", which details the eye is less sensitive to. What weluminance and chromaticity are based on lots of research into human vision. Yes, the maths is simple. lossy codecs work by discarding information that humans cannot see. With YUV, we're less sensitive to changes in U and V so we can simply store the U and V components at a lower resolution, hence the 4:2:2 and 4:2:0 pixel formats.> said: "YUV color is used in... TV broadcasts... Only the Y component of a > color TV signal is shown on black-and-white TVs". Besides TV standards, > nothing holds you fron using something like Y = R/4 + G/2 + B/4, which > would considerably speed up codec, or sticking with good old 12-bit RGB.although that would be faster to decode it would result in lower quality images, because discarded information would be more noticeable. Conrad.
<Pine.GSO.4.58.0406040851440.22563@shell> Message-ID: <40C565BD.101@qanu.de> Mike Melanson wrote:>> Besides TV standards, >>nothing holds you fron using something like Y = R/4 + G/2 + B/4, which >>would considerably speed up codec, or sticking with good old 12-bit RGB. > > > True, very true. Which is why the creators of Cinepak did just > that with their codec over a decade ago... > > http://www.csse.monash.edu.au/~timf/videocodec/cinepak.txtJPEG2000 defines a similiar colorspace that can get losslessly transformed from/to RGB using integer arithmethic only, the old experimental w3d code in the xiph CVS contained something like this too. The compression of these schemes for color images is not as well as the one using a model that better matches the human visual sensitivity, but grayscale pictures get compressed a little better since the U+V components become true zero due to the symmetric definition of U and V. Holger