Talk:Y′UV

message: When uploading the original image for this article, I absolutely forgot to mention that I actually created it from scratch.  I am going to re-upload it and properly licence it this time.  Denelson83  04:42, 29 October 2005 (UTC)
thread_title:  Oh, dear... 

message: Let A denote the 3x3 transformation matrix from RGB-space to YUV-space. It is true that each in-range RGB-vector transforms into an in-range YUV-vector using A, it is _not_ the case that any in-range YUV-vector (as stated in the tex: 0<=Y<=1, -0.436<=U<=0.436, -0.615<=V<=0.615) has a valid RGB vector as it is transformed by inv(A). The point is that the picture for this article presents a whole bunch of transformed in-range YUV-vectors that do not map to the RGB space. These are located around the edge of the picture. For clarity, shouldn't non-valid RGB-vectors be left out of that image?
Example:
y = [0.5, -0.4, -0.4]' (it's on the image) transforms to (approx.):
r = [0.044, 0.89, -0.31]' (which is a non-valid RGB vector)
--81.172.252.164 14:47, 1 March 2006 (UTC)
replies: text: The actual color range within the UV color space is actually a hexagonal shape, which doesn't fill the (-0.5,-0.5)-(0.5,0.5) square but touches the inner sides of the (-0.436,-0.615)-(0.436,0.615) square.  And by the way, do I need to remind you that this is an analog colorspace. When tuning things on a TV like color and/or brightness, the internal voltages might indeed drop below 0 (depends on the circuitry) and only at the very last moment, when the voltage enters the tube, the negative values are clipped (actually negative values just don't manipulate the electron beam, just as if the voltage were 0) --Zom-B 10:05, 8 Sep 2006 (UTC)
thread_title:  YUV to RGB image misrepresenting the transformation 

message: I can't understand how the given formula for fixed point approximation can work. Unless I'm missing something, it seems plain wrong to me. It is not explained what range is expected for RGB components and what range the YUV result would have. I see in the history the formula has already been removed and readded, please double check it. I can figure out one myself, and post it if needed, but maybe it's worth asking where the one currently in the article came from. SalvoIsaja 21:04, 30 April 2006 (UTC)
replies: text: I have a working code snippet for the inverse transformation (YUV->RGB).
 /* YUV->RGB conversion      */
 /* According to Rec. BT.601 */
 void
 convert(unsigned char y, unsigned char u, unsigned char v,
         unsigned char *r, unsigned char *g, unsigned char *b)
 {
    int compo, y1, u1, v1;
 
    /* Remove offset from components */
    y1 = (int) y - 16;
    u1 = (int) u - 128;
    v1 = (int) v - 128;
 
    /* Red component conversion and clipping */
    compo = (298 * y1 + 409 * v1) >> 8;
    *r = (unsigned char) ((compo < 0) ? 0: ((compo > 255) ? 255: compo));
 
    /* Green component conversion and clipping */
    compo = (298 * y1 - 100 * u1 - 208 * v1) >> 8;
    *g = (unsigned char) ((compo < 0) ? 0: ((compo > 255) ? 255: compo));
 
    /* Blue component conversion and clipping */
    compo = (298 * y1 + 516 * u1) >> 8;
    *b = (unsigned char) ((compo < 0) ? 0: ((compo > 255) ? 255: compo));
 }
Don't know if it can be inserted in the main article. Think about it. --Cantalamessa 14:35, 30 May 2006 (UTC)

text: Discussions I've seen in the past seemed to suggest that people don't want to see sample code in article, preferring that articles instead give algorithms and formulae. (By the way, your code also does not give expected range of inputs or outputs; it is NOT the case that 0 to 255 is a universal representation for color values; worth adding that in a comment. The formulae on the page are open to the same criticism, but they do at least use the 0 to 1 range which color scientists use). Notinasnaid 17:17, 30 May 2006 (UTC)

text: Whether it pleases colour scientists or not, the key point is that you don't define the range of input and output values. Notinasnaid 17:21, 31 May 2006 (UTC)

text: By the way I was mistaken to say the article doesn't define this. It says "Here, R, G and B are assumed to range from 0 to 1, with 0 representing the minimum intensity and 1 the maximum. Y is in range 0 to 1, U is in range -0.436 to 0.436 and V is in range -0.615 to 0.615." Notinasnaid 18:35, 31 May 2006 (UTC)
thread_title:  Fixed point approximation 

