Pixel Format

Emergent Vision Technologies cameras provide a pixel format feature that lets you set and retrieve the format of the image data that the camera transmits. The pixel format choices depend on the camera model.

PixelFormat node

The pixel format feature uses the PixelFormat node, which has the following properties:

• Name: PixelFormat
• Access mode: Read/Write
• Node type: Enumeration

You can use the eSDK API functions to:

• get and set the node’s current value, and
• get the node’s value options.

Using the pixel format feature

You can configure a camera’s pixel format using either eCapture Pro or the Emergent API. This section summarizes how to use the Emergent API with the PixelFormat node. For information about configuring a camera’s pixel format using eCapture Pro, see the eCapture Pro Manual.

To get all pixel formats available to a camera, use the Emergent API function EVT_CameraGetEnumParamRange and the PixelFormat node, as shown in the following C++ sample code:

1// Get all possible PixelFormat values into a
2// comma-separated enumBuffer string array.
3const unsigned long enumBufferSize = 1000;
4char enumBuffer[enumBufferSize];
5unsigned long enumBufferSizeOut = 0;
6EVT_CameraGetEnumParamRange(&camera, "PixelFormat", enumBuffer, enumBufferSize, &enumBufferSizeOut);

‍

To set a camera’s pixel format to one of the available values, use the Emergent API function EVT_CameraSetEnumParam and the PixelFormat node, as shown in the following C++ sample code:

1// Set the camera’s PixelFormat value to 
2// BayerGB10Packed.
3EVT_CameraSetEnumParam(&camera, "PixelFormat", "BayerGB10Packed");

‍

To get a camera’s current pixel format, use the Emergent API function EVT_CameraGetEnumParam and the PixelFormat node, as shown in the following C++ sample code:

1// Get the camera’s current PixelFormat value 
2// into a buffer.
3EVT_CameraGetEnumParam(&camera, "PixelFormat", enumBuffer, enumBufferSize, &enumBufferSizeOut);

‍

For more information about configuring a camera’s pixel format using the Emergent API, see the following:

• The Camera Programmer’s Manual
• The Camera Attributes Manual
• The examples in the eSDK

Pixel formats

When selecting a pixel format for high-speed camera applications, you should balance the need for color accuracy, image detail, processing simplicity, and bandwidth optimization. Monochrome formats excel in applications prioritizing detail over color, Bayer formats are versatile for general color imaging, YUV is ideal for bandwidth efficiency with acceptable color, and RGB/BGR serves applications requiring the highest color fidelity.

Detailed information about pixel formats can be found in the GenICam Pixel Format Naming Convention 2.1.

Monochrome pixel formats

Monochrome pixel formats are best suited for applications needing high sensitivity and resolution without the need for color. 

Here are some examples of monochrome pixel formats:

• Mono8 - monochrome 8-bit unpacked
• Mono12 - monochrome 12-bit unpacked
• Mono12Packed - monochrome 12-bit packed

Bayer pixel formats

Bayer pixel formats offer a balanced approach to capturing color images in a cost-effective and space-efficient manner but require computational demosaicing to reconstruct a full-color image.

Color cameras have a Bayer color filter and can output color images based on Bayer pixel formats. When a color camera uses a Bayer pixel format, it outputs 8, 10, or 12 bits of data per pixel. Each pixel is filtered to record only red, green, or blue. This Bayer pixel format data is sometimes called “raw” output.

Here are some examples of Bayer pixel formats:

• BayerRG8 - Bayer red green filter 8-bit unpacked
• BayerGB8 - Bayer green blue filter 8-bit unpacked
• BayerGB10Packed - Bayer green blue filter 10-bit packed

BayerRG8 pixel format

The BayerRG8 pixel format uses an 8-bit per pixel Bayer filter pattern. Each pixel is represented by a single byte, simplifying processing and storage. The 8-bit depth of BayerRG8 provides lower image quality than the 10-bit depth of BayerRG10Packed. 

On an image’s first row (row 0), BayerRG8 pixels alternate between red and green, starting with red on byte 0. On an image’s second row (row 1), the pixels alternate between green and blue, starting with green on byte n. The next rows in the image repeat the color sequences of the first two rows.

BayerGB10Packed pixel format

The BayerGB10Packed pixel format uses a 10-bit per pixel Bayer filter pattern. The 10-bit depth of BayerGB10Packed offers more dynamic range than the 8-bit depth of BayerRG8. The higher bit depth allows for capturing finer gradations in intensity, leading to improved detail in shadows and highlights.

On an image’s first row (row 0), the BayerGB10Packed pixels alternate between green and blue, starting with green on byte 0. On an image’s second row (row 1), the pixels alternate between red and green, starting with red on byte n. The next rows in the image repeat the color sequences of the first two rows.

