CINXE.COM
YUV to RGB Conversion
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta name="viewport" content="width=device-width,initial-scale=1"> <link rel="canonical" href="/fccyvrgb.php"> <title>YUV to RGB Conversion</title> <meta name="keywords" content="video, codec, pixel format, FOURCC, fourc character code, multimedia, compress, decompress, download"> <meta name="description" content="FOURCC.org contains definitions of a large number of PC video codecs and pixel formats. Where available, download links are provided."> <link href="/styles/fcc.css?v=1.0.3" rel="stylesheet" media="screen"> <link href="/styles/fcc_narrow.css?v=1.0.3" rel="stylesheet" media="screen and (max-width: 700px)"> <link href="/styles/jqdt_table.css?v=1.0.3" rel="stylesheet" media="screen"> <link rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/cookieconsent@3/build/cookieconsent.min.css"> </head> <body> <div class="page_segment"> <div class="page_content nopadding"> <div class="theader"> <a href="/"><img src="/images/fourcc.png" border="0" alt="FOURCC.org - Video Codecs and Pixel Formats" title="FOURCC.org - Video Codecs and Pixel Formats"></a> </div> </div> </div> <div class="page_segment menu"> <div class="page_content nopadding"> <div class="tleft collapsed"> <div class="narrow_expander"> <a href=""><img src="/images/open_menu.png" style="width:24px;height:24px;" alt="Open menu"></a> </div> <div class="menu collapsed"> <div class="header"> ESSENTIALS ∨ </div> <ul style="left:-0px;"> <li><a href="/fourcc.php">What is a FOURCC?</a></li> <li><a href="/codecs.php">Codecs by FOURCC</a></li> <li><a href="/identifier/">Identify by FOURCC</a></li> <li><a href="/downloads/">Download video codecs</a></li> <li><a href="/forum/">Q&A Forum</a></li> </ul> </div> <div class="menu collapsed"> <div class="header"> TECHNICAL ∨ </div> <ul style="left:-200px;"> <li><a href="/rgb.php">RGB Formats</a></li> <li><a href="/yuv.php">YUV Formats</a></li> <li><a href="/chips.php">Graphics Chips</a></li> <li><a href="/samples.php">Sample Code</a></li> </ul> </div> <div class="menu collapsed"> <div class="header"> SITE ∨ </div> <ul style="left:-400px;"> <li><a href="/reg.php">FOURCC Registration</a></li> <li><a href="/help.php">Help me out</a></li> <li><a href="/credits.php">Site Credits</a></li> <li><a href="/users/login.php">Log in</a></li> <li><a href="/users/signup.php">Sign up</a></li> <li><a href="/privacy.php">Privacy Policy</a></li> </ul> </div> <div style="clear:left;"></div> </div> </div> </div> <div class="page_segment"> <div class="page_content"> <div class="breadcrumbs"> <a href="/">Home</a> >> </div> <h1>YUV to RGB Conversion</h1> <p align="left">I recently received an email from Mike Perry thoroughly explaining this whole issue. For the definitive answer, <a href="#mikes_answer">please look here</a>. If you want my original posting, here it is...</p> <p align="left">Conversion back and forward between RGB and YUV formats is a topic that often causes confusion - are we dealing with gamma corrected RGB values? Which luminance/chrominance colour space are we actually dealing with ? Why can't someone just tell me how to do the conversion without giving me 5 chapters of theory first!</p> <p align="left">To cut a long story short, here are the formulae that I have used to do the conversions for PC video applications (well, OK, these are not exactly the formulae I used but I did generate a bunch of lookup tables from these). The colour space in question is actually YC<sub>b</sub>C<sub>r</sub> and not YUV, which a video purist will tell you is, in fact, the colour scheme employed in PAL TV systems and is somewhat different (NTSC TVs use YIQ which is different again). Why the PC video fraternity adopted the term YUV is a mystery but I strongly suspect that it has something to do with not having to type subscripts.</p> <p align="left">The following 2 sets of formulae are taken from information from Keith Jack's excellent book "Video Demystified" (ISBN 1-878707-09-4).</p> </div> </div> <div class="page_segment alternate"> <div class="page_content"> <h2 align="left">RGB to YUV Conversion</h2> <blockquote> <pre>Y = (0.257 * R) + (0.504 * G) + (0.098 * B) + 16 Cr = V = (0.439 * R) - (0.368 * G) - (0.071 * B) + 128 Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128 </pre> </blockquote> </div> </div> <div class="page_segment"> <div class="page_content"> <h2 align="left">YUV to RGB Conversion</h2> <blockquote> <pre>B = 1.164(Y - 16) + 2.018(U - 128) G = 1.164(Y - 16) - 0.813(V - 128) - 0.391(U - 128) R = 1.164(Y - 16) + 1.596(V - 128)</pre> </blockquote> <p align="left">In both these cases, you have to clamp the output values to keep them in the [0-255] range. Rumour has it that the valid range is actually a subset of [0-255] (I've seen an RGB range of [16-235] mentioned) but clamping the values into [0-255] seems to produce acceptable results to me.</p> </div> </div> <div class="page_segment alternate"> <div class="page_content"> <h2 align="left">Further Information</h2> <p align="left"><a href="/cdn-cgi/l/email-protection#f1829a9087949f85838492b18890999e9edf9783">Julien</a> (surname unknown) suggests that there are problems with the above formulae and suggests the following instead:</p> <blockquote> <pre>Y = 0.299R + 0.587G + 0.114B U'= (B-Y)*0.565 V'= (R-Y)*0.713</pre> </blockquote> <p align="left">with reciprocal versions:</p> <blockquote> <pre>R = Y + 1.403V' G = Y - 0.344U' - 0.714V' B = Y + 1.770U'</pre> </blockquote> <p align="left">Scott Scriven has recently sent me a C program he wrote to convert Quantel YUV files as generated by SGI's "ZapIt!" video capture software into RGB PPM files. You can <a href="yuv2ppm.c" target="_blank">get hold of the source by clicking here</a>. Please <a href="/cdn-cgi/l/email-protection#3b4f5442505e5e4b5e497b58535e5e495d4e5715585456">contact Scott</a> with any support questions on this program.</p> <p align="left">Intel actually has an extensive web site on the topic of colour space conversion and you can find it here.</p> </div> </div> <div class="page_segment"> <div class="page_content"> <h2 align="left"><a name="mikes_answer" id="mikes_answer"></a>Mike Perry's Definitive Answer to the Conversion Question</h2> <p align="left">"I looked at your RGB/YUV page again and it still contains extremely "iffy" wording as if no-one knows what the heck is really the correct way to do conversion. There are two specifications, CCIR 656 and CCIR 601 which define standards for component video, and I'm sure other pages on your site refer to them. In any case, CCIR 601 defines the relationship between YCrCb and RGB values:</p> <p align="left">Ey = 0.299R+0.587G+0.114B<br> Ecr = 0.713(R - Ey) = 0.500R-0.419G-0.081B<br> Ecb = 0.564(B - Ey) = -0.169R-0.331G+0.500B</p> <p align="left">where Ey, R, G and B are in the range [0,1] and Ecr and Ecb are in the range [-0.5,0.5] <a href="#BOURGEOIS">(Equations corrected per input from Stephan Bourgeois and Gregory Smith below)</a></p> <p align="left">If you form a matrix with those coefficients and compute the inverse you get coefficients equivalent to what Julien suggested.</p> <p align="left">The reason your first set of coefficients is incorrect, and related to your clamping comment, is because the defined range for Y is [16,235] (220 steps) and the valid ranges for Cr and Cb are [16,239] (235 steps) These are normalized ranges and when the data is used, 16 is added to Y and 128 is added from Cr and Cb to de-normalize them. The reason for this is that control and colorburst information is stored in the components along with the luminence and chromiance data which is why the full range of [0,255] is not used. There is no "rumor" about this being correct. It is a defined standard for YCrCb video. I wouldn't be surprised if certain PC programs are using a variant where the entire range of [0,255] is used but technically it is not YCrCb. If you use YCrCb for video purposes, its probably going to be CCIR 601 compliant. I don't know why you would use YCrCb for anything else as many rendering operations are extremely expensive to do in the non-linear YCrCb color space relative to the linear RGB color space.</p> <p align="left">Most importantly, you should probably mention that there are more efficient ways of converting from YCrCb to RGB than just doing a straightforward implementation of the floating point matrix multiplication.</p> <p align="left">First, the input values YCrCb component values you are given may not even be valid within the YCrCb color space. This can occur if the components were obtained by converting from another color space (usually RGB). This places additional overhead to implement a pre-clamp phase and to also to possibly normalize the component values if they arent normalized already (subtract 16 from Y, subtract 128 from Cr and Cb, divide by 219 or 235 to obtain normalized ranges). You can reduce this overhead to a minimum by creating two 256-entry lookups which contain pre-converted-and-clamped results for input values in the range 0-255. You need one table for luminance and one table for chromiance.</p> <p align="left">Second, floating point operations are usually much slower than integer operations, at least when it comes to most C compilers which do very poor instruction scheduling. Speed might not be important if you are converting static data "offline," but floating point is a killer if you're trying to do software conversion of YCrCb frame buffers. I do my conversion using 2.14 fixed point representation stored in 32 bit integers. You can use any number of fraction bits that you want but my target system (the Nuon) has pixel pack and unpack operations which treat the values as 2.14. You certainly don't need any more than 2 integer bits as you only care about the range [-2.0,2.0]. You can precalculate the normalize-and-clamp lookup tables to contain fixed point values so that the first stage is consists solely of three lookups.</p> <p align="left">At that point you do the equivalent matrix multiply steps except that you use fixed point instead of floating point. This is gobs faster than using floating point operations. After the conversion you have obtained R, G, and B. You then need to do another series of clamps to ensure everything is in the range [0,1]. If you get your coefficients just right, you probably shouldn't need to do this, but its rather difficult to ensure that underflow and overflow wont occur. If a component is not clamped, you need to obtain the scaled value using a fixed point multiply, usually by 255 if you're trying to convert to 8-bit component values.</p> <p align="left">Also, its important to note that if you are only interested in luminance data (for the purposes of creating a greyscale image) then the RGB triple for YCrCb is simply (Ey,Ey,Ey) and you don't have to do the matrix calculation nor post-clamping and you only have to scale one value. Simply run Y through the luminance lookup table, scale to [0,255] and plug into R, G and B.</p> <p align="left">I am looking into the possibility of using overlay channels to bypass software conversion altogether, although my emulated system (Nuon) has two channels (main + overlay) with alpha blending capabilities so I would only be able to use this mechanism when only one screen is active and I would lose chromiance information unless hardware vendors start implementing unpacked YCrCb instead of YUY2. Another interesting method of doing YUV to RGB conversion for the purpose of displaying video is to use programmable pixel shaders. You can almost pull it off on a Geforce3 but the GeforceFX and Radeon 9700/9800 cards are advanced enough that you can pass 32 bit YCrCb textures to the video card and do all conversion calculations on the video card. Using multi-texturing you can even do main channel and overlay channel alpha blending in one pass. Given that converting a single 720x480 32-bit YCrCb frame buffer at 60 frames per second takes up about 25% of my xp2800+ CPU time, this would be a very cool thing indeed."</p> </div> </div> <div class="page_segment alternate"> <div class="page_content"> <h2 align="left"><a name="BOURGEOIS" id="BOURGEOIS"></a>Further Input from Stephan Bourgeois:</h2>In Mike Perry's Section, the conversion matrix should be : <p>Ey = 0.299R + 0.587G + 0.114B<br> Ecr = 0.713(R - Ey) = 0.500R - 0.419G - 0.081B<br> Ecb = 0.564(B - Er) = -0.169R - 0.331G + 0.500B <i>(Gregory Smith points out that Er here should read Ey - equations above were corrected)</i></p> <p>there is a minus sign missing in the R->Cb coefficient, and a digit 3 missing in G->Cb.</p> <p>Also I disagree with Mike on the idea that Y is "normalized" by adding 16. If RGB=[255,255,255], the equations would give Y=255+16. Y should be clamped at 16 to prevent sub-black, the same way as it should be clamped at 235 to prevent white>100%. This can be done by the use of a 256 entry lookup table.</p> </div> </div> <div class="page_segment"> <div class="page_content"> <h2>Avery Lee's JFIF Clarification</h2> <p>"The equations you have from "Video Demystified" are the ones to use most of the time on PCs, such as for MPEG-1 decoding and handing most (all?) of the formats on the YUV FOURCC page. However, there is one notable exception: JPEG. The JFIF file format that is commonly used with JPEG defines a YCbCr color space that is slightly different than usual, in that all components have the full [0,255] excursion rather than [16,235] and [16,240]. The equations given by "Julien" are for this variant and are very close to the ones in JFIF:</p> <p>R = Y + 1.402 (Cr-128)<br></p> <p>G = Y - 0.34414 (Cb-128) - 0.71414 (Cr-128)<br></p> <p>B = Y + 1.772 (Cb-128)</p> <p>It should be noted that some Motion JPEG codecs don't take this consideration into account and improperly exchange YCbCr values between the YUY2 and UYVY formats and their internal JPEG planes without performing the necessary scaling. This results in contrast shifts when using YUV formats."</p> </div> </div> <div class="page_segment alternate"> <div class="page_content"> <h2>Microsoft's Answer</h2> <p>MSDN also has an answer to this question. You can find it here.</p> </div> </div> <div class="page_segment"> <div class="page_content"> <h2>Want some sample code?</h2> <p>Peter Bengtsson recently sent <a href="source/YUV420P-OpenGL-GLSLang.c">code for a sample program</a> showing how to perform YCrCb to RGB conversion with a Fragment Shader (Pixel Shader) in OpenGL. He says that it is tested on Linux but should be usable on Windows with only minor rework. Please contact him directly (tesla at och dot nu) with questions or comments.</p> <h2>The Thorny Issue of HD Video</h2> <p>Just when you thought things were quietening down, Richard Salmon correctly points out that the YCrCb colour space used for HD video (ITU.BT-709) is actually different from SD (ITU.BT-601). He adds:</p> <p>"Found your page, and I'm afraid, even with Mike Perry's explanation, which covers the problems of coding ranges and black/white offsets in the digital coding of TV signals etc very well, it is still lacking;</p> <p>In addition to the YUV/RGB equations relating to Rec.601 (which are used for Standard Definition TV) there are another completely different set adopted for HDTV (ITU Rec.709). This change of equation was entirely pointless, but unfortunately we have to live with it, since it is the internationally agreed standard. You will find the information on this at:</p> <p>http://www.dcs.ed.ac.uk/home/mxr/gfx/faqs/colorconv.faq"</p> <p align="left"></p> </div> </div> <div class="page_segment alternate"> <div class="page_content nopadding"> <p class="footer">fourcc.org ©2011-2023 Silicon.dk ApS<br> <strong>ESSENTIALS:</strong> [<a href="/fourcc.php">FOURCC?</a>] [<a href="/codecs.php">Video Codecs by FOURCC</a>] [<a href="/identifier/">Identify by FOURCC</a>] [<a href="/downloads/">Download codecs</a>] [<a href="/forum/">Q&A Forum</a>]<br> <strong>TECHNICAL:</strong> [<a href="/rgb.php">RGB Formats</a>] [<a href="/yuv.php">YUV Formats</a>] [<a href="/chips.php">Graphics Chips</a>] [<a href="/samples.php">Sample Code</a>]<br> <strong>SITE:</strong> [<a href="/reg.php">FOURCC Registration</a>] [<a href="/help.php">Help me out</a>] [<a href="/credits.php">Site Credits</a>] [<a href="/users/login.php">Log in</a>] [<a href="/users/signup.php">Sign up</a>] [<a href="/privacy.php">Privacy Policy</a>]<br></p> </div> </div> <script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script><script type="text/javascript" src="/js/jquery-1.4.2.min.js"></script> <script type="text/javascript" src="/js/jquery.dataTables.min.js"></script> <script type="text/javascript" src="/js/fcc.js"></script> <script> (function() { /* handle expand/collapse tap in narrow layout */ var button = document.querySelector('.tleft .narrow_expander a'); button.onclick = function(e) { menu.closest('.tleft').classList.toggle('collapsed'); return false; }; /* handle mouseover full width layout */ var menus = document.querySelectorAll('.tleft .menu'); for (var i = 0; i < menus.length; i++) { var menu = menus[i]; (function (menu) { //TODO: how to support devices without mouseover?!?! menu.onmouseenter = function(e) { menu.classList.remove("collapsed"); }; menu.onmouseleave = function(e) { menu.classList.add("collapsed"); }; }) (menu) } })(); </script> <script src="https://cdn.jsdelivr.net/npm/cookieconsent@3/build/cookieconsent.min.js" data-cfasync="false"></script> <script> window.cookieconsent.initialise({ "palette": { "popup": { "background": "#000" }, "button": { "background": "#f1d600" } }, "content": { "href": "https://fourcc.org/privacy.php" } }); </script> </body> </html>