Talk:YUV

From Wikipedia, the free encyclopedia

	This article is supported by the Color WikiProject. This project provides a central approach to Color-related subjects on Wikipedia. Please participate by editing the article, and help us assess and improve articles to good and 1.0 standards, or visit the wikiproject page for more details.
A	This article has been rated as A-Class on the quality scale.
???	This article has not yet received a rating on the importance scale.
Article Grading: The article has been rated for quality and/or importance but has no comments yet. If appropriate, please review the article and then leave comments here to identify the strengths and weaknesses of the article and what work it will need.

I made a minor change to the wording of how chroma signals are made from the U and V channels as the previous wording implied that U and V are directly added when they're actually conveyed separately on the color subcarrier.

1 U+V = C ?
2 Exact numbers
3 Code sample
4 Oh, dear...
5 YUV to RGB image misrepresenting the transformation
6 color
7 Fixed point approximation
8 Exact numbers
9 Y'CbCr information should go on Y'CbCr page
10 Any relation to UV mapping?

[edit] U+V = C ?

Hi, first of all, what do U and V mean? Then, I don't understand the way how U and V are mapped on the u and v color map. Do the x- and y-axis equal voltages that are on the U and V channel? For example +0.3 Volts on the V-channel, and -0,2 Volts on the U-Channel equal a brownish color?

I really have problems with the following sentence:

"For instance if you amplitude-modulate the U and V signals onto quadrature phases of a subcarrier you end up with a single signal called C, for chroma, which can then make the YC signal that is S-Video."

What does quadrature blahblah mean? Aren't the U and V signals totally destroyed when they are mixed?

Thank you so much for all the efford you put into this article, --Abdull 21:45, 17 Jan 2005 (UTC)

i don't really understand this myself but the following pages may help

Chrominance Colorburst Quadrature amplitude modulation Plugwash 23:30, 18 Feb 2005 (UTC)

