Talk:YCbCr

From Wikipedia, the free encyclopedia

This article may be too technical for a general audience.
Please help improve this article by providing more context and better explanations of technical details to make it more accessible, without removing technical details.
This article is supported by the Color WikiProject, a project that provides a central approach to Color-related subjects on Wikipedia. Help us improve articles to good and 1.0 standards; visit the wikiproject page for more details.
Start This article has been rated as start-Class on the quality scale.
High This article has been rated as high-importance on the importance scale.

Contents

[edit] Not 2^24 colors

Please forgive the odd comment placement, but I think this deserves attention.
I think the fact that 24 bit YCbCr, even without the "head room"/"toe room", does not contain a full set of 16777216 colors, should be expounded upon in this article, and the exact number of possible colors should be given.
For example, if (assuming there is no "buffer") Y where 0 (black) or 255 (white), the Cb and Cr values are irrelevant.
In fact, when saturation of a color is low, the precision of Cb and Cr is of little relevance.
Only when saturation is at the maximum it is possible get the "full range" of hues.

Your figure of 16777216 colors do include the unsaturated/less saturated colors. This includes proper mappings of R,G,B = 0 or 255. However, 24 bit RGB having values of 0..255 (8,8,8) bits, can only be losslessly converted into (8,9,9) bits of YCbCr. This is because the results of the subtractions (B-Y, C-Y) can range from -255..255. So Cb and Cr have to have one sign bit each. You will indeed lose precision if you truncate this to (8,8,8) "24 bit" YCbCr, but the loss is in subtle color differences. Perhaps if also subsampling chroma, you could allow the upsampled (interpolated) chroma values to cover some of these differences by using higher precision math. This would be somewhat analogous to DXT1[[1]] compression using 8 bit interpolated values.

[edit] how close is it to red and blue again?

I hardly understood what chrominancy means, but really can't figure out the two chrominance components Cb and Cr, as mentioned in this article. Maybe someone can explain those in the article? thanks, --Abdull 21:55, 17 Jan 2005 (UTC)

"A different form of YCbCr is used for HDTV, as specificed in the ITU-R BT.709 standard." Just want to say this is not entirely correct. I have a bunch of HDTV files on my PC. Some of them are indeed encoded using Rec.709 (info is present in the header of the file and can be viewed with GSpot or latest DGDecode (Avisynth plugin)), while others are encoded using Rec.601. Wilbert Dijkhof 13:50, 21 March 2005 (GMT)

In general material from an HD source will use the correct (709) color. HD material that is from other sources is frequently generated (incorrectly) using 601 color conversions. Pelman 17:06, 5 April 2007 (UTC)

The above-quoted section has been rephrased to soften its forcefulness to address the above remark attributed to Wilbert Dijkhof. Cat5nap 19:56, 21 Mar 2005 (UTC)

[edit] "Sony Extended Video"

What on earth is "Sony Higher Definition"/"Sony Extended Video/"xvYCC"? Here is a link to a page at Sony which contains the term: http://news.sel.sony.com/pressrelease/6377

Please drop a note over my talk page if you respond :)

Thanks, Wulf 07:31, 9 January 2006 (UTC)

[edit] "Why is it Useful ?"

Feedback: Hi, Thanks for the article. I would have liked to have understood early in the article what YCbCR achieves over say just using RGB values. Why is it useful ? What are the benefits ? Then I would have been motivated to understand all the maths. [My background I.T. and trying to understand the landscape of video codecs]. Anyway, It's great to have all the detail there. Thanks, again. Peter H

I think a key point is in the first sentence: whether this is a good or bad color space (and there are entirely too many) it is the color space used in video systems; so if you need to work in that area, there's your motivation. Computer software tends to give the impression that everything works in RGB, but that's really a convenient abstraction. There are two specific advantages to YCbCr that I can think of, compared to RGB: (1) the use of Y means that there is a black and white signal in there directly; I think this was vital in the transition from black and white to color television. (2) the eye/brain is more sensitive to changes in Y than in CbCr. This is why it is used in JPEG compression; the Cb and Cr components are compressed more agressively than the Y component, allowing better overall compression with less loss of quality. Notinasnaid 09:18, 21 April 2006 (UTC)

The main advantage of Y'CbCr is that it allows color subsampling. As Notinasnaid pointed out, our vision has poorer resolution (or acuity) for color than for brightness. By reducing the resolution/bandwidth of the color, we can optimize the system for lower bandwidth. In practice, you can consider it to be a form of compression.