No padding bits are needed between the BayerGB10Packed pixels in a row. This packing reduces the necessary memory space and transmission bandwidth. However, because the data isn’t byte-aligned, packed data requires more complex processing to unpack the pixel data for image reconstruction.

YUV pixel formats

YUV pixel formats excel in separating luminance from color, optimizing compression and transmission but might sacrifice color precision.

If a color camera uses a YUV format, each pixel value in the captured image goes through a conversion process as it exits the sensor. This process yields brightness (Y) and chroma (U and V) information for each pixel. Emergent Vision Technologies cameras use 8 bits to encode each Y, U, and V component. 

Here are some examples of YUV pixel formats:

• YUV411Packed
• YUV422Packed 
• YUV444Packed

YUV444Packed pixel format

The YUV444Packed pixel format captures the full color information for each pixel without subsampling. Due to its comprehensive data representation, YUV444Packed demands more storage space and bandwidth compared to subsampled formats. It’s ideal for high-quality image processing and editing but less so for bandwidth-sensitive applications.

The “444” in YUV444Packed signifies that all components are sampled at the same rate. Each YUV444Packed pixel has 1 byte of Y data, 1 byte of U data, and 1 byte of V data. 

In YUV444Packed pixels, the components are arranged in the sequence U Y V.

YUV422Packed pixel format

The YUV422Packed pixel format balances color fidelity and data size by subsampling chroma while maintaining full luminance detail. This efficiency reduces storage and bandwidth needs compared to non-subsampled formats like YUV444Packed, making it ideal for applications requiring a compromise between quality and efficiency.

The “422” in YUV422Packed signifies that for every two pixels, the Y component is fully sampled for both, but the U and V components are sampled once and shared across these two pixels.

In YUV422Packed pixels, the components are arranged in the sequence U0 Y0 V0 Y1.

YUV411Packed pixel format

The YUV411Packed pixel format reduces data size by more aggressively subsampling chroma, allowing for even greater storage and bandwidth efficiency than YUV422Packed. It’s ideal for more bandwidth-sensitive applications that require some color data.

The “411” in YUV411Packed signifies that for every four pixels, the Y component is fully sampled for all, but the U and V components are sampled once and shared across these four pixels.

In YUV411Packed pixels, the components are arranged in the sequence U0 Y0 Y1 V0 Y2 Y3.

RGB and BGR pixel formats

RGB and BGR pixel formats provide direct and accurate color information at the cost of increased data demands and potentially lower light sensitivity.

When a color camera uses the RGB8 or BGR8 pixel format, the camera outputs 8 bits of red data, 8 bits of green data, and 8 bits of blue data for each pixel. The pixel formats differ by the output sequences for the color data (red, green, blue or blue, green, red).

Here are some examples of RGB and BGR pixel formats:

• RGB8 - red, green, blue 8-bit unpacked
• BGR8 - blue, green, red 8-bit unpacked

Maximum pixel bit depth

The maximum pixel bit depth is defined by the pixel format with the highest bit depth among the pixel formats available on your camera. For example, if the available pixel formats for your camera are RGB8, Mono10, and BayerGB12, the maximum pixel bit depth of the camera is 12 bits.

Packed and unpacked pixel formats

Many pixel formats have packed and unpacked versions. Unless otherwise specified, the pixel formats are unpacked. 

Packed formats conserve bandwidth and storage by tightly grouping pixel data, as opposed to unpacked formats, which ensure each pixel's data aligns with byte boundaries but might use more space. 

However, packed pixel data that isn’t byte-aligned must later be unpacked and realigned before further processing and to ensure compatibility with a wide range of hardware and software systems that often operate most efficiently on byte-aligned data. For applications where speed is a priority, the choice between packed and unpacked might be influenced by the system's ability to handle the unpacking process efficiently.

Unpacked pixel formats

When a camera uses an unpacked pixel format, the camera inserts padding bits (zeros) if needed to reach the next byte boundary. Unpacked pixel data is always byte aligned. For example, if you choose a 12-bit unpacked pixel format like Mono12, the camera outputs 16 bits (2 bytes) per pixel: 12 bits of pixel data and 4 padding bits to reach the next byte boundary. 

Packed pixel formats

When a camera uses a packed pixel format, the camera doesn’t insert padding bits between pixels. Packed pixel data is not always byte aligned. A byte can contain data of multiple pixels. For example, if you choose a 12-bit packed pixel format like Mono12Packed, then 3 bytes contain 24 bits for two 12-bit pixels.

Note: The additional processing step to later unpack the packed pixel data can increase computational overhead, especially in real-time applications where processing speed is critical.

For more information about related features, see Image Format Control Features.