Talk:YCbCr

Color space vs color spaces vs color model

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)

Invalid YCbCr values

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)

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.

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)

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)

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)

"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)

"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)

"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)

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'.

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)

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.

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

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).

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)

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)

YCbCr, YC_bC_r or YC_BC_R

moved from User talk:Crissov

Dicklyon’s revert of YC_bC_r

Dicklyon’s revert of YC_BC_R

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 “YC_bC_r” would better have been “YC_BC_R”. 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 “YC_BC_R”, but “Y, C_B, C_R”, 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 YC_BC_R 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)

Poynton seems to use the capital-letter subscript form in all the PDF files on his site. He seems fairly “reliable”. :-) –jacobolus (t) 09:40, 19 January 2010 (UTC)

Primaries used in 601 vs 709

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)

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)

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)

Dubious

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)

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)

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)

First image

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)

ITU-R Rec. 2020

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)

Inconsistent Units

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)

What's the correct ITU BT.709 conversion matrix?

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)

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)

Rounding

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)

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)

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)

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)

Assessment comment

The comment(s) below were originally left at Talk:YCbCr/Comments, and are posted here for posterity. Following several discussions in past years, these subpages are now deprecated. The comments may be irrelevant or outdated; if so, please feel free to remove this section.

Many beginners like myself connect via three RCA cables, one for video and two for audio (right and left). It would be helpful if your article would state whether or not the same cables can be used for HDMI or are separate cables needed. ALMARCA (talk) 23:11, 17 February 2009 (UTC)

Last edited at 23:11, 17 February 2009 (UTC). Substituted at 11:00, 30 April 2016 (UTC)

Exact numbers

Possible exact values. Need confirmation for this.

ITU-R BT.601

${\begin{aligned}K_{R}&=337775559/1130000000=0.29891642389380530973451327433628\\K_{B}&=28299149/247187500=0.11448454715549936788874841972187\end{aligned}}$

ITU-R BT.709

${\begin{aligned}K_{R}&=2647777/12450000=0.21267285140562248995983935742972\\K_{B}&=336967/4668750=0.07217499330655957161981258366801\end{aligned}}$

ITU-R BT.2020

${\begin{aligned}K_{R}&=278309653657/1059332500000=0.26272171736164046699218611720116\\K_{B}&=7850846519/132416562500=0.05928900713609749535674587535075\end{aligned}}$

1&only (talk) 15:55, 7 January 2017 (UTC)

• Maybe "exact" values can be derived from the D65 white point and RGB primaries for BT.709 and BT.2020, but they will be different from yours. Derived in the same way as in the RP 177-1993. Tadoritz (talk) 08:07, 31 December 2019 (UTC)
  • You should not use those precise values, though. The values must be rounded to 4 decimals AND normalization of the so called "primaries matrix" should be done so that after rounding the 2 row of the matrix added to 1. If it does not normalize it again, see RP 177 or https://tech.ebu.ch/docs/tech/tech3237s1.pdf or ITU-T H.273 or https://www.ilkeratalay.com/colorspacesfaq.php#xyz. 2A00:1370:812D:178D:9CEE:7F0F:5820:87B9 (talk) 12:13, 10 April 2021 (UTC)

Ref image discrepancy

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)

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)

Animated GIF of Colour Space Looks Wrong

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)

The cube shown is the subset of all possible Y′C_BC_R 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_B and C_R 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_B and C_R 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)

Luminance VS Intensity

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)

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)

Other 4:2:0 Pixel Formats

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)

Yes, interlaced 420 formats should be included. Valery Zapolodov (talk) 19:33, 4 February 2024 (UTC)

Packed pixel formats and conversion

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)