The U and V are mapped by the equations. The R, G, & B values are normalized to a range [0, 1]. So, for example, (R, G, B) = (1, 0, 0) would be red and (1, 1, 1) would be white. Using the equations in the article you can see Y, U, and V are on different ranges. The values have no direct relationship to voltages (that's for the physical implementation to deal with as this is just the color space).

Abdull, you need to understand this "quadrature blahblah" before you can understand that information is not lost. It's the process of converting two real signals, say, U and V onto a complex signal C = U + j*V. So your equation as the header here is mising the imaginary number: C = U+jV not C = U+V. Cburnett 00:41, 19 Feb 2005 (UTC)

I don't know if this will help or hinder, but I find it helpful to think of complex numbers as simply pairs of numbers. It is elegant mathematically to convert the two real numbers a and b into the complex number C = a + j.b but doesn't really change anything, except to make some kinds of formula quicker to write. For example, you can add two complex numbers together and it is just the same as adding together the separate numbers in each pair. Consider

C1 = a1 + j.b1
C2 = a2 + j.b2
C1 + C2 = a1 + j.b1 + a2 + j.b2 = (a1 + a2) + j.(b1+b2)

But take care, if you are new to complex mathematics, not to generalise. You can add and subtract complex numbers in this way, and you can multiply or divide by a single constant. But multiplying two complex numbers is NOT the same as just multiplying their elements.

If I read this quadrature stuff right, the two signals are mixed in such a way that they can be separated (because they are at 90 degree angles?) The complex notation is just a convenient way of representing this combined information with a single item in a formula. Notinasnaid 10:27, 19 Feb 2005 (UTC)

Thank you all for your great help. Right now I have the idea that the colors red, green and blue all lie 120° apart from each other on the U-V color plane. Am i right? Well, my problem is to understand on what principle this u-v color plane is made up... why is reddish colorin the upper region, why is a purple tint in the right region, etc? there must be some argumentable logic behind it. Has YUV always its roots in RGB color space (thus, you always need RGB before you can give YUV values)?

And still, what does U and V stand for? Ultra and Vulvar? Thanks, --Abdull 13:14, 23 Mar 2005 (UTC)

U, V and W are secondary coordinate identifiers, whereas X, Y and Z are the primary ones. Maybe they used variables with the names U and V for color because X and Y were already taken for the pixel location in the being edited? --Zom-B 9:07, 8 Sep 2006 (UTC)

[edit] Exact numbers

Are the 3 decimal place figures in the matrices and formulae of the article exact, or can they be written completely accurately in a surd/trigonometrical/whatever form? Just curious where they came from... – drw25 (talk) 15:37, 14 July 2005 (UTC)

I don't know the details in this case, but I think these are most likely to be first generation numbers - not derived numbers. Some people picked them to get the results they wanted. So in that sense they are probably exact. The exotic numbers in Lab are exact in that sense. Notinasnaid 16:20, 14 July 2005 (UTC)

The numbers are from "Rec. 601". The document was originally known as "CCIR Rec. 601". It's now ITU-R BT.601, the current version is BT.601-5 . So, yes, they're just as precise as they are in that document. NikolasCo 10:51, 19 March 2006 (UTC)

[edit] Code sample

I removed the following from the page:

Below is a function which convert RGB565 into YUV:

void RGB565ToYCbCr(U16 *pBuf,int width, int height)
{
        U8 r1,g1,b1,r2,g2,b2,y1,cb1,cr1,y2,cb2,cr2;
        int i,j,nIn,val;
        for(i=0;i<height;i++)
        {
                nIn = i*width;
                for(j=0;j<width;j+=2)
                {
                        b1 = (U8)((pBuf[nIn+j]&0x001f)<<3);
                        g1 = (U8)((pBuf[nIn+j]&0x07e0)>>3);
                        r1 = (U8)((pBuf[nIn+j]&0xf800)>>8);
                        val = (int)((77*r1 + 150*g1 + 29*b1)/256);
                        y1=((val>255) ? 255 : ((val<0) ? 0 : val)); 
                        val = (int)(((-44*r1 - 87*g1 + 131*b1)/256) + 128);
                        cb1=((val>255) ? 255 : ((val<0) ? 0 : val)); 
                        val = (int)(((131*r1 - 110*g1 - 21*b1)/256) + 128);
                        cr1=((val>255) ? 255 : ((val<0) ? 0 : val)); 
                        
                        b2 = (U8)((pBuf[nIn+j+1]&0x001f)<<3);
                        g2 = (U8)((pBuf[nIn+j+1]&0x07e0)>>3);
                        r2 = (U8)((pBuf[nIn+j+1]&0xf800)>>8);
                        val = (int)((77*r2 + 150*g2 + 29*b2)/256);
                        y2=((val>255) ? 255 : ((val<0) ? 0 : val)); 
                        val = (int)(((-44*r2 - 87*g2 + 131*b2)/256) + 128);
                        cb2=((val>255) ? 255 : ((val<0) ? 0 : val)); 
                        val = (int)(((131*r2 - 110*g2 - 21*b2)/256) + 128);
                        cr2=((val>255) ? 255 : ((val<0) ? 0 : val));  

                        pBuf[nIn+j] = (U16)(y1<<8 | ((cb1+cb2)/2));
                        pBuf[nIn+j+1] = (U16)(y2<<8 | ((cr1+cr2)/2));
                }
        }
}

I removed it for the following reasons: 1. It is not formatted (yes I could fix that) 2. While wikipedia does have algorithms, there doesn't seem to be any great amount of completed program code. Does it belong here? 3. Wasn't in the right part of the article. 4. RGB565 should be defined, linked etc. As it is a representation rather than a color space, it isn't likely to be a familiar term even to color scientists, unless they happen to work with this format. 5. The code is not self-contained; it relies on external definitions, not included, like U8 and U16.

Comments?

Notinasnaid 08:06, 10 August 2005 (UTC)

I've formatted it by adding spaces at the start of each line (which turn off normal line wrapping, and force a special raw text display format). I agree: Wikipedia articles should not contain code unless they are about algorithms. An equation is more appropriate here. -- The Anome 08:13, August 10, 2005 (UTC)

Can you explain me what language does this code example (fixed-point approximation) uses? If this is C/C++ what is := operator? If this is pascal what >> operator?

Pekka Lehtikoski: Language is C, please refer to "The C Programming Language, Kernighan & Ritchie, ISBN 0-13-110370-9". This kind of nit picking will take us nowhere, at least it will not make wikipedia better. As far this is best we got, let's publish it. Until when and if someone contributes improved or new version on the topic. About the code: I see no problem in incuding code samples within wikipedia, maybe not in main article, but linked to it. I would think that this would make wikipedia more useful to programmers, and would not hurt anyone else.

[edit] Oh, dear...

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. Denelson 83 04:42, 29 October 2005 (UTC)

[edit] YUV to RGB image misrepresenting the transformation

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)

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.

