facelessuser
commented
2 months ago Touching on this. Yes, there is a rotation of YIQ that is is referred to as YUV. But in modern times, it seems Y'PbPr, Y'CbCr, and Y'UV are used interchangeably. Y vs Y' simply denotes whether the transform is applied to linear or gamma corrected colors.
What is the formal definition of these colors? Well, it varies. The actual logic for Y'PbPr is pretty well understood, but the weighting can vary depending on the color space: Rec. 601, Rec. 709, Rec. 2020, etc. Y'PbPr is the analog color form while Y'CbCr is the digital form. The digital form will often be offset and scales fit within an integer of some size (8 bit, 10bit, 12bit, etc.). Additionally, the color is scaled such to leave open bits for timing and such, so black may be 16, 16, 16 and may get an upper cap around 240 for 8 bit. Additionally, the color would be rounded.
Do we bother to include the YIQ rotated YUV? Do we provide a YUV for sRGB, which most people seem to use the Rec. 601 weightings for and can also be referred to as sYCC (YCC being an abbreviation for Y'CbCr with I assume the 's' comes from sRGB). My initial thoughts is we would target Rec. 709 (HD form) as Y'CbCr (or Y'PbPr not sure which or both) and if we wanted sRGB, we could have it under the name sYCC. We could include the Rec. 2020 form as well and/or make it easy to derive it from the default.
I assume if we went this route, bit depth could be configured when deriving from the class along with the offset. I'm not sure if we would force rounding or not in the digital form. Rounding can be forced by the user already when serializing, but maybe we could also make that an option? It would obviously break round tripping due to loss of information, but that is also a natural conclusion of using digital vs analog.
Really just YIQ rotated by 33˚