YCbCr v RGB, Which color space is bible?

YCbCr v RGB, Which color space is bible?

Postby Joel Barsotti » Mon Apr 12, 2010 10:04 pm

I've recently begun playing with converting YCbCr values back and forth to RGB.

My understanding is the Y channel has valid values from 16-235 and the Chroma channels have valid values from 16-240. When you transform these values from YCbCr to RGB, many of these legal values fall outside of the 16-235 range. I've seen that you've written that StudioRGB is composed from the different combinations of 16-235 steps for each R,G,B channel.

If what gets encoded on BD or DVD should only be studio RGB, then clipping above 235 in the RGB space shouldn't remove any valid image data. If source for the YCbCr data includes full range information, then you could still encode it in a way that produced only legal YCrCb data, but would be transformed to values that exceed 235 in RGB.

Do the guidelines for content creation specify that only valid StudioRGB values be encoded to YCrCb, or is it only the validity of the resultant YCbCr value important?
SpectraCal Developer
User avatar
Joel Barsotti
Site Admin
 
Posts: 3707
Joined: Thu Dec 03, 2009 12:11 pm
Location: Seattle, WA

Re: YCbCr v RGB, Which color space is bible?

Postby ChrisWiggles » Tue Apr 13, 2010 11:21 am

As far as disc-based media goes, I regularly encounter content that exceeds 235 in R'G'B' and there is no good reason why a studio would want to impose a hard clip right at 235 in R'G'B'. There is nothing gained by that, and the entire 1-254 range is allocated for video. For many reasons you don't want black and white at the extremes of signal ranges.

As we've moved to digital displays that don't really float around in black level as a CRT does, there is less need for anything below 16 in my opinion, because for most black level alignments in a proper environment, you will align the display's black point right at 16. There is still some minimal impact on any video processing in the chain, but I think it would be fair to characterize those impacts as pretty insignificant to the viewer, even a very critical viewer.

However, the question of where to align a display's white point is a little bit more elusive. A CRT doesn't really have a white point per se, you are mainly trying to target an appropriate luminance and simply ensure that this level is below where the electron beam loses focus, and sometimes you're also trying to stay below where geometry distorts(sometimes irrelevant because many cheap consumer CRTs were always distorted, and some high-end/professional CRTs never distorted no matter how high you went.). So with a CRT, you see everything up to 254 if there are values that go that high.

With a digital display of limited on/off CR, you are actually trying to do something different in setting black level and white level to maximize all of the available on/off CR that you can on the display. You want the black level of the display to be aligned right at 16 of the incoming signal, and then you want the display's peak white level aligned to the display's incoming white level. This begs the question of what the incoming white level is, because the incoming content has a "reference white" at 235, but it could extend all the way up to 254 which I regard as the "peak white." I always align the display to 254, or the peak white. This ensures that if there is any excursion beyond 235 (which I find to be extremely common, at least a little bit higher than 235) that it isn't clipped off. However, this sacrifices a little bit of on/off CR between the reference white point and black, and a little bit of luminance for white. So some might compromise a little bit and clip off a little bit of the peak white range above 235. And while there is frequently excursion above 235, well mastered content has the bulk of white right around 235, so there is an argument to be made that clipping off a little bit of the peak whites, or even all the way down to 235 doesn't sacrifice much. I don't like that argument, and in some cases it is certainly visible when you clip to 235 so I don't do it.
ChrisWiggles
New User
 
Posts: 1
Joined: Sat Mar 07, 2009 10:24 pm

Re: YCbCr v RGB, Which color space is bible?

Postby Charles Poynton » Wed Apr 28, 2010 7:38 pm

Joel -

You write,

Y channel has valid values from 16-235 and the Chroma channels have valid values from 16-240.

The term “valid” was invented two decades ago by Tektronix. In the Glossary for DVAI, I describe “valid” as

The condition where a video signal is R’G’B’-legal – that is, where none of the corresponding R’, G’, and B’ signals exceeds its reference range.

In the next edition (forthcoming!), I will append “except perhaps for brief transients.” In any event, owing to emergent xvYCC coding, the term is now questionable.

