Skip to main content
Computer Graphics

Return to Question

edited body
Source Link
colinmarc
colinmarc
  • 151
  • 5

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 OETFEOTF 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 EOTFOETF 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 EOTFOETF 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 EOTFOETF?

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 OETF 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 EOTF 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 EOTF 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 EOTF?

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?

Source Link
colinmarc
colinmarc
  • 151
  • 5

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 OETF 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 EOTF 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 EOTF 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 EOTF?