This document describe the layout of information within a frame of image data populated by a call to the Pixelink API's function PxLGetNextFrame or a call back routine. The layout in a frame is based primarily on the camera's pixel format, which can be found by querying the PixelFormat field of the Frame Descriptor structure that is returned by PxLGetNextFrame or provided to the callback routine.  The pixel format will typically be one of the following:


MONO8, MONO16, BAYER8, BAYER16, YUV422


MONO8


Each sensor pixel is represented as an 8 bit DN value and takes up 8 bits (1 byte).  The frame is organized as an array of sensor pixels, starting at top left, moving left to right, top to bottom.


Example


PL-B771 camera configured for:


MONO8

ROI is 8x8


The camera is looking at a bright white image. Looking at the frame data in memory on a byte-by-byte basis


0x00A92D20  ff ff ff ff ff ff ff ff

0x00A92D28  ff ff ff ff ff ff ff ff  

0x00A92D30  ff ff ff ff ff ff ff ff  

0x00A92D38  ff ff ff ff ff ff ff ff  

0x00A92D40  ff ff ff ff ff ff ff ff  

0x00A92D48  ff ff ff ff ff ff ff ff  

0x00A92D50  ff ff ff ff ff ff ff ff  

0x00A92D58  ff ff ff ff ff ff ff ff  


MONO16


Each sensor pixel is represented as a 10-bit or 12-bit DN value, depending on the capabilities of the camera. This can be determined by querying the feature FEATURE_MAX_PIXEL_SIZE. Note that this feature is supported only in API versions 6.18 or later. If this feature is not supported by your camera, only 10 bit values are supported. Each sensor pixel takes up 16 bits. (2 bytes). The frame is organized as an array of sensor pixels, starting at top left, moving left to right, top to bottom.

The camera always uses the uppermost bits of a 16 bit value. On a 10-bit camera, the pixel values range from 0x0000 to 0xFFC0 (the bottom 6 bits aren't used), whereas on a 12-bit camera the pixel values range from 0x0000 to 0xFFF0 (the bottom 4 bits aren't used). The 16-bit data from the camera arrives into the computer in big-endian order. Because Wintel (Window & Intel/Intel compatible) computers are little-endian, a simple read of a 16-bit pixel value will result in a value that is byte-swapped. 


Example


PL-B771 camera configured for: 


MONO16 

camera supports 10 bit data

ROI is 8x8


The camera is looking at a bright white image so that all pixels are saturated. For 10-bit data we would expect each pixel to have a value of 1023 (0x3FF). Looking at the frame in memory on a byte-by byte basis (hex values)


0x00A94FF8  ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0

0x00A95008  ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0  

0x00A95018  ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0  

0x00A95028  ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0  

0x00A95038  ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0  

0x00A95048  ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0  

0x00A95058  ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0  

0x00A95068  ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 ff c0 


Looking at the data above in big-endian order, we see that the first pixel has a value of 0xFFC0, in other words, all 10 uppermost bits of the 16 bit value are set. However, we can't do big-endian reads on Wintel computers; a 16-bit (little-endian) read of the first pixel will return a value of 0xC0FF. To get the expected value of 0x03FF requires a bit of bit twiddling.

 

 // Read the first pixel value
 U16 value = *((U16*)0x00A94FF8); 
 // Step 1 - Convert from big-endian to little-endian
 U16 correctValue = ((value &amp; 0xFF00) >> 8) | ((value &amp; 0x00FF) << 8);
 // Step 2 - 'Normalize' to get rid of unused bits
 // For 10 bits, bottom 6 bits aren't used. (16-10)
 // For 12 bits, bottom 4 bits aren't used. (16-12)
 correctValue >>= 6;

 

BAYER8


Each sensor pixel is represented as an 8 bit DN value that takes up 8 bits (1 byte).  The frame is organized as an array of sensor pixels, starting at top left, moving left to right, top to bottom.  On top of the sensor is a Bayer filter, a colour filter array (CFA) which limits which colours are seen by an individual sensor pixel. The Bayer pattern will be either Green-Red-Blue-Green (GRBG) or Green-Blue-Red-Green (GBRG), depending on the sensor. The variation of BAYER8 in use can be determined from the PixelFormat field of the Frame Descriptor.  For example:


Pixel format 3 = PIXEL_FORMAT_BAYER8_GRBG

Pixel format 8 = PIXEL_FORMAT_BAYER8_GBRG


Example


PL-B742 camera configured for:


BAYER8

ROI of 8x8


Camera is looking at a bright pure red image.  The pixel format for the camera is PIXEL_FORMAT_BAYER8_GBRG.  Looking at the frame data in memory on a byte-by-byte basis


0x00A92B98  00 00 00 00 00 00 00 00  

0x00A92BA0   ff  00  ff  00  ff  00  ff  00   

0x00A92BA8  00 00 00 00 00 00 00 00  

0x00A92BB0   ff  00  ff  00  ff  00  ff  00  

