Talk:YCbCr

message: If we consider how YCbCr relates to RGB, it's worth noting that there is no article titled "RGB" on Wikipedia, only an article on RGB color spaces. That article makes it clear that there isn't one single RGB color space, but rather multiple color spaces built on the RGB color model, each one with its own primaries, transfer functions, white points, etc.
This YCbCr article, however, does not follow that taxonomy and approach. If we wanted to make it truly analogous to the RGB color spaces article, this article should be renamed "YCbCr color spaces" or perhaps even more broadly "YCC color spaces", and follow the same approach: explain that there is no single YCC color space, that it's a family of color spaces built on the YUV color model (which should be renamed "YUV color model" to match its RGB analog), and then proceed to list the various YCC color spaces and their specifications.  — Preceding unsigned comment added by 208.127.78.240 (talk) 00:23, 15 June 2023 (UTC)
thread_title: Color space vs color spaces vs color model

message: While working with the YCbCr color space I realized that most of the possible YCbCr triples do not correspond to valid RGB triples. Many YCbCr triples yield RGB values, which exceed the valid range from 0.0 to 1.0 (i.e. the RGB values are either negative or larger than one). Especially the negative values are definitely invalid. 
This observation can be quantized. Taking the coefficient matrix for the JFIF color space and computing its determinant yields the volume of the unit cube [0,1]^3 after being transformed with this matrix. The unit cube contains all valid RGB values, so the result of transforming it is the volume of all valid YCbCr values. The determinant and thus the volume happen to be 0.236. This means that only 23.6% of the value triples in the range from 0.0 to 1.0 are valid YCbCr colors. In particular the color tables on this page are wrong. This is also the reason, why their luminance is obviously not constant.
I don't feel like updating the article, but if anyone is interested I can give further details and some graphics I made. Here is one of them:
--Christoph Peters (talk) 22:57, 8 February 2011 (UTC)
thread_title: Invalid YCbCr values

message: Please forgive the odd comment placement, but I think this deserves attention.<BR>
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.<BR>
For example, if (assuming there is no "buffer") Y where 0 (black) or 255 (white), the Cb and Cr values are irrelevant.<BR>
In fact, when saturation of a color is low, the precision of Cb and Cr is of little relevance.<BR>
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[] compression using 8 bit interpolated values.
The above is wrong in some details about computer numbers.
Since there is no sign bit in standard twos-complement integers, the range is from
-128 to 127.  There is no need for an extra bit for sign.  Also the range
127 - -128 = 256 is the same as for an unsigned number. 208.71.232.130 (talk) 00:40, 10 July 2013 (UTC)
thread_title:  Not 2^24 colors 

message: 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)
replies: text: Judging from the decomposition of the example image, I'd say the blue and red chromatic components look like an approximation to the CIELAB opponent channels (which in turn are an approximation to the actual yellow-vs-blue and red-vs-green opponent-hue channels of perceptual color space first described by Ewald Hering). So basically, it seems the Cb channel roughly represents how much bluish-or-yellowish the hue of the color looks like, and the Cr channel how much reddish-or-greenish, which combined are enough to describe the perceptual hue component of all colors (leaving aside the novel hues of the Crane & Piantanida experiment). 213.37.6.23 (talk) 04:48, 25 July 2008 (UTC)
thread_title:  how close is it to red and blue again? 

message: 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)
thread_title:  "Sony Extended Video" 

message: 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)
thread_title:  "Why is it Useful ?" 

message: 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'.
: The FCC standard is for NTSC as it existed in 1953.  — Preceding unsigned comment added by 69.12.176.20 (talk) 21:01, 10 August 2012 (UTC)
thread_title:  Formula? 

message: How to convert computer-RGB to and from gamma corrected RGB?
Lodev 16:30, 24 August 2006 (UTC)
thread_title:  R'G'B' <-> RGB conversions 

message: 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)
thread_title:  Image removed 

message: 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)
replies: text: 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)
thread_title:  So...How do we use this? 

message: 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)
replies: text: 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)
thread_title:  Inverse Matrix 

message: The article says about BT.709 compared to BT.601:
"This form of Y'CbCr is based on an RGB model that more closely fits the phosphor emission characteristics of newer CRTs and other modern display equipment.
Note that the definitions of the R', G', and B' color primary signals also differ between BT.601 and BT.709. So proper conversion of YCbCr from one form to the other is not just a matter of inverting one matrix and applying the other. In fact, when YCbCr is used correctly, the values of Kb and Kr are derived from the precise specification of the RGB color primary signals, so that the luma (Y') signal corresponds as closely as possible to a gamma-adjusted measurement of luminance (typically based on the CIE 1931 measurements of the response of the human visual system to color stimuli)."
According to the Poynting book, BT.601 does not specify primaries directly. Furthermore, Poynton claims that in practice, all modern systems are based on the BT.709 primaries (even SDTV bt.601 systems).  —Preceding unsigned comment added by Knutinh (talk • contribs) 10:46, 6 July 2008 (UTC)
replies: text: What you say that Poynton said was (sort of) correct when it was written (his "Digital Video and HDTV" book was copyright 2003) — i.e., BT.601 did not specify primaries "directly" at that time.  However, it should be implicitly clear that BT.601 was intended to represent signals for 625/50 and 525/59.94 television systems, which were designed according to BT.470, and BT.470 did include a definition of color primaries (which were different than what is in BT.709).  But more importantly, BT.601 has since been revised (2007), and this aspect has been further clarified in that revision.  BT.601 now explicitly defines color primaries.  They are not only different than the ones in BT.709, but there are two of them, depending on whether the system is a 625/50 or 525/59.94 TV system. —Pawnbroker (talk) 17:08, 10 September 2008 (UTC)
replies: text: Yes, indeed. Not only matrix should be correct, but color management of primaries should be done. But please note that for JPEG, that also uses BT.601 matrix, the default space is sRGB, that uses BT.709 primaries, no color managment is needed there, only the change of transfer function (EOTF change from BT.1886 to sRGB). 194.186.53.16 (talk) 18:50, 27 April 2021 (UTC)
thread_title:  Primaries used in 601 vs 709 