Best to think of reference black and reference white codes originating with R’G’B’ abstract values 0 and 1 respectively. Upon coding into 8-bit integers across the interface, the reference luma levels (instead of “valid” levels) are 16 and 235. I recommend that studio equipment and consumer equipment allow excursions down into the footroom and up into the headroom regions, that is, down to 1 and up to 254 in 8-bit space. (10-bit video should run 4 ... 1019 inclusive, with luma reference codes 64 and 940.) Chroma reference codes are 16 and 240 in 8-bit space (that is, 64 and 960 in 10-bit space).

I’ll write about clipping in June's Vector issue, but the short story is that I have consulted a dozen of my studio colleagues and all agree that no clipping should take place - transients into footroom and headroom should be preserved as long as possible (as ChrisWiggles has posted here). BUT - many post-production facilities are nervous that not-completely-clueful QC operations will reject any material that has excursions into these regions, and rather than fight, the post houses cave, and clip, knowing that they shouldn’t.

Stay tuned, though - wide-gamut is coming. When an appreciable number of studios take interest, then clipping has to stop.

- Charles
Charles Poynton
Calibration Soldier
 
Posts: 27
Joined: Wed Apr 07, 2010 2:16 pm
Location: Toronto, Ontario, Canada

Re: YCbCr v RGB, Which color space is bible?

Postby madshi » Thu Jul 22, 2010 8:48 am

Charles Poynton wrote:Chroma reference codes are 16 and 240 in 8-bit space (that is, 64 and 960 in 10-bit space).

I'm a bit late to the party, sorry about that.

I'm wondering if 64 and 960 are really the correct numbers for 10bit? The reason is this:

If you want to process video data in the highest possible quality, you will convert it to floating point first. If you convert 8bit to float, you will probably do 0 -> 0.0 and 255 -> 1.0, right? So basically you're dividing all data by 255. If you go back to 8bit, you will consequently multiply by 255 again (and hopefully do dither + round). Which means that if you go to 10bit, you should probably multiply by 1023. As a result 240 in 8bit would equal ~ 962.8 in 10bit.

This is also what Direct3D does. If you feed it with 8bit cardinal data, it converts 0 to 0.0 and 255 to 1.0.

Or let's look at it from a different angle: If you simply multiply by 4.0, then when converting 8bit data to 10bit, the max value you will get is 255 * 4 = 1020. So 1021-1023 would be unused/wasted.

So shouldn't the proper values for 10bit Chroma be 16/255*1023 and 240/255*1023? What do you think?
madshi
Calibration Soldier
 
Posts: 55
Joined: Mon Nov 16, 2009 3:41 pm

Re: YCbCr v RGB, Which color space is bible?

Postby Joel Barsotti » Thu Jul 22, 2010 10:18 am

madshi wrote:
Charles Poynton wrote:
So shouldn't the proper values for 10bit Chroma be 16/255*1023 and 240/255*1023? What do you think?


235/255 = .9215 * 1023 =942, but....

They just want to make it easy to do quickly, converting everything to floating point and chewing throught that much data wasn't something that could be reasonably done when the spec was implemented (often times sub optimal solutions are used, due to computational limitations). So they simply pad the values.

16 = 0001 0000
64 = 00 0100 0000

235 = 1110 1011
940 = 11 1010 1100

They simply pad the 8bit number with two trailing zeros to convert to 8bit space. It's not perfect, but it's fast, simple and good enough (wasting 0.3% of available steps).
SpectraCal Developer
User avatar
Joel Barsotti
Site Admin
 
Posts: 3707
Joined: Thu Dec 03, 2009 12:11 pm
Location: Seattle, WA

Re: YCbCr v RGB, Which color space is bible?

Postby madshi » Sat Jul 24, 2010 12:27 am

You're mentioning "the spec". Which one is that? I didn't know there was a spec defining how 10bit should be used. Does it also define 12bit and 16bit? I guess that should also be simply padded, then? For 8bit -> 16bit a multiplication with 257 instead of 256 would allow us to use the full 16bit range (0 * 257 = 0x0000; 255 * 257 = 0xffff). But then if there's a spec saying that video black should be at 16 * 256 = 4096, then we should use that.

Thanks!
madshi
Calibration Soldier
 
Posts: 55
Joined: Mon Nov 16, 2009 3:41 pm

Re: YCbCr v RGB, Which color space is bible?

Postby Charles Poynton » Fri Jul 30, 2010 8:58 pm

