[RFC] widen type bound for YCbCr #11
Conversation
|
I don't really know what I'm talking about, but don't Cb and Cr range from -1 to 1? https://en.wikipedia.org/wiki/File:YCbCr-CbCr_Scaled_Y50.png. If so, then you'll want |
|
So I think there is Cb' / Cr' which go from 0-1 and alternatively Cb / Cr which go from -1 - 1. And technically the standard is speaking of DY' and DCb' + DCr', but I also don't know what I am talking about ;) I am trying to find the right standard definition right now... But Y' is definitely only from 0-1 so how would we handle a colortype that has two different value types? |
|
Also sub-black information encoding? Who came up with this... |
|
But you are right for Cb and Cr (8bit) 128.00b is defined as zero. |
|
We use sub-black in broadcast for encoding additional information in the physical layer on analogue networks like HD-SDI. I'd like to say it's a throwback to earlier times, but very few manufacturers of broadcast kit have dared remove HD-SDI connectors from their gear. My colleagues are working on an IP(as in Internet Protocol)-only broadcast system, but it is still very much a research project. So, sadly, sub-black info is around for a while. I suspect I'll either build a custom colour type for broadcast data, or more likely convert to floating point when I need to do any of the kind of processing that these libraries are intended for. |
|
@AndrewGibb That's what I need it for to process video material coming in from a Camera via SDI. |
See #10 for Context.
These are the minimal changes to make YCbCr work with Fractional as a upper bound.
I think there is a case to introduce AbstractYCbCr to furthermore allow the introduction of compact types like RGB32 and also because I had to treat YCbCr like AbstractRGB in a few places.
The only point that I see that speaks against AbstractYCbCr is that it furthermore complicates the type hierarchy and it probably needs more consideration then these changes.