message: I put dubious and citation needed tags on "In fact, when Y'CbCr is designed ideally, the values of Kb and Kr are derived from the precise specification of the RGB color primary signals, so that the luma (Y') signal corresponds as closely as possible to a gamma-adjusted measurement of luminance (typically based on the CIE 1931 measurements of the response of the human visual system to color stimuli)."  What is the basis for this?  Dicklyon (talk) 18:32, 10 September 2008 (UTC)
replies: text: One place to find it stated is on page 292 of Poynton's Digital Video and HDTV book (Morgan Kaufman, 2003), where it states that there was "international agreement ... on 'theoretically correct' luma coefficients derived from the Rec. 709 primaries".  Deriving the equations this way is straightforward.  The idea is to determine what coefficient values will make the Y' signal the same as the CIE definition of luminance (ignoring gamma).  This results in the same numerical values that are found as the coefficients of the Y' component as a function of R', G', and B' in the standard.  —Pawnbroker (talk) 19:12, 10 September 2008 (UTC)

text: Additionally, I just noticed that this is also discussed further on page 291 in relation to the Rec. 601 definition of Y' and on page 292 in relation to the SMPTE 240M definition of Y'.  For example, on page 291 it says "In principle, luma coefficients should be derived from the primary and white chromaticities".  So I suggest referring to both pages 291 and 292 (which are in Chapter 24, which is entitled "Luma and color differences").  —Pawnbroker (talk) 19:24, 10 September 2008 (UTC)
thread_title:  Dubious 

message: Does a large slow-loading animated GIF really have to be the first image in the article? -- AnonMoos (talk) 21:06, 17 June 2012 (UTC)
thread_title: First image

message: It would be great if someone could add a section on the new ITU-R Rec. 2020 (Rec._2020) for UHDTV to contrast with 601 and 709. Chris Dolan (talk) 16:45, 9 April 2013 (UTC)
thread_title:  ITU-R Rec. 2020 

message: The formulae for RGB to YCbCr use 0..1 values for RGB. The formulae for YCbCr to RGB produce values from 0..255, so they're not really the inverses.  — Preceding unsigned comment added by 66.68.50.188 (talk) 03:31, 5 October 2014 (UTC)
thread_title:  Inconsistent Units 

message: The RGB-to-YCbCr conversion matrix is supplied for the BT.601 and the BT.2020 standards, but there is nothing shown for the BT.709 standards. A value for Kb and Kr is provided, but that's it. Why did you wikipedians post the matrix for everything BUT the BT.709 standard? It makes no sense. Please post this, so I can use the info to write this program I'm making. I need this matrix, but I can't find it on any other website either. Benhut1 (talk) 18:46, 21 October 2014 (UTC)
replies: text: I added it (and decoding matrix too). For 10 to 16 bit per component you may want to invert the encoding matrix with higher precision. Do NOT ADD precision to encoding matrix! 2A00:1370:812D:F205:189C:7DDD:C537:183A (talk) 13:03, 16 April 2021 (UTC)
thread_title:  What's the correct ITU BT.709 conversion matrix? 

message: What's the correct method of rounding? When I use the math on this page with pure RGB red, I get Y = ~81.48, but this tool converts it to Y = 82. Is it wrong? 83.93.8.224 (talk) 22:44, 4 October 2015 (UTC)
replies: text: BT.601 gives 81.48, that is right. BT.709 gives 62.56, 102.34, 240. So... Here: https://res18h39.netlify.app/color 109.252.90.66 (talk) 15:13, 29 January 2021 (UTC)
replies: text: 62.56 is indeed rounded as 63, BTW. See SMPTE RP 219-1:2014, 100% red. Valery Zapolodov (talk) 18:55, 11 May 2021 (UTC)
replies: text: So, I found out that 81.48 should be rounded as 81 indeed, see page 10 of ITU-R Rec. bt.1729 (100% red, value in brackets is for 8 bit). Valery Zapolodov (talk) 06:45, 12 May 2021 (UTC)
thread_title:  Rounding 

message: Substituted at 11:00, 30 April 2016 (UTC)
thread_title: Assessment comment