message: See Poynton's note about the difference.    If I wasn't lazy myself, I would revamp this article.Glennchan 06:18, 10 December 2006 (UTC)
thread_title:  Y'CbCr information should go on Y'CbCr page 

message: Do UV color values have any corelation to UV mapping on 3D surfaces? --24.249.108.133 16:49, 1 March 2007 (UTC)
replies: text: No. 92.35.31.146 (talk) 17:08, 5 December 2023 (UTC)
thread_title:  Any relation to UV mapping? 

message: The difference is very poorly explained. The conversion matrix coefficients given in the YUV conversion equations here are exactly the same as the equations given in the Y'CbCr for the (601) variation. The explanation says they have difference scaling factors and that YUV is analog. That sounds weird, surely digitising an analog signal does not change anything about the fundamental signal content. —Preceding unsigned comment added by 61.8.12.133 (talk • contribs) 
:The analog and digital scale factors are different because different formats are used to encode the signal (e.g. NTSC encoding may be used on the analog signal).  In digital, there are many flavours of Y'CbCr with different scale factors... in rec. 601 y'cbcr, the chroma is in the 16-240 range while in JPEG it's something else.Glennchan (talk) 00:53, 31 October 2008 (UTC)
thread_title:  Difference between YUV and Y'CbCr 

message: The RGB articles lists a bunch of example values for white, black, red, blue, green, yellow, and so forth.  There is no such entry in the YUV article.  Can someone add these values to make it less abstract and theoretical?  I would do it myself but I don't trust my ability to calculate accurate values. I came here to find what the YUV value for white is, and didn't see any information. -Rolypolyman (talk) 21:43, 16 January 2008 (UTC)
thread_title:  Example numbers 

message: Is Y an error for Y'? This article used to have Y and was then changed to Y'.  In the old article the variables were all Y, in the words and in the matrices.  If this is not an error, Y should be defined. SpinningSpark 08:20, 25 April 2008 (UTC)
thread_title:  <nowiki>Y'' in mathematical derivation section</nowiki> 

message: All material currently supplied via the EBU is provided as either 10-bit 4:2:2 in YUV10 or YUV16 file format or as 8-bit 4:2:2 material. Isn't that just YUV at 10 and 16 bits? Can we have some info about them here?
EBU - HD test sequences
—IncidentFlux [ TalkBack | Contributions ] 13:35, 28 October 2008 (UTC)
thread_title:  10-bit 4:2:2 in YUV10 or YUV16 

message: The image on the top of the page is not the YUV color space.  It is the Y,Y-R,Y-B color space.  In YUV the color difference signals are scaled.  In the image, it is labled from -.5 to .5 on both axis, which if were used in Y,R-Y,B-Y color space with a lumanance of .5 it will be correct because the blue level will be 1 at B-Y=.5 and 0 at B-Y=-.5, and same with the red.  —Preceding unsigned comment added by 75.57.161.130 (talk) 02:23, 31 March 2009 (UTC)
thread_title:  Image is for Y,R-Y,B-Y not for YUV 

message: Back before the merger that created the IEEE, the electronics people were the IRE. Their journal, Proceedings of the IRE, Color Television Issue, was a lifetime inspiration to me (I was probably a freshman in high school, but learned electronics early, from the MIT Rad. Lab. series). IIrc, it was the June, 1949 issue; just about positive about the year.
Although there was a lot of explanation of the color-subcarrier scheme for carrying chroma in NTSC, that's probably of interest to people who want to learn about NTSC analog (and why a 3-ns time error creates a noticeable hue shift!) (The spoof name  was "Never Twice The Same Color", btw; people usually don't get that word "twice".)
If you're a serious student, the quadrature suppressed-carrier modulation scheme is worth learning about; it's still in use, I'm pretty sure, although in a more-developed form. It could be a background for learning about OFDM (and COFDM).
====Human perception====
Main point, though, is that some articles in that issue explained human color vision very clearly, and made it very evident that chrominance could have much less bandwidth than luminance yet still provide a quite-satisfactory image. As well, it was explained why the axes were chosen as they were, to correspond to human color perception.
Moreover, that issue made the concept of color difference signals (U and V, or I and Q) quite clear. It does take some rethinking!  I dare say that, back then, NTSC represented sophisticated engineering. Nikevich (talk) 19:36, 23 May 2009 (UTC)
thread_title:  Historical background and human visual perception 