Y'CbCr encoding actually does not seperate color from brightness perfectly. Better systems however would be more computationally expensive and ?may add more rounding error?, so that's probably why they weren't implemented. Similarly, Y'IQ encoding incorporates some ideas that allow for better quality, but it was too expensive to implement and now the NTSC world uses Y'UV color encoding for analog broadcasts. Y'IQ rotates the chroma components, allowing one axis to have lower bandwidth than the other. This is because our eyes are more sensitive towards orange-blue (I) than for purple-green (Q).

More info can be found at [subsampling and of my articles. Unfortunately my article has errors in it, and may only make sense to me (if even).

Glennchan 02:21, 1 September 2006 (UTC)

[edit] Formula?

The formula "JPEG-YCbCb (601) from "digital 8-bit R'G'B' "" (the last set of equations), shouldn't it be the same as http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC30 ("How do I encode Y'CBCR components from computer R'G'B' ?") Either my math is very wrong (that would surprise me a bit), or I don't understand it at all (wouldn't surprise me), or there is something fishy here (well... this IS Wikipedia).

Reply: You're might be confusing JPEG-YCbCr (601) from "digital 8-bit R'G'B'" with YCbCr (601) from "digital 8-bit R'G'B'" :)

I'm not a regular of wikipedia, but would like to contribute to this particular discussion. People assume there is a single definition for ycrcb, and hence a single formula for converting rgb to/from ycrcb. In fact, there are several different but simular definitions for ycrcb.

The mpeg-2 standard describes these different definitions. You can buy this standard from ISO as ISO/IEC 13818-2, or download it for free from ITU (www.itu.int) as ITU-T H.262. Go to http://www.itu.int/publications/bookshop/how-to-buy.html and follow the instructions at 'Free Recommendations'.

Excerpt from ISO/IEC 13818-2:

Table 6-9: Recommendation ITU-R BT.709:

 E'Y = 0.7154 E'G + 0.0721 E'B + 0.2125 E'R 
 E'PB = – 0.386 E'G + 0.500 E'B – 0.115 E'R 
 E'PR = – 0.454 E'G – 0.046 E'B + 0.500 E'R

FCC:

 E'Y = 0.59 E'G + 0.11 E'B + 0.30 E'R 
 E'PB = – 0.331 E'G + 0.500 E'B – 0.169 E'R 
 E'PR = – 0.421 E'G – 0.079 E'B + 0.500 E'R

Recommendation ITU-R BT.470-2 System B, G:

 E'Y = 0.587 E'G + 0.114 E'B + 0.299 E'R 
 E'PB = – 0.331 E'G + 0.500 E'B – 0.169 E'R 
 E'PR = – 0.419 E'G – 0.081 E'B + 0.500 E'R

SMPTE 170M:

 E'Y = 0.587 E'G + 0.114 E'B + 0.299 E'R 
 E'PB = – 0.331 E'G + 0.500 E'B – 0.169 E'R 
 E'PR = – 0.419 E'G – 0.081 E'B + 0.500 E'R

SMPTE 240M (1987):

 E'Y = 0.701 E'G + 0.087 E'B + 0.212 E'R 
 E'PB = – 0.384 E'G + 0.500 E'B – 0.116 E'R 
 E'PR = – 0.445 E'G – 0.055 E'B + 0.500 E'R

In Table 6-9:

E'Y is analogue with values between 0 and 1;

E'PB and E'PR are analogue between the values –0.5 and 0.5;

E'R, E'G and E'B are analogue with values between 0 and 1;

