VideoHelp Forum
+ Reply to Thread
Results 1 to 22 of 22
Thread
  1. Chicken McNewblet
    Join Date
    Sep 2009
    Location
    United States
    Search Comp PM
    I understand that RGB is red-green-blue and YCbCr is luma-chroma-chroma, obviously.

    But in a purely mathematical context (and assuming other common factors like bit depth), are YCbCr 4:4:4 and RGB more or less identical?

    I work with audio and one of the staple characteristics of lossless audio is that if you have waveforms 1, 2, and 3, and you mix them all together, you can retrieve a mix of 2-3 if you null 1-2-3 with waveform 1, and you can do this until the cows come home - it doesn't matter how the waveforms are mixed together. This is of course working within the confines of LPCM 44.1/16 audio.

    Would this concept hold true for video? Meaning that mathematically you could convert YCbCr 4:4:4 and RGB between each other all day and never suffer quality loss? Or is there a fundamental mathematical difference in the color spaces used?
    Quote Quote  
  2. Not all YCbCr values have a valid representation in RGB. There are values that result in "negative" RGB values, which get discarded. If you look at the color cube representation, the YCbCr color model is "larger" than the RGB model, values lie outside of RGB

    https://software.intel.com/en-us/node/503873
    Image Attached Thumbnails Click image for larger version