madshi writes,
I'm wondering if 64 and 960 are really the correct numbers for 10bit? ... shouldn't the proper values for 10bit Chroma be 16/255*1023 and 240/255*1023?

Quick answer: No. Digital video was invented and standardized 25 years ago at 8 bits. At that time an extra 2 bits were reserved in the data stream; several years later, the standards were revised to place two additional LSBs on those bits. So the top 8 bits remained the same, and two more bits of precision were provided. Later still, that approach was sanctioned for deeper bit depths (potentially 12 or 16). In other words, to represent video value V (referenced to black at 0 and white at 1) in an integer code having k bits, 8 ≤ k, the integer code is (16 + 219 V) · 2k – 8.

Just scale correctly, it all works fine, even in float (although to eliminate roundoff error you might want to code reference white at a number other than than 1.0, like 876/1024 = 0.85546875, but that’s another story ...).

PC coding is of course 0 through 255 inclusive, and everyone will expect deeper words to retain reference white at the maximum binary value 2k – 1, and to have reference white at exactly 1.0 in floating point (though that may not be the best choice to absolutely minimize roundoff error).
I didn't know there was a spec defining how 10bit should be used.

The coding is defined in SMPTE 274M and several other SMPTE documents, and in ITU-R Rec. BT.601 and 709 and several other ITU documents.

- C
Charles Poynton
Calibration Soldier
 
Posts: 27
Joined: Wed Apr 07, 2010 2:16 pm
Location: Toronto, Ontario, Canada

Re: YCbCr v RGB, Which color space is bible?

Postby madshi » Sun Aug 01, 2010 11:15 pm

Thanks much for your reply, Charles.
madshi
Calibration Soldier
 
Posts: 55
Joined: Mon Nov 16, 2009 3:41 pm

Re: YCbCr v RGB, Which color space is bible?

Postby Stacey Spears » Thu Mar 24, 2011 1:41 pm

This is an old thread, but the topic is close enough that I thought I would share.

For the last couple of years I have been complaining to DVDO about clipping in their video processor. Setting contrast to -1 seemed to fix it. This all changed when I got my QuantumData HDMI analyzer. I was finally able to see what was happening and realized that setting contrast to -1 did not fix it. In my journey, I discovered that the Panasonic 3D Blu-ray player had the exact same problem if you forced the player to output RGB. After much investigation, and special thanks to Panasonic for sharing, we (Spears & Munsil) were able to figure out what was going wrong. DVDO fixed their product last year. Panasonic tells me they have fixed it in the newer models.

The ABT an Qdeo chips have the error by default. If you program a custom 3x3 matrix, you can get proper performance. OPPO has done custom programming in their Blu-ray players so they do not have the issue. Pixar was actually the first to notice this problem back when the BDP-83 was in beta. Pixar complained about some pixels being off by one. :) At least I know there is someone else out there that shares my obsession. :)

We have built some new tests patterns to catch the problem. One is designed to be measured with an HDMI analyzer and the other is for visual viewing.

The issue is that companies are trying to shortcut the calculation by not converting to the nominal [1..0] range, and the range is different between Cb/Cr and Y. But the coefficients are intended to work with the nominal range scaled to be the same for all three values.

In other words, these equations are not identical (where "K1" is the Cb matrix coefficient and "K2" is the Cr matrix coefficient, and the Y coefficient is assumed to be 1.0):

Eq1: R = Y + (Cb - 128) * K1 + (Cr - 128) * K2 // DVDO & Panasonic

Eq2: R = (((Y - 16) / 219) + ((Cb - 128) / 224) * K1 + ((Cr - 128) / 224) * K2 ) * 219 + 16 // correct

The top one is close to a simplification of the bottom one (which is the correct calculation), but pretends that it can ignore the difference between 219 and 224. At moderate values (close to gray), the differences are small, but at extreme values, the error gets large.

A correct simplification is:

R = Y + (Cb - 128) * (219/224) * K1 + (Cr - 128) * (219/224) * K2

Which allows you to "bake in" the 219/224 fraction into the Cb and Cr coefficients in the matrix if you want to save some math.
Stacey Spears
Calibration Hero
 
Posts: 275
Joined: Wed Aug 11, 2010 12:52 pm


Return to Poynton's Vector

Who is online

Users browsing this forum: No registered users and 4 guests

x