Is there an actual difference between YCbCr (YUV?) 4:4:4 and RGB?

[CursedLemon]

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?

[poisondeathray]

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

[CursedLemon]

Out of curiosity, what do negative values look like visually when you do that conversion anyway? Does it just result in white/black clipping?

[jagabo]

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.

[poisondeathray]

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)

[CursedLemon]

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?

[Cornucopia]

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

[SameSelf]

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.

[pandy]

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

[pandy]

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

[hello_hello]

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.

[JVRaines]

Perhaps what was meant is YPbPr, better known as a component analog connection.

[pandy]

As YPbPr is analog representation for YCbCr so it is quite common (plenty of consumer displays support YPbPr).

[SameSelf]

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.

[hello_hello]

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.

[pandy]

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.

[CursedLemon]

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.

[SameSelf]

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.

[hello_hello]

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.

[poisondeathray]

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

[SameSelf]

I was secretly hoping pdr would weigh in on this. Couldn't have said it better myself. TAA

[hello_hello]

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.