<p><a href="https://www.itu.int/pub/R-REP-BT.2246-8-2023" rel="nofollow noreferrer">Report ITU-R BT.2246-8</a> discusses this in extensive detail, starting in section 2.3 of Annex 2. The authors discuss the advantages of a YCbCr model operating on linear color (referred to as CL, or constant luminance, in the report, and defined in Rec. 2100). And they suggest that the commonplace YCbCr &quot;NCL&quot; models are a historical accident:</p>
<blockquote>
<p>The colour encoding process defined in Recommendation ITU-R BT.709 (same as in the NCL) was
actually proposed to comprise the least computational steps, and so the non-linear R'G'B' signals can
be used without further transformation as an input to compensate the intrinsic non-linear property of
a CRT receiver. On the contrary, a linear display such as LCD and AMOLED mainly will be used
for UHDTV systems. Therefore, it is reasonable to have linear RGB signals at the end of the decoder.</p>
</blockquote>
<p>In plain English, since CRTs used to accept nonlinear signals, it was simplest for the receiver to just undo the YCbCr transform and dump the resulting signal (which is nonlinear) out to the CRT. We no longer use CRTs very often, but we keep doing it this way because our software (and some hardware, like GPUs) expect it.</p>
<p>The authors of the report conclude that in general, it shouldn't introduce any extra error to do the YCbCr conversion the historical way. However, they also suggest that it may be &quot;beneficial to improve compression efficiency due to more orthogonal CL video signals... compared with the NCL signals.&quot;</p>

CC BY-SA 4.0
2024-03-31T12:13:02.037Z
2024-03-31T12:13:02.037Z
colinmarc
<p>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.</p>
<p>When you're naively converting between different RGB spaces, for example from sRGB to BT.2020, you generally do something like the following:</p>
<ul>
<li>Apply the source EOTF to get linear values</li>
<li>Do a matrix multiplication to go from one space to the other (assuming the white points are the same)</li>
<li>Apply the destination OETF to get nonlinear values for storage</li>
</ul>
<p>This makes intuitive sense to me, because the transfer function is an &quot;extra&quot; 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.</p>
<p>However, when converting from RGB to YCbCr, you're supposed to use the nonlinear values when doing the transformation. For example, <a href="https://www.itu.int/rec/R-REC-BT.2100-2-201807-I/en" rel="nofollow noreferrer">Rec. 2100</a> defines Y, Cb, and Cr in terms of <code>R'</code>, <code>B'</code>, and <code>G'</code>, which I understand to be the values after the OETF is applied.</p>
<p>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?</p>
<p>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?</p>

CC BY-SA 4.0
2024-03-29T11:11:06.697Z
Apologies in advance for all the terminology I got wrong. Please correct me / edit the post as needed.
colinmarc
CC BY-SA 4.0
2024-03-30T14:07:04.733Z
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.
Simon F
CC BY-SA 4.0
2024-03-31T12:14:56.627Z
@SimonF I think your hunch was right. See my answer referencing BT.2246.
colinmarc
<color><color-science>
Why are YCbCr transforms defined in terms of gamma-corrected RGB?
colinmarc
# Why are YCbCr transforms defined in terms of gamma-corrected RGB?

(Asked by: username_0 on 2024-03-29)

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](https://www.itu.int/rec/R-REC-BT.2100-2-201807-I/en) 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?

**Tags:** color, color-science

> **Comments:**
> **username_0**: Apologies in advance for all the terminology I got wrong. Please correct me / edit the post as needed.  
> **username_1**: 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.  
> **username_0**: @username_1 I think your hunch was right. See my answer referencing BT.2246.  

---

## 1 answers

### Answer by username_0 on 2024-03-31. Score: 3

[Report ITU-R BT.2246-8](https://www.itu.int/pub/R-REP-BT.2246-8-2023) discusses this in extensive detail, starting in section 2.3 of Annex 2. The authors discuss the advantages of a YCbCr model operating on linear color (referred to as CL, or constant luminance, in the report, and defined in Rec. 2100). And they suggest that the commonplace YCbCr "NCL" models are a historical accident:

> The colour encoding process defined in Recommendation ITU-R BT.709 (same as in the NCL) was
> actually proposed to comprise the least computational steps, and so the non-linear R'G'B' signals can
> be used without further transformation as an input to compensate the intrinsic non-linear property of
> a CRT receiver. On the contrary, a linear display such as LCD and AMOLED mainly will be used
> for UHDTV systems. Therefore, it is reasonable to have linear RGB signals at the end of the decoder.

In plain English, since CRTs used to accept nonlinear signals, it was simplest for the receiver to just undo the YCbCr transform and dump the resulting signal (which is nonlinear) out to the CRT. We no longer use CRTs very often, but we keep doing it this way because our software (and some hardware, like GPUs) expect it.

The authors of the report conclude that in general, it shouldn't introduce any extra error to do the YCbCr conversion the historical way. However, they also suggest that it may be "beneficial to improve compression efficiency due to more orthogonal CL video signals... compared with the NCL signals."


---