0x00A92BB8  00 00 00 00 00 00 00 00  

0x00A92BC0   ff  00  ff  00  ff  00  ff  00  

0x00A92BC8  00 04 00 00 00 00 00 00  

0x00A92BD0   ff  00  ff  00  ff  00  ff  00  


Using the same configuration, but now looking at a bright blue image


0x00A92B98   00  ff  00  ff  00  ff  00  ff  

0x00A92BA0  00 00 00 00 00 00 00 00  

0x00A92BA8  00  ff  00  ff  00  ff  00  ff  

0x00A92BB0  00 00 00 00 00 00 00 00  

0x00A92BB8  00  ff  00  ff  00  ff  00  ff  

0x00A92BC0  00 00 00 00 00 00 00 00  

0x00A92BC8  00  ff  00  ff  00  ff  00  ff  

0x00A92BD0  00 00 00 00 00 00 00 00


Using the same configuration, but now looking at a bright green image


0x00A92B98   ff  00  ff  00  ff  00  ff  00

0x00A92BA0  00  ff  00  ff  00  ff  00  ff  

0x00A92BA8   ff  00  ff  00  ff  00  ff  00

0x00A92BB0  00  ff  00  ff  00  ff  00  ff   

0x00A92BB8   ff  00  ff  00  ff  00  ff  00

0x00A92BC0  00  ff  00  ff  00  ff  00  ff   

0x00A92BC8   ff  00  ff  00  ff  00  ff  00

0x00A92BD0  00  ff  00  ff  00  ff  00  ff  


From this it can be seen that the CFA over this sensor is arranged as


0x00A92B98  G1  BB  G1  BB  G1  BB  G1  BB 

0x00A92BA0  RR G2  RR  G2  RR  G2  RR G2 

0x00A92BA8  G1  BB  G1  BB  G1  BB  G1  BB 

0x00A92BB0  RR G2  RR  G2  RR  G2  RR G2 

0x00A92BB8  G1  BB  G1  BB  G1  BB  G1  BB 

0x00A92BC0  RR G2  RR  G2  RR  G2  RR G2 

0x00A92BC8  G1  BB  G1  BB  G1  BB  G1  BB 

0x00A92BD0  RR G2  RR  G2  RR  G2  RR G2 


With PIXEL_FORMAT_BAYER8_GBRG, the GBRG refers to the upper-left quartet of sensor pixels.


BAYER16


Each sensor pixel is represented as a 10 bit DN value that takes up 16 bits (2 bytes).  For the organization of an individual pixel's bit within the 16-bits, see MONO16. As with BAYER8, there's a CFA above the sensor.  The Bayer pattern will be either GRBG or GBRG, depending on the sensor. 


Pixel format  4 = PIXEL_FORMAT_BAYER16_GRBG

Pixel format 11 = PIXEL_FORMAT_BAYER16_GBRG


Example


PL-B742 camera configured for:


BAYER16

ROI of 8x8


Camera is looking at a bright pure red image.  The pixel format for the camera is PIXEL_FORMAT_BAYER16_GBRG. Looking at the frame data in memory on a byte-by-byte basis.


0x00A92B98  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  

0x00A92BA8   ff  c0 00 00  ff  c0 00 00  ff  c0 00 00  ff   c0 00 00  

0x00A92BB8  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x00A92BC8   ff  c0 00 00  ff  c0 00 00  ff  c0 00 00  ff   c0 00 00  

0x00A92BD8  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  

0x00A92BE8   ff  c0 00 00  ff  c0 00 00  ff  c0 00 00  ff   c0 00 00  

0x00A92BF8  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  

0x00A92C08   ff  c0 00 00  ff  c0 00 00  ff  c0 00 00  ff   c0 00 00  


YUV422


The camera converts each sensor pixel to a YUV (aka YCbCr) triplet. But, rather than transmit the entire triplet for each individual sensor pixel, the following pattern is sent:


U Y | V Y


This is for two pixels of 8 bits each.  For the first pixel, only the U and Y values are sent.  For the second pixel, only the V and Y values are sent.


Example


PL-B686CF camera configured for:


YUV422

ROI of 16x16


Camera is looking at a bright pure red image.  According to the image statistics - found in the histogram tool of PixeLINK Capture OEM:


Average Y is 76 (0x4C)

Average U is 85 (0x55)

Average V is 255 (0xFF)


The Frame Descriptor Pixel Format is 2, i.e. PIXEL_FORMAT_YUV422.  Looking at the frame data in memory on a byte-by-byte basis


0x00A95178  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A951A8  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A951D8  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A95208  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A95238  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A95268  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A95298  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A952C8  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A952F8  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A95328  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A95358  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A95388  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A953B8  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A953E8  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A95418  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

0x00A95448  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 


The UYVY pattern can be seen:

0x00A95178  55 4c ff 4c 55 4c ff 4c 55 4c ff 4c 

                       U  Y  V  Y  U  Y  V  Y  U  Y  V  Y