message: Main point, though, is that some articles in that issue explained human color vision very clearly, and made it very evident that chrominance could have much less bandwidth than luminance yet still provide a quite-satisfactory image. As well, it was explained why the axes were chosen as they were, to correspond to human color perception.
Moreover, that issue made the concept of color difference signals (U and V, or I and Q) quite clear. It does take some rethinking!  I dare say that, back then, NTSC represented sophisticated engineering. Nikevich (talk) 19:36, 23 May 2009 (UTC)
thread_title: Human perception

message: People, I'm quite puzzled about the YUV422 format. The article says that YUV422 represent a macropixel in the format YUYV, but this website says the contrary: a macropixel is of the format UYVY. Additionally, the Aldebaran Nao robocup documentation says that the YUV422 format is UYVY, so who's right?
(Aldebaran documentation, unfortunately, is readeble only for Robocup participants, sorry!)  —Preceding unsigned comment added by 151.50.50.94 (talk) 22:01, 14 January 2010 (UTC)
thread_title:  YUYV or UYVY ??? 

message: YUV and Y'UV were used for a specific analog encoding of color information in television systems, while YCbCr was used for digital encoding of color information suited for video and still-image compression and transmission such as MPEG and JPEG. Today, the term YUV is commonly used in the computer industry to describe file-formats that are encoded using YCbCr.
The article begins with an explanation that says YCbCr is used for digital but that it's called YUV. This corresponds well with the YCbCr article which states: when referring to signals in video or digital form, the term "YUV" mostly means "Y′CbCr"
However, then this article has another description under Confusion with Y'CbCr. This section states that YUV is analogue and YCbCr is digital and that computer textbooks/implementations erroneously use the term YUV where Y'CbCr would be correct.
Right after that, the article describes "getting a digital signal", followed by Converting between Y'UV and RGB. This is very confusing as it seems to be addressing digital video (referencing pixels and FourCC) but uses YUV repeatedly. Is this about analogue-to-digital or about digital methods erroneously called 'YUV'? 
Eradicator (talk) 22:20, 16 May 2010 (UTC)
thread_title:  Further Confusion 

message: So does anybody know if YUV just stand for "Y-signal" "U-signal" "V-signal" or some reference saying what it stands for or who coined it that way or why? Thanks! Rogerdpack (talk) 18:35, 26 April 2012 (UTC)
thread_title:  abbreviation 

message: From all article information this matrix
:
\begin{bmatrix} R \\ G \\ B \end{bmatrix}
=
\begin{bmatrix}
 1 &  0       &  1.13983 \\
 1 & -0.39465 & -0.58060 \\
 1 &  2.03211 &  0
\end{bmatrix}
\begin{bmatrix} Y' \\ U \\ V \end{bmatrix}
:should look like this matrix:
:
\begin{bmatrix} R \\ G \\ B \end{bmatrix}
=
\begin{bmatrix}
 1 &  0       &  1.13983 \\
 -1.7036 & -3.462 & -1.942 \\
 1 &  2.03211 &  0
\end{bmatrix}
\begin{bmatrix} Y' \\ U \\ V \end{bmatrix}
:Note that, if  Y'=1, U=-U_{max}=-0.436 and V=-V_{max}=-0.615 then G= -1.7036 Y'-3.462 U - 1.942 V=1.000162.  — Preceding unsigned comment added by Versatranitsonlywaytofly (talk • contribs) 15:33, 19 June 2012 (UTC)
replies: text: If Y is 1, U and V can be only 0. Also the matrix is just inverted from direct matrix. 2A00:1370:812D:F205:4C51:7CD:D2B7:2086 (talk) 22:48, 18 April 2021 (UTC)
thread_title:  Incorrect RGB matrix 

