# Why are YCbCr transforms defined in terms of gamma-corrected RGB?

I've learned a lot about digital color recently, and I've had the opportunity to implement several transforms in shaders, including converting between different RGB systems and converting into YCbCr for video encoding.

When you're naively converting between different RGB spaces, for example from sRGB to BT.2020, you generally do something like the following:

• Apply the source EOTF to get linear values
• Do a matrix multiplication to go from one space to the other (assuming the white points are the same)
• Apply the destination OETF to get nonlinear values for storage

This makes intuitive sense to me, because the transfer function is an "extra" encoding on top, so you need to remove it and reapply it when doing the conversion, just like you're supposed to when blending or doing other color math stuff to it.

However, when converting from RGB to YCbCr, you're supposed to use the nonlinear values when doing the transformation. For example, Rec. 2100 defines Y, Cb, and Cr in terms of R', B', and G', which I understand to be the values after the OETF is applied.

Is there an intuitive way to understand the mathematical reason that this is the case, or is it just a coincidence that it was defined that way?

Does that mean a given YCbCr encoding is dependent on both the primaries and transfer function, or can I use the same transformation matrix on color that has been compressed using some other OETF?

• Apologies in advance for all the terminology I got wrong. Please correct me / edit the post as needed. Commented Mar 29 at 11:11
• I couldn't say for certain, but in my opinion it would possibly be due to (a) that it's mimicking the analog world where the old CRT TV's non-linearity which comes from the CRT which is the last step in the process... TV signal (YUV) -> convert to R'G'B' with some OpAmp 'maths' , then send to CRT) and (b) from a cost point of view it surely involves fewer conversions between linear and nonlinear. Commented Mar 30 at 14:07
• @SimonF I think your hunch was right. See my answer referencing BT.2246. Commented Mar 31 at 12:14