Animation of all the possible RGB colors in the YUV colorspace. Time is Y, X-axis is U and Y-axis is V. The black square delimits the (-0.5,-0.5)-(0.5,0.5) range.

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)

[edit] color

The article says,

standards such as NTSC reduce the amount of data consumed by the chrominance channels considerably, leaving the eye to extrapolate much of the color. NTSC saves only 11% of the original blue and 30% of the red. The green information is usually preserved in the Y channel. Therefore, the resulting U and V signals can be substantially compressed.

What does it mean to save X% of the original color? What is the source of this information? The article on NTSC doesn't even say this.

In the YIQ article, it says that broadcast NTSC limits I to 1.3 MHz, Q to 0.4 MHz, and Y to 4 MHz. That's where the percentages come from, though it's rather simplistic to map YIQ directly to RGB. Having less bandwidth is like having a smaller number of colors, if I understand correctly. - mako 00:41, 24 March 2006 (UTC)

Not necessarily a smaller number of colors. It could be a smaller number of chroma pixels per field, which is indeed an aspect of the NTSC format.

Your phrase "rather simplistic" is a euphemism for "inaccurate".

[edit] Fixed point approximation

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)

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)

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)

Maybe the code is not intended to please 'color scientists', but I can guarantee that if you download a YUV sequence from the internet, well, this kind of demapping is what makes the sequence to be seen on the screen with decent colors. --Cantalamessa 15:03, 31 May 2006 (UTC)

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)

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)

Notinasnaid, please don't misunderstand me: I don't want to struggle against you at all! For the input and output ranges, they are defined in the BT.601 recommendation, as per the second line of comment (YUV means BT.601 in almost 90% of the downloadable sequences). Major details to be found in YCbCr. --Cantalamessa 23:50, 31 May 2006 (UTC)

Ah, this is interesting stuff. According to[1], BT.601 is based on YCbCr, which as this article says '...is sometimes inaccurately called "YUV".' Notinasnaid 08:31, 1 June 2006 (UTC)

The problem with "YUV" is that it is a term that is used incorrectly pretty much by everyone. Y'UV is the analog system used for PAL video similar to Y'IQ for NTSC. Things like YUV 4:4:4, and YUV 4:2:0 are incorrect terms. YUV in this case is referring to Y'CbCr digital video. YUV is just being used incorrectly by everyone, and thus causing much confusion. Read [2] for more information.

Pekka Lehtikoski: Most readers of YUV-RDB conversions are programmers, and practical code by Cantalmessa is most appreciated. It should be in the main article, or linked clearly to it.

[edit] Exact numbers

I noticed the original RGB-to-YUV matrix $\begin{bmatrix} 0.299 & 0.587 & 0.114 \\ -0.147 & -0.289 & 0.436 \\ 0.615 & -0.515 & -0.100 \end{bmatrix}$ is rounded to 3 decimal places, and the YUV-to-RGB matrix $\begin{bmatrix} 1 & -0.000039457070707 & 1.139827967171717 \\ 1 & -0.394610164141414 & -0.580500315656566 \\ 1 & 2.031999684343434 & -0.000481376262626 \end{bmatrix}$

is the exact matrix-inverse of the first matrix, but displayed using all decimals. As you can see, elements 0,1 and 2,2 are all zeros up to the 4th decimal place. Because of this, I thought maybe these elements ought to have been 0 and some elements in the RGB-to-YUV matrix in the 2nd and 3rd row should be more accurate than 3 decimal places.

--Zom-B 07:45, 8 Sep 2006 (UTC)

Using a formula slightly different from the one on the YCbCr page I managed to find the exact values of the first matrix.

$Y =$	$+$	$0.299$	$R +$	$0.587$	$G +$	$0.114$	$B$
$U = 0.436(B - Y) / (1 - 0.114) =$	$-$	$0.1471376975169300226$	$R -$	$0.2888623024830699774$	$G +$	$0.436$	$B$
$V = 0.615(R - Y) / (1 - 0.299) =$	$+$	$0.615$	$R -$	$0.5149857346647646220$	$G -$	$0.1000142653352353780$	$B$

In matrix form:

$\begin{bmatrix} 0.299 & 0.587 & 0.114 \\ -0.1471376975169300226 & -0.2888623024830699774 & 0.436 \\ 0.615 & -0.5149857346647646220 & -0.1000142653352353780 \end{bmatrix}$