Coaxlink FFC

Implementation of Flat Field Correction in Coaxlink products

Some cameras have a built-in FFC module while other cameras do not implement this feature, The devices without that functionality can however be corrected by the FFC core of the Coaxlink card.

The FFC core of the Coaxlink firmware corrects the pixels directly coming from the camera by applying the FFC using the coefficients (Offset and Gain) corresponding to their locations in the image. Because the correction happens at a very early stage in the Coaxlink pixel processing chain, the other pixel processing functions such as RedBlueSwap, LUT, and Bayer Decoding are performed on corrected pixels.

Gain and Offset Coefficients Format

The coefficients calculated in the calibration procedure can be loaded into the Coaxlink card, provided they are encoded as follows:

Offset and Gain values for one pixel component are packed together into a 16-bit little-endian value:

● Gain is encoded in UQ2.8 on bits 9..0

● Offset is a 6-bit unsigned integer on bits 15..10

Coefficients related to pixel component values are treated separately in the same sequence as the pixel components of the image. For example in RGB8 format, one pixel is encoded as 3 successive 8-bit values (Red, Green, Blue), therefore we need 3 successive 16-bit packed coefficients to correct one RGB8 pixel.

If the 16-bit packed coefficients are stored (in sequence) in a binary file (let's say 'path/to/coefficients.ffc'), they can be easily loaded from a Euresys script by calling

require("coaxlink://ffc/load")(grabber, 'path/to/coefficients.ffc');

where grabber is the script variable referencing the grabber to configure.

Note: such a binary file can be created by the Euresys ffc-wizard sample application

Feature Availability

The following table lists the product/firmware variant combinations supporting FFC and their main characteristic:

Product / Firmware variant	Firmware Variant	CoaXPress Interface	DRAM Partitions
1633 Coaxlink Quad G3	1-camera	CXP-6 DIN4	512 MB for FFC coefficients storage 512 MB for FIFO data buffer
3602 Coaxlink Octo	2-camera	CXP-6 DIN4	512 MB for FFC coefficients storage 512 MB for FIFO data buffer

Specifications

Camera Types

The FFC feature is applicable to monochrome, Bayer CFA and RGB Color area-scan cameras delivering 8-, 10-, 12- 14- or 16-bit data per pixel component.

Maximum Image Size

The following table shows the maximum image size for all supported pixel formats when FFC is enabled :

Bit depth	Maximum Image size [Pixels]
Bit depth	Monochrome and Bayer CFA formats	RGB formats	RGBa formats
8-bit	134,217,728 pixels	44,739,242 pixels	33,554,432 pixels
10-bit	107,374,182 pixels	35,791,394 pixels	26,843,545 pixels
12-bit	89,478,485 pixels	29,826,161 pixels	22,369,621 pixels
14-bit	76,695,844 pixels	25,565,281 pixels	19,173,961 pixels
16-bit	67,108,864 pixels	22,369,621 pixels	16,777,216 pixels

Performance

When enabled, the FFC feature adds a significant load to the DRAM memory since it fetches an additional 16-bit coefficient data for each processed pixel. When the FFC is enabled, the Coaxlink cards are only able to sustain a fraction of the maximum data rate achievable by the CoaXPress Link. This dimension-less value is named "Sustainable relative data rate"

The following table shows the sustainable relative data rate for all bit depths and product/firmware variant combinations supporting FFC.

Sustainable Relative Data Rate

Bit depth	Sustainable Relative Data Rate [% of a 4-lane CXP-6 maximum data rate]
Bit depth	1633 Coaxlink Quad G3 - 1-camera	3602 Coaxlink Octo - 2-camera
8-bit	70.0 %	123.2 %
10-bit	77.8 %	136.9 %
12-bit	84.0 %	147.8 %
14-bit	89.1 %	156.8 %
16-bit	93.3 %	164.3 %

Note: The "Sustainable Relative Data Rate" is global for all cameras attached to a board.For instance, in the 3602 Coaxlink Octo - 2-camera 8-bit use case, the sustainable data rate of 123.2% can be split unequally to 100% for a camera and 23.2% for the other camera.

Note: Coaxlink cards do not acquire any data during blanking intervals. Line- and frame-blanking intervals do not consume memory bandwidth and therefore must be excluded in the calculation of the camera data rate.

To avoid latencies, FIFO buffer overflow and loss of frames, Euresys recommends to limit the (global) camera data rate accordingly.