message: I'd suggest renaming this article into something like YUV family of color spaces or YUV and YUV derivates. That way, all the different kinds of "YUV" could have their own small overview section each (with three ===, ordered chronologically by date of invention or first employment, and by larger supersections with two == dividing between analogue and digital, planar and packed branches within the YUV family tree), with each overview section only giving the proper name, date, and use/function (why people created it, for what purpose/special device). Plus some rather limited, simple prose in one sentence about how its technical makeup differs from the previous or parent version.
Of course, each small overview section would contain a link to the particular version's main article, where we could get really down into the nasty details, including those long, complicated formulas for conversion to and from RGB and between different YUV versions, and illustrations about what the technological makeup looks like.
Many of those illustrations could also be used in this overview article here, provided they're not the kind of final image plus one picture for each of the three respective channels, all stacked on top of each other, as those 4-pic stacks are usually too large for small overview sections. Although I do agree that the one 4-pic stack for the seminal analogue YUV that started it all should be used at the top of this article. However, for the small overview sections per YUV version, I'm thinking of a corresponding pic of the type found here: , as they are neatly sized squares (though we are free to use different symbols, of course).
Another main issue of this current article could also be tackled by such a general overview article with small overview sections for each version of YUV: At the moment, this article only mentions very few of all the YUV derivates currently in use. A more complete list (with 31 packed and 20 planar versions) can be found here: 
This article's lead should also stress more that YUV is definitely not identical with RGB (fewer number of color depth samples between pure black and pure white even in the luma channel Y, roughly 88% of range samples between pure black and pure white in V relating to Blue when comparing to Y, roughly 49% in U relating to Red, and regarding pixel resolution, both chroma channels have about half the pixel resolution each of luma) and thus requires conversion (mainly channel-specific gamma correction) for correct display on RGB monitors!
After all, I've run into quite a few disputes before that stemmed from the fact that RGB monitors do show a picture when fed a YUV video signal or displaying a YUV-encoded video file, which has many people believe that YUV would be the exact same thing as RGB, not realizing that their RGB monitor only shows a more or less distorted rendering of the data. Further confusion is added by the fact that JPGs also use a YUV derivative, however the ICC profile for JPG (*NOT* necessarily MotionJPEG!) specifies an automated gamma correction for RGB monitors, an automatic feature that never existed for the interpretation of YUV video data in the RGB domain.
In other words, YUV was made for TVs (even modern flatscreen TVs use a more-or-less working YUV decoder for correction), whereas most computer monitors (be they CRT or flat) strictly use RGB, and you can't properly judge a YUV-encoded video file on an RGB monitor without conversion.
It's also because people lack the knowledge about the differences between YUV and RGB that they often mistake YUV for only a color model, because they only consider the two chroma axes (blue–luminance and red–luminance) compared to the "absolute" or "fixed" values of RGB that only reside on a more "simple" scale between 0 and 255. But YUV is really an own color space because of lower, channel-specific color depth, i. e. less samples between pure black and pure white, and because the two chroma channels have a pixel resolution that's half that of luma Y. --85.182.140.98 (talk) 11:32, 24 January 2013 (UTC)
thread_title:  Rename and make into an overview article 

message: I see both these sentences:
Y'UV420p (and Y'V12 or YV12) to RGB888 conversion
Y'UV420p (NV21) to ARGB8888 conversion
They are all Y'UV420p,  and with YV12 or NV21 in bracket.  is  YV12 == NV21 ?  — Preceding unsigned comment added by Sinojelly (talk • contribs) 16:09, 2 March 2013 (UTC)
replies: text: See the difference between YV12 and NV21 here: http://www.fourcc.org/yuv.php --37.80.57.245 (talk) 20:19, 9 March 2013 (UTC)
thread_title:  What's the difference of NV21 and YV12 ?  

message: I'd correct this if I knew what the author intended.
Quite near the end of the text, it says
"Y'UV420p (NV21) to ARGB8888 conversion [edit]
This format (NV21) is the standard picture format on android camera preview"
Afaik, Android, the operating system, has little to do with cameras specifically; this probably refers to (analog?) studio cameras.
If it's just a slip of the mind, there's no need to retain this section.
User Nikevich, who often forgets to log in, and uses DHCP.
74.104.161.88 (talk) 05:30, 15 June 2013 (UTC)
thread_title:  Android? 

message: One can try YCbCr to RGB conversion given here. Equations given in this OpenCV page seem practically more accurate than the once mentioned in current wiki article  — Preceding unsigned comment added by 59.185.236.53 (talk) 07:26, 2 December 2013 (UTC)
thread_title:  Correct conversion from YCbCr to RGB 