message: Possible exact values. Need confirmation for this.
=== ITU-R BT.601 ===
:\begin{align}
 K_R &= 337775559/1130000000 = 0.29891642389380530973451327433628\\
 K_B &= 28299149/247187500 = 0.11448454715549936788874841972187  
\end{align}
=== ITU-R BT.709 ===
:\begin{align}
 K_R &= 2647777  / 12450000 = 0.21267285140562248995983935742972 \\
 K_B &= 336967  / 4668750 = 0.07217499330655957161981258366801
\end{align}
=== ITU-R BT.2020 ===
:\begin{align}
 K_R &= 278309653657/1059332500000 = 0.26272171736164046699218611720116 \\
 K_B &= 7850846519/132416562500 = 0.05928900713609749535674587535075
\end{align}
1&only (talk) 15:55, 7 January 2017 (UTC)
thread_title:  Exact numbers 

message: :\begin{align}
 K_R &= 278309653657/1059332500000 = 0.26272171736164046699218611720116 \\
 K_B &= 7850846519/132416562500 = 0.05928900713609749535674587535075
\end{align}
1&only (talk) 15:55, 7 January 2017 (UTC)
thread_title:  ITU-R BT.2020 

message: The reference images for Cb and Cr are quite different, suggesting one is (or both are) incorrect.
In the vertical image, Cb is green house w/ blue background, while Cr is red house/yellow background.
In horizontal image, we have yellow house/blue background and red house/green background.
(These are generalizations of the colors, I assume my point was made.)
Hopefully this can be addressed? —    DKqwerty    20:47, 1 March 2020 (UTC)
replies: text: You do understand that it should be just shadows of black in all 3 cases? See what ffmpeg's -vf extractplanes=y does. Also see discussion here: https://en.wikipedia.org/wiki/User_talk:Mike1024#Color_components_(HSV,_RGB) 2A00:1370:812D:8D4D:5194:3BCB:161E:D2DB (talk) 23:26, 28 May 2021 (UTC)
thread_title:  Ref image discrepancy 

message: The YCbCr colour space can be visualised as a cube with white and black at the centre of the front and rear faces respectively.
Y runs in a straight line from white to black, through all the greys, when Cb=Cr=0.
As Cb and Cr vary around 0 for a particular Y, so we move left and right, up and down, on a vertical slice of the cube given by Y.
Yet the animated GIF has white and black be at corners of the cube.
Has anyone ever confirmed this GIF is an accurate representation?
Even if it is, the coarseness of the dots, etc., make it a poor representation in my view and it should be deleted as it's misleading, even if nothing better replaces it.
― Ralph Corderoy (talk) 16:38, 2 December 2020 (UTC)
replies: text: The cube shown is the subset of all possible  coordinates that represent valid RGB values. There is no cube face at Y=0 or Y=255, only a single point, because they represent black and white. Movement along the C and C axes is meaningless when luminance is at 0, because 0 luminance just means pure black regardless of what the chrominance components are. At Y=255, it represents maximum luminance, which means all three primaries are at maximum intensity. Movement along the C and C axes again is not possible, because it would require a color primary to go beyond maximum intensity in order to shift the chrominance away from the centerline. Or you can decrease the intensity of the other primaries. But then you are no longer at maximum luminance, so Y=254 or 253 or less. This is reflected in the diagram; as you move away from maximum luminance, some slight deviation from the centerline becomes possible. As you move further away from maximum luminance, more movement along the chrominance axes become possible. Hence, it is a corner.  — Glenwing (talk) 04:51, 29 March 2022 (UTC)
thread_title:  Animated GIF of Colour Space Looks Wrong 

message: In the article, a distinction is made between the constant luminance of YcCbcCrc and the constant intensity of ICtCp, but no explanation of what this means is provided. How do these differ? 80.162.33.59 (talk) 22:09, 4 August 2022 (UTC)
replies: text: There is a cite there. https://www.dolby.com/us/en/technologies/dolby-vision/ICtCp-white-paper.pdf 2A00:1370:8184:5EAB:5186:5C94:2441:2A49 (talk) 01:10, 10 September 2023 (UTC)
thread_title:  Luminance VS Intensity 

message: The four main 4:2:0 pixel formats cited is what Microsoft recommends. It omits other formats that are common or noteworthy such as I420/IYUV. Should they be included? Another list also from Microsoft: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/4-2-0-video-pixel-formats 2001:569:7F81:C200:CD6B:46B4:9B91:65B6 (talk) 15:05, 28 January 2024 (UTC)
replies: text: Yes, interlaced 420 formats should be included. Valery Zapolodov (talk) 19:33, 4 February 2024 (UTC)
thread_title:  Other 4:2:0 Pixel Formats 

message: I find this section impossible to understand. What Y0 and Y1 ? Two nibbles of a value for one pixel, or two different pixels? And the matrix-like images, do they show pixels as each element, or something else? And what do the different colors (in those matrix-like images) represent? I spent an hour trying to guess how to interpret this, without success. 85.230.66.218 (talk) 10:19, 27 March 2024 (UTC)
thread_title:  Packed pixel formats and conversion