Name:	0EF01A88-F874-4ECB-B2B6-3ADC38636CD4-imageId=FE9BEAD5-12E5-4244-80E1-E61EB8211A76.jpg
Views:	3074
Size:	29.5 KB
ID:	43131  

    Quote Quote  
  3. Chicken McNewblet
    Join Date
    Sep 2009
    Location
    United States
    Search Comp PM
    Out of curiosity, what do negative values look like visually when you do that conversion anyway? Does it just result in white/black clipping?
    Quote Quote  
  4. That also means that limited range 8 bit YUV has only 1/6 as many different colors compared to 8-bit RGB. Ie, on average, 6 slightly different RGB values map to the same YUV value. This is why banding and posterization are much more of an issue with YUV.

    What the illegal YUV colors look like depends on the conversion algorithm. Most just clamp at the edges now. A long time ago there were some which "wrapped around". That is, intensity 256 would wrap around to 0, 257 to one, etc. Or -1 would wrap to 255, -2 to 254, etc.
    Last edited by jagabo; 16th Sep 2017 at 14:12.
    Quote Quote  
  5. Originally Posted by CursedLemon View Post
    Out of curiosity, what do negative values look like visually when you do that conversion anyway? Does it just result in white/black clipping?
    Typically, yes.

    (But some programs can use float values or different intermediate color models to "hold" those "invalid" values, instead of clipping)
    Quote Quote  
  6. Chicken McNewblet
    Join Date
    Sep 2009
    Location
    United States
    Search Comp PM
    Originally Posted by jagabo View Post
    That also means that limited range 8 bit YUV has only 1/6 as many different colors compared to 8-bit RGB. Ie, on average, 6 slightly different RGB values map to the same YUV value. This is why banding and posterization are much more of an issue with YUV.
    I'm assuming that the color space's bit depth and color gamut are different concepts and that the limitations between YUV and RGB would still apply, yeah?
    Quote Quote  
  7. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    Gamut is the "universe" of valid colors & brightness values that can be described by apps using color models/methods/spaces, and counted to a degree of accuracy/fineness determined by the bit depth.

    So, yes, the difference in those relationships still applies.

    Scott
    Quote Quote  
  8. Originally Posted by CursedLemon View Post
    But in a purely mathematical context
    Yes, they are identical (IOW, one can losslessly convert between the two) if one uses floating point or 32-bit RGB and the out-of-gamut values (those values that fall outside the cube in the posted pic by pdr) are internally preserved which is the color science that most compositing programs (e.g. AE, DR, etc.) operate in. Of course, the problem with out-of-gamut values is there is no way to display them on your 'puter screen which is always RGB. Therefore, RGB triads that contain values outside 0-255 will be clipped accordingly. This is one of the many reason colorists use monitors that can display a true YCbCr signal thus bypassing the gpu RGB conversion.

    But bear in mind, you are talking about YCbCr 4:4:4 which is very rarely used. The more common format even in a pro camera is 4:2:2. So one has to also deal with the chroma subsampling upscaling which is never lossless because there is no 4:2:2 analog for RGB.
    Quote Quote  
  9. Originally Posted by CursedLemon View Post
    Out of curiosity, what do negative values look like visually when you do that conversion anyway? Does it just result in white/black clipping?
    It depends - some things already pointed by others - calculations are one topic, practical HW design is other topic - nowadays it usually not a problem but in past some glitches in analog video signal can be observed and measured - some systems use higher bitdepth DAC's to deal with complex nature of video signal (many standards, flexibility etc) - with some signal combinations such DAC can recreate negative (undershoot) and positive (overshoot) glitches and this is something else but similar to "normal" DAC glitches (it is usually related to logic issue not DAC itself as DAC can be designed and made to be "glitch free").
    Quote Quote  
  10. Originally Posted by SameSelf View Post
    This is one of the many reason colorists use monitors that can display a true YCbCr signal thus bypassing the gpu RGB conversion.
    ? Can you elaborate more on this (AFAIK there is no display that can display YCbCr natively as all of them are RGB (there are other combinations but in principle all are RGB).
    Quote Quote  
  11. Originally Posted by SameSelf View Post
    This is one of the many reason colorists use monitors that can display a true YCbCr signal thus bypassing the gpu RGB conversion.
    Did you make that up?
    I was under the impression it works the other way around. Aren't PC's natively RGB? By outputting RGB, you're bypassing a GPU RGB to YCbCr conversion.... and the monitor having to convert it back to RGB. I'd imagine you'd also avoid a conversion to limited levels and back to full range too.
    Quote Quote  
  12. Member
    Join Date
    Aug 2010
    Location
    San Francisco, California
    Search PM
    Perhaps what was meant is YPbPr, better known as a component analog connection.
    Quote Quote  
  13. As YPbPr is analog representation for YCbCr so it is quite common (plenty of consumer displays support YPbPr).
    Quote Quote  
  14. Seems I have caused some confusion. No, I didn't make anything up regarding native YCbCr signals being passed to a monitor that supports such. These solutions are not cheap however. They require:

    1. Some sort of third party video processor that bypasses the cpu and either the onboard gpu or third party gpu. Examples include Blackmagic Design and Aja, even R3D. They do exactly what I described. Take the YCbCr video from an NLE and pass it untouched by the cpu or gpu to a monitor. This is critical because colorists want complete control of the signal and if you let the cpu or gpu touch it, there are no guarantees.
    2. Now, to actually see this sort of signal, you need a monitor that supports YCbCr signals. There are many examples of these, but they are rarely less than $1000.
    3. Sometimes, people use an external LUT box as well for even greater control.
    4. Also, these systems really require some sort of calibration solution.
    5. Lastly, many colorists also pass the signal to a plasma or some other high end TV.

    Just about every colorist and even editors operate like this. I am not sure why this is such a secret on a video enthusiast forum. If anyone here is truly interested, PM me and I will describe my setup.
    Last edited by SameSelf; 19th Sep 2017 at 21:50.
    Quote Quote  
  15. Originally Posted by SameSelf View Post
    Seems I have caused some confusion. No, I didn't make anything up regarding native YCbCr signals being passed to a monitor that supports such. These solutions are not cheap however.
    Even my cheap Benq LCD monitor supports YCbCr. I'd be astounded if there were many monitors with HDMI inputs that didn't support YCbCr.
    Not that I own an AMD video card, but I'm pretty sure for AMD the default output over HDMI is YCbCr.
    Quote Quote  
  16. Originally Posted by SameSelf View Post
    Seems I have caused some confusion. No, I didn't make anything up regarding native YCbCr signals being passed to a monitor that supports such. These solutions are not cheap however. They require:
    .
    .
    Just about every colorist and even editors operate like this. I am not sure why this is such a secret on a video enthusiast forum. If anyone here is truly interested, PM me and I will describe my setup.
    Well... seem issue in signal flow is operating system and unknown/unspecified signal processing inside display path and any dedicated solution define way how signal is processed or intentionally will not process signal and this make this unique and hype-pro expensive - my remark about displays was that by principle all of them are based on RGB colour model perhaps with some modifications related (perhaps) to addressing some technology limitation by adding definable RGB back-light and/or adding additional colours like yellow and/or magenta and sometimes adding white white (luma) pixels... But after all - all modern consumer grade devices are capable to display natively source YCbCr 4:4:4 (sometimes also 4:2:2 and 4:2:0) however internally they need use colour space conversion as display will be RGB by principle.
    Quote Quote  
  17. Chicken McNewblet
    Join Date
    Sep 2009
    Location
    United States
    Search Comp PM
    Originally Posted by SameSelf View Post
    Seems I have caused some confusion. No, I didn't make anything up regarding native YCbCr signals being passed to a monitor that supports such. These solutions are not cheap however. They require:

    1. Some sort of third party video processor that bypasses the cpu and either the onboard gpu or third party gpu. Examples include Blackmagic Design and Aja, even R3D. They do exactly what I described. Take the YCbCr video from an NLE and pass it untouched by the cpu or gpu to a monitor. This is critical because colorists want complete control of the signal and if you let the cpu or gpu touch it, there are no guarantees.
    2. Now, to actually see this sort of signal, you need a monitor that supports YCbCr signals. There are many examples of these, but they are rarely less than $1000.
    3. Sometimes, people use an external LUT box as well for even greater control.
    4. Also, these systems really require some sort of calibration solution.
    5. Lastly, many colorists also pass the signal to a plasma or some other high end TV.

    Just about every colorist and even editors operate like this. I am not sure why this is such a secret on a video enthusiast forum. If anyone here is truly interested, PM me and I will describe my setup.
    Don't all HDMI monitors accept YCbCr by default? They have to be displayed as RGB as well in the end, I'd also have to imagine.
    Quote Quote  
  18. To answer everyone's question, idk. I have already described the setup nearly every colorist uses. I don't know of anyone that uses an AMD/nVidia based signal path. I would be very skeptical of the integrity of such a path because Y'CbCr also includes Rec.709, 10-bit, and so on. Gaming cards and even Quadro/FirePro just aren't built for that sort of use.
    Quote Quote  
  19. You still haven't explained what's special about the monitors you claimed can display a YCbCr signal, because they all seem to have red green and blue pixels. That's the question you didn't answer while answering everyone's questions, even though it's the one being asked.
    Quote Quote  
  20. Yes virtually all displays are RGB. If you have a YCbCr signal it's being converted somewhere to RGB. I think that's his point, about controlling the conversion. The difference with those pricey displays are calibration, bit depth, and built in LUT support

    When people say "RGB" - most people are actually referring to "sRGB" or "standard" RGB. But there are different variations of "RGB" based models, and different equations and "mapping" between YCbCr and the "RGB" derivative model. For example, Adobe RGB, studio RGB (not sRGB), Pro Photo RGB. Another is "wide gamut RGB" (which is a Rec1361 derivative or xv-ycc) , which handles what would normally result in negative RGB values. When displayed on a wide gamut display you can actually "see" those colors that would have been normally discarded or clipped

    $5-30K production monitors do accept YCbCr signals through HD-SDI/3G-SDI, or even HDMI - but the display is still RGB . You're not "seeing" a YCbCr pixel, you're seeing RGB. There still is a conversion somewhere, either through hardware or software . Most modern production monitors have built in HW LUT support for DCI P3 , Rec 2020 , 709 . 99% are still 10bit (only), but a few are 12bit, so these are viewing LUT's not grading LUT's. But that's the point - the colorist wants control over everything. A cheapo monitor won't support DCI P3 (you need it for film out) . Sometimes footage is is shot in log for example - that's why you need LUT support and control - you can't display it properly without LUT support

    Also not all inputs are YCbCr . Higher budget productions don't even use YCbCr for acquisition at all - it's only for delivery or farther down the pipeline. These days, raw is used for acquisition. Only for TV / episodic shows/ ENG - with fast turnaround requirements use something like prores HQ in YCbCr . In the past , and to some extent even today, filmscans (from actual celluloid) were 16bit TIFF or SGI, and the "intermediate" was cineon/dpx (which are "only" 10bit) - but all RGB. These days, EXR is used when higher end digital effects and compositing is required (still RGB) .
    Quote Quote  
  21. I was secretly hoping pdr would weigh in on this. Couldn't have said it better myself. TAA
    Quote Quote  
  22. So virtually any monitor can display a YCbCr signal, even when they cost far less than $1000, and more expensive monitors have more features, none of which is directly connected to an ability to accept a YCbCr input, and they all convert YCbCr to RGB.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!