| Customize Help

Minimum latency and grabbing all frames



When grabbing with either MdigGrab() or MdigProcess(), Matrox RadientPro CL is optimized to have the smallest latency possible between the last pixel sent from the camera to the last pixel written into the buffer. This allows the buffer to be available for processing with a minimum amount of delay.

On-board memory is used to protect against PCIe latency. By default, Matrox RadientPro CL grabs into off-board buffers. To perform real-time grabs, your rate of acquisition (grabbing bandwidth) must be lower than the PCIe maximum transfer rate (PCIe bandwidth). If the acquisition rate is higher than the transfer rate across the PCIe bus, frames will be skipped rather than allowing a grab over-run to occur. To determine the image transfer speed from Matrox RadientPro CL to the Host, use the Matrox RadientPro CL Bench utility.

Detecting missed frames when using MdigProcess

To be certain that no frames were missed when MdigProcess() was last used, use MdigInquire() with M_PROCESS_FRAME_MISSED. This value is based on a comparison between the frame rate (M_PROCESS_FRAME_RATE) and the frame count (M_PROCESS_FRAME_COUNT). If a grab is triggered from a temperamental trigger or if the hooked function is slow, the value returned by M_PROCESS_FRAME_MISSED will be affected. This value is most trustworthy with a camera in continuous mode. You can inquire the frame time-stamp sampled at the end of the frame using MdigGetHookInfo() with M_TIME_STAMP.

Use M_PROCESS_FRAME_COUNT to determine the total number of frames grabbed in the sequence.

Use M_PROCESS_FRAME_RATE to return an estimate of the frame rate in frames per second. Note that this value is determined based on the average of the camera's frame rate, and the total amount of time to process the user-defined hooked function(s).

Quickly copying an on-board buffer to a Host destination buffer

When copying an on-board buffer into a Host destination buffer, the copy operation should be performed by your Matrox RadientPro CL using the Matrox RadientPro CL's DMA engine, rather than the Host. Your Matrox RadientPro CL will perform the operation faster than the Host. To ensure that Matrox RadientPro CL performs the operation, use the following:

  • To copy an on-board buffer into a destination buffer on the Host, use MbufCopy().

  • To resize an on-board buffer while copying it to a destination buffer on the Host, use MimResize() with a factor of 1 to 16 and with an interpolation mode of M_NEAREST_NEIGHBOR. Alternatively, you can use MbufTransfer() to perform the same operation.

  • To flip an on-board buffer while copying it to a destination buffer on the Host, use MimFlip().

Note that for your Matrox RadientPro CL to perform these operations, the destination Host buffer must be allocated in non-paged memory (that is, using MbufAlloc...() with + M_IMAGE + M_NON_PAGED).

Quickly converting buffer formats while copying

When copying an on-board buffer into a destination Host buffer, the color space converter and image formatter can automatically convert the bit-depth and color format of the source buffer to the bit-depth and color format of the destination buffer.

For on-board conversion of buffers to take place, the following on-board image and destination depth and color formats are supported.

On-board buffer depth and color format (specified in the DCF).

Host destination buffer depth and color format.

8-bit monochrome.

16-bit monochrome.

M_PACKED + M_BGR24.

M_PACKED + M_BGR32.

M_YUV16_YUYV / M_YUV16.

M_PLANAR + M_RGB24.

M_PLANAR + M_RGB48.

8-bit monochrome.

Yes.

No.

Yes.

No.

Yes.

Yes.

No.

16-bit monochrome.

Yes.

Yes.

Yes.

Yes.

Yes.

Yes.

Yes.

M_PACKED + M_BGR24.

Yes.

No.

Yes.

No.

Yes.

Yes.

No.

M_RGB48 + M_PACKED

Yes.

Yes.

Yes.

Yes.

Yes.

Yes.

Yes.

For information about YUV or RGB/BGR buffers, refer to Chapter 21: Data buffers. For the calculations used to convert to YUV, refer to the Matrox RadientPro CL Hardware and Installation manual.