Getting Raw Pixel Values

Greetings,

It appears that the Blackmagic SDK only gives you access to formatted pixels values (8bit YUV422, 8 Bit RGB, etc). Is it possible to get the raw Y and CbCr from a pixel in a HD-SDI stream?

A little background:
We make IR cameras where I work that output SMPTE 292 video, and we have a request to support MISB 0403.3 Infrared (IR) video. It is my understanding, that in a normal SMPTE 292 video stream, each pixel in a frame is represented by 10 bits of Y and 10 bits of CbCr. In MISB 0403.3, we are dealing with 16 bit Y data (IR is greyscale so we have more bits dedicated to luma) so the upper 10 bits of a IR pixel is packed into the Y channel and the lower 6 bits are packed into the CbCR. I'm trying to use the SDK to rebuild a 16 bit pixel from the Y, Cb,Cr values coming from the capture card. If I am trying to get every pixel's CbCr value, I can't use 4:2:2 encoding, since it gives the CbCr for every other pixel. Is there anyway around this in the SDK?

Thanks,
Matt

Hi Matt,

From what I understand of the ST0403.3 standard, the lower bits come from the colour difference samples. You get a colour sample for each luminance signal, blue first, then red. As these are not colour but luminance data, you would simply combine the bits (bearing in mind the 0x40 offset).
[Cb, Y]
[Cr, Y]
[Cb, Y]
[Cr, Y]
So, as long as you are in BMDFormat10BitYUV, your 1st pixel would be made up of Bytes 0-2 of word 0, pixel 1 from bytes 2 & 3 of word 0 and bytes 0 & 1 of word 1 etc.

Regards,

Dave.

Thanks Dave for the response. What isn't clear to me from the Blackmagic SDK documentation is what order the pixels are read out. Is y0/cb0 the first pixel in the sense that it is the most upper/left pixel in your image? Then is y1/cr0 the pixel immediately to its right? I'm getting a weird wrapping behavior where I have 16 pixels that appear in wrong row, so I'm wondering if I have a fundamental problem understanding how blackmagic is arranging the pixel data in the byte array I get from a frame of their video.

Hi Matt,

I believe the pixel order is how you describe it. As for the row problem, have you noted the 128 byte alignment?

In this format, each line of video must be aligned on a 128 byte boundary. Six pixels fit into16 bytes so 48 pixels fit in 128 bytes. For the row bytes calculation the image width is rounded to the nearest 48 pixel boundary and multiplied by 128.
For the frame size calculation the row bytes are simply multiplied by the number of rows in the frame.

Regards,

Dave.