Y, Cb and Cr are related to E'Y, E'PB and E'PR by the following formulae:

  Y = ( 219 * E'Y ) + 16 
  Cb = ( 224 * E'PB ) + 128 
  Cr = ( 224 * E'PR ) + 128

You can easily invert these equations to obtain the formuals for rgb as a function of ycrcb.

The mpeg-2 reference implementation is the program 'mpeg2dec', freely available on internet. The file 'globals.h' contains the color space conversion coefficients, 'Inverse_Table_6_9'. The actual arithmetic is done in display.c (and store.c). This is 8-bit accurate integer arithmetic.

HTH.

[edit] R'G'B' <-> RGB conversions

How to convert computer-RGB to and from gamma corrected RGB?

Lodev 16:30, 24 August 2006 (UTC)

Computer RGB *is* R'G'B'. It is *not* linear light levels, which is what RGB would be. This is assumming you are talking about the numbers from 0 to 255 that you stick into the display buffer to get an image on the screen.

Also, what are the inverse transformations (YCbCr to RGB) of the given formulas?

Using the Kb=.0722 and Kr=.2126 and doing matrix inversion I get: R = Y + 1.5748*Pr G = Y - 0.1873*Pb - 0.4681*Pr B = Y + 1.8556*Pb

User:Spitzak

[edit] Image removed

I removed image because it was wrong. Color planes there were really very blurred, so it was not good example to show low resoluton of eye to colors. Proper image should be made. —The preceding unsigned comment was added by 85.71.172.18 (talk) 19:50, 17 March 2007 (UTC).

[edit] So...How do we use this?

What this article is really missing is implementation. It's got a series of equations showing me how various ranges of numbers can be manipulated. There's also some discussion regarding various conventions used, and the occasional mention of some impact on color space. But there's nothing here that really talks about the end of the line--what does a CRT do with this info? What are the strengths and weaknesses of this color space in comparison to others across different types of output devices?

This document is marked as being possibly too technical, but the real problem is that it lacks context. It seems technical (aka hard to follow) because the reader has no idea why any of the calculations are being done (eg. to what end). If anyone has some implementation-based "why-it-has-to-be-this-way" information, please add. —Preceding unsigned comment added by 130.215.27.65 (talk) 16:24, 11 October 2007 (UTC)

I added a brief rationale section to give some context. Feel free to work on it or ask questions that might lead to improving it. Dicklyon 00:39, 12 October 2007 (UTC)

[edit] Inverse Matrix

It's a big world, but sometimes Wikipedia still makes me shake my head. Inverting a matrix is vandalism and must be deleted. Sheesh... Well it's not worth fighting over, if inverse transforms might make this page too, err useful, then don't have them. I merely put it there because I needed to write it down somewhere and this is a place that most people would come looking if they needed such a transform. —Preceding unsigned comment added by 61.8.12.133 (talk) 11:24, 16 December 2007 (UTC)

That's exactly what I was looking for. I guess I'd have to search the page history. There it was! :) By the way, the bot only said possible vandalism. --Boivie (talk) 11:50, 18 January 2008 (UTC)

[edit] YCbCr, YCbCr or YCBCR

moved from User talk:Crissov
Dicklyon’s revert of YCbCr
Dicklyon’s revert of YCBCR

What's with the subscript notation? Dicklyon (talk) 20:40, 8 May 2008 (UTC)

It is (or at least used to be) the (professional) standard notation, where no technical limitation prohibited it. I guess a different wiki does not count as a reliable source, but ITU-R BT.601 alias CCIR 601 uses subscripts for example.[2] You will also find many hits for the tex-based search string YC_bC_r. The lowercase b and r (giving “YCbCr”) were probably chosen to give at least a minimal resemblance of the subscripts, which are usually uppercase, so my “YCbCr” would better have been “YCBCR”. If this style is not used on Wikipedia it should at least be mentioned. — Christoph Päper 08:20, 13 May 2008 (UTC)
I have looked in a lot of books, which generally do not have typographical constraints, and they just use YCbCr. Take a look at these; and others, as my search on YCbCr may not match on the subscripted version if it exists. If you can find a few books that do it, we can consider; so far I've seen no reliable sources at all. I have seen subscripts for the variables Cb and Cr, but I haven't seen those imported into the space name YCbCr. Your TeX hits are not very many (fewer than the books), and mostly in Japanese-language documents, so they don't seem to be very definitive. Dicklyon (talk) 15:15, 13 May 2008 (UTC)
As a matter of fact the first book that shows up on Google Books (for me at least, German locale) uses uppercase subscript.
So ITU doesn’t write “YCBCR”, but “Y, CB, CR”, they also write “R, G, B” instead of “RGB”. They don’t use “YCbCr” or “Y, Cb, Cr” at all, so that doesn’t make a very convincing case against subscripts, especiallly considering that Rec. 601 is mentioned as source for parts of this article. Even if the name was better written “YCbCr”, the variables in formulas should still use subscripts, which you also reverted.
It’s just wrong not to mention the subscript notation at all. — Christoph Päper 11:33, 16 May 2008 (UTC)
It' wrong to mention it without a source, or to imply that it is standard or more common without some backup for that. Dicklyon (talk) 21:01, 16 May 2008 (UTC)
I'd say the recommendation for 601, as linked to by Crissov, is a pretty reliable source. Do note that the separation by commas is because they are talking about the components individually, not the system. If you do object to the use of YCBCR in the title, at least use the individual component titles with uppercase subscript as referenced. --tonsofpcs (Talk) 19:51, 26 May 2008 (UTC)
I agree. As I said, if someone wants to use their variable names, that's OK, but renaming the conventionally named YCbCr space to use subscripts is not OK. If Crissov or someone would do one and not the other, it would stand, I expect. Dicklyon (talk) 20:03, 26 May 2008 (UTC)
Note also that Y, Cb, and Cr are also used, just as separately, by ITU (see H.262) --tonsofpcs (Talk) 20:11, 26 May 2008 (UTC)