message: From the content of the article, I cannot make sense of the images entitled "Y' value of 0", "Y' value of 0.5", and "Y' value of 1". When Y' is 0, the center point obviously is and should be black. Shouldn't the rest of the plane be either black as well or out of gamut? How can there be any color at all with zero Luma? Likewise, with a Y' of 1, how can there be any color other than white, and shouldn't all positions outside the center of the plane be out of gamut since one or more of the RGB components would have to be > maximum at any other point? Finally, when Y' is at 0.5, there appears to be a horizontal line of higher brightness through the green quadrant, so how this image represent a constant Luma?
Steve Jorgensen (talk) 08:40, 18 December 2014 (UTC)
thread_title:  Clarification of images and Luma across U/V plane at constant Y' 

message: This article is about YUV a family of low-level structures to represent color images.
The more simple structure is the RGB format. It is intuitive and every reader of this article should be familiar with it, right.
That can be used as the departure of the article. 
The article could start by explaining that images are captured by cameras and scanners which mainly use RGB sensors.
Then explain why RGB had disadvantages for video streaming and why the YUV family of standards emerged. (that part is already in the article, although a it could be improved by only writing the steps important to understand the diverse YUV formats.
Stated the need for YUV, it could be explained using pictures of the structure. There is no need to explain it with programs code.
Explain how a stream of RGB pixels is represented in a YUV stream, first using a diagram, then using mathematics not programming code nor pseudo-code, explaining how the transformation is done. In this article I understood that the constants employed have changed and those constants may change in different variants of the YUV codes. For that reason, at first time, it can be explained using symbols for constants, not the actual numbers.
Once the transformation is abstractly explained, problems with calculations may be explained, but, please do not use program code to explain that. Just draw cells and draw the needed: shifts, ANDs, ORs, etc.
If one thinks the structure of the article as a literate program form to be filled by any reader.  An example C code could be used to illustrate the implementation.
My skills in embellishing web pages is asymptotically close to zero, maybe I'm going to tell something stupid, just take it as a wish from a wiki-language ignorant, right!
If there is a way to dynamically change the page, it could be nice that code in different languages may be changed according to some parameter. In other sites that could be done with by means of javascript, but I do not even suggest to include any kind of scripts in wikipedia, I prefer it simple and safe. But some skilled wikipedian reading this, may know a trick or an alternative to include different actual encodings for the explained transformation. I am thinking in something simple as some frame with programming languages like C, C++, Java, Perl, etc. and by clicking each language name, a piece of code be shown. 
That is just bells and whistles, but I suggest it, because my point of view about the inclusion or not of code in articles of subjects like this, is not to forbid it, but write the article as the context to develop a program in a literate style. It does not really matters if code is included or not, if the code is omitted, any programmer could write the code simply following the explanation and the structure of the article, as I said, the article should be seen as form to fill with code to obtain a literate program. 
 
Following with the content of the article. It would be important to explain where the actual constants (weighs) came from. I did not understood the origin, I mean if it is arbitrary or are obtained following some optimality criteria. That may be important.
After explaining the first version of YUV, the variants could follow, explaining the reason for each one, always starting with a diagram, without repeating the things to take into account when implementing it in a computer, like endianess (not yet mentioned in the actual article), roundoff errors, floating point usage, etc. because that was explained in the first example. 
A reference to that part should be enough, unless the new variant has another particularity which needs more caution during implementation.
A comparison among the variants, citation of the standards document, pictures and videos showing any difference in the quality of the different YUV encoding schema.
May also be included.
Links to articles about programs used to encode YUV.
Advantages, if any, in using those formats to tasks like editing videos, compressing videos, encoding digital pictures, etc.
Thats all, if I knew about this subject, it would be very relaxant for me to write the new article. But as I said in other comment, I came to this article to learn about YUV.
Of course, the actual article has great diagrams and parts that can be reused, but I suggest a new article, because it has a lot of explanations using confusing programs code.
I hope my suggestion be useful for other wikipedians  — Preceding unsigned comment added by 189.178.32.207 (talk) 06:49, 29 October 2015 (UTC)
thread_title:  A suggested new structure for this article, may be better to rewrite it! 

message: In this section https://en.wikipedia.org/wiki/YUV#Numerical_approximations of the article here, specifically in the Full Swing subsection, it claims that the factors for calculating the Y component are 76, 150, and 29. Unfortunately this is incorrect. While these values do sum to 255 themselves, after performing the remaining required operations, with actual pixel data, a white pixel can be seen to produce a Y value of 254, when it SHOULD be 255. That is to say (76*255 + 150*255 + 29*255 + 128) >> 8 = 254. This means that the factors were selected such than when the calculation is performed you get 254, when in fact the factors should have been selected such that the above calculation results in the value 255 instead. I'm not sure which of the 3 factors is incorrect here, or if in fact the entire matrix will need to be recalculated (lest changing one factor throw off the correctness of the entire matrix, assuming that the rest of the matrix is currently correct).
Please, some advanced mathematician on here, please re-write this matrix, so that I can use it in a program that I'm developing. I'm using Wikipedia as my source material, to gain the knowledge that I will need to write my program, but it can't help me if it has so many inaccuracies.
Benhut1 (talk) 01:28, 9 June 2016 (UTC)
thread_title:  Error in Numerical Approximations section. 

message: It would *TREMENDOUSLY* help and clarify a lot of things if the article would also explain the differences between RGB and YUV and its many derivates in regards to color depth per pixel, and clarify that the 4:x:x color subsampling schemes only refer to pixel resolution per color channel. Regarding color depth, the following applies to YUV and its many derivates:
:*a.) The maximum depth or resolution per color channel between pure black and pure white (the absolute lower and upper thresholds that are identical in RGB and YUV) is not 255 values but 255 - 16 - 15 = 224 values (in other words, RGB samples 0-255, whereas YUV etc. only samples 16-240), which would be roughly 11.23 million colors all-in-all. The difference to the 16.7 million of colors of RGB24 aka TruColor is invisible to the human eye when it comes to the number of unique colors, but results in notably different gamma when RGB and YUV material is displayed on a monitor working in the other color space, which is why converting between the two color spaces requires gamma correction.
:*b.) Additionally, YUV and its derivates use color subsampling not only in pixel resolution but also in color depth, where Y stands for brightness aka green and is the one channel that actually samples all 224 values, while blue and red as U and V are color-subsampled (meaning they sample less values between pure black and pure white), where the blue channel samples 88% (of the values in Y) = 198 different values between pure black and pure white, and red only 49% (of the values in Y) = 110 values, so the *ACTUAL* TV signal color depth of YUV and its derivates is 224 * 198 * 110 = slightly under 5 million colors.
::Again, the difference between 5 million colors and RGB TruColor is virtually invisible to the human eye as for the number of *DIFFERENT COLOR VALUES* between pure black and pure white, but this latter fact requires different gamma correction per color channel in order to convert between YUV and RGB, instead of one global gamma value for all three channels. So that's all that YUV <--> RGB conversion is: Applying three different gamma correction values upon the data, one for every color channel, plus color subsampling also in regards to pixel resolution. The practical result of these different gamma values per color channel is that what looks clean and neutral on a YUV screen looks like it has a slight pink tint on an RGB screen if no proper YUV --> RGB conversion is applied. The complimentary case is where unconverted RGB footage is shown on a YUV monitor and turns out slightly greenish. (Note that while chroma subsampling is pretty much invisible to the human eye in *COLOR DEPTH*, it's *SOMEWHAT* noticeable in number of *PIXELS* per color channel. But especially color subsampling in *PIXEL RESOLUTION* is only what they call a "psycho-visual" compression nowadays, based upon the strengths and weaknesses of the human eye that can see colors far less well than brightness, plus YUV monitors blur especially the pixels of the red channel in order to make the huge red pixels less obvious and blocky to the naked eye, while their blockiness stands out like a sore thumb when displaying a YUV signal on RGB monitors. But the latter only applies to video YUV, whereas the same red blur as common in YUV monitors is also applied on RGB monitors as part of the ICC profile of the JPEG standard, which is why nobody sees chunky red pixels on JPEG images.) --2003:EF:13C6:EE54:B4F5:387A:FA44:9009 (talk) 03:42, 17 September 2018 (UTC)
thread_title:  Color depth 

message: I realise it would have helped to ask this on August 17th 2006, but I'm curious where the "YUV420p" terminology originated. It's not anything to do with FourCC and Microsoft only appear to use the term in passing; I don't believe Khronos use it, and I've not seen Apple use it. If it was made up for this page, it's stated in very authoritative terms (which means that others start to use it in an official context and I worry about correcting them...)
If it's somewhere official, it would be nice to link; if not, it should be clear that the terminology is only being used for the sake of abbreviation in the article.
09:40, 3 July 2020 (UTC)
replies: text: Kodak Photo CD used 4:2:0 subsampling. Considering it was as long as back in 1993, and they are in ICC... Maybe it was them. 109.252.90.66 (talk) 15:00, 29 January 2021 (UTC)
replies: text: I know that yuvj420p (j means full range, p means planar) was a hack in libav and was deprecated in FFmpeg. 176.213.135.201 (talk) 09:42, 16 April 2021 (UTC)
thread_title:  Where does "YUV420p" come from? 

message: Most of this article is redundant with the YCbCr article. I would suggest merging them and keeping only one, or possibly removing all the Rec. 601/709/etc colorspace information from the article and only leaving the pixel format information. Thoughts? TD-Linux (talk) 17:19, 20 October 2020 (UTC)
replies: text: What? BT.601 stuff has nothing to do with YCbCr article, just look into scaling coeff. It is actually YUV. And BT.709 is also not YCbCr one, that matrix has two 0.5 numbers in it. I added BT.709 matrices in the YCbCr article here: https://en.wikipedia.org/w/index.php?title=YCbCr&diff=1017259797&oldid=1017034650 2A00:1370:812D:178D:2197:F930:8167:C89A (talk) 15:51, 11 April 2021 (UTC)
thread_title:  Merging with YCbCr article 

message: This article explicitly states that Rec. 601 and Rec. 709 operate on linear values, however they don't - they operate on R'G'B', the gamma corrected values. This is backed up by the sources of Rec._709 and YCbCr, and even more explicitly by Rec._2020, which actually has a mode that can operate on RGB. I'm going to change  the equations on this page to match YCbCr in a few days if no one objects. TD-Linux (talk) 17:22, 20 October 2020 (UTC)
replies: text: I agree. The problem with this article is that except for Y no matrix is the same with BT.601 spec. 2A00:1370:812D:864F:2132:15C2:E4F9:6517 (talk) 20:53, 13 January 2021 (UTC)
replies: text: So it is a little more complicated. It can be both linear and nonlinear. "SECAM IV was a colour standard developed by the Russian research institute NIR (Nautschnuiu Issledowatelskaya Rabota). In fact two standards were developed: Non-linear NIR in which the square root of the amplitude of the chroma signals is transmitted (in a process analogous to gamma correction) and Linear NIR which omits this process. SECAM-IV as described below is the Linear version of NIR." http://web.archive.org/web/20190227232952/http://www.radios-tv.co.uk/Pembers/World-TV-Standards/Colour-Standards.html#SECAM 2A00:1370:812D:864F:3CE5:C0DC:2383:A90E (talk) 18:10, 21 January 2021 (UTC)
replies: text: I fixed it and added info about SECAM IV. 2A00:1FA0:487C:BE81:695D:16C0:3F0:DCCC (talk) 09:52, 16 April 2021 (UTC)
thread_title:  Incorrect information on gamma 

message: Polling before taking action...
There's currently a some code quoted from Android for NV21 conversion. That code is no longer part of Android/stagefright as far as I can tell, and I'm really struggling to tell where those constants came from (no mangling I can do to any obvious TV standard seems to produce that matrix).
If that matrix is meaningful, can anyone refer to a more authoritative source or show some derivation, please? If there's no evidence of it being correct or still being used, the code should go.
Fluppeteer (talk) 20:36, 4 June 2021 (UTC)
replies: text: You gotta be kidding me. It is still there https://android.googlesource.com/platform/frameworks/av/+/0e4e5a8/media/libstagefright/yuv/YUVImage.cpp#375 as for more modern see libyuv. Valery Zapolodov (talk) 00:25, 8 June 2021 (UTC)
replies: text: Valery, your link is pointing to a version of libstagefright that is 6 years old. It is irrelevant to this discussion, which is about the current state of libstagefright. --Krótki (talk) 06:26, 8 June 2021 (UTC)
replies: text: This code is no longer in libstagefright, it is in libyuv. Valery Zapolodov (talk) 21:43, 10 June 2021 (UTC)
thread_title:  Formula no longer in Android 

message: I doubt that, I did give matrices with BT.709 if Umax and Vmax are applied, yet I doubt those are real. Valery Zapolodov (talk) 15:18, 28 August 2021 (UTC)
thread_title:  Did ATSC 1.0, 2.0, 3.0 really use analog Umax, Vmax scaled BT.709? 

message: External links: Defunct fourcc.org redirects to malicious website! 185.63.98.8 (talk) 12:50, 19 June 2023 (UTC)
thread_title:  External links: defunct link leads to malicious website