ImageBuffer max.size and bandwidth problem when using ROI

  • I have a design that runs for a CXP camera, Mono8, 4672x3416@148fps, externally synchronized through CoaXPress on an OptoTrigger.

    This is a classic design : camera->split in low/high bytes->store in two Infinite imagebuffers->merge pixel->SelectROI operator->DmaOutput


    https://seefastechnologies.com…416-synchro%2Btrigger.zip


    The problem occurs when I set the camera to 1024x1000@1000fps. I also set the SelectROI Width/Height to 1024x1000

    In that case, which has a *lower* datarate than 4672x3416@148fps, the image buffers are filled at 75% and there are overflows. I have to reduce the sync signal to ~830fps to get a flawless behaviour.


    But I can make it work if I also manually set both image buffers XLength and YLength to 1024x1000.

    I would like to get rid of this manual operation, since I expect Image Buffers to automatically adapt themselves to smaller images.


    I tried different other strategies without success:

    -put the SelectROI before the Image buffers (it's even worse)

    -split the pixels in 4 images buffers of 2 bits instead if 2 image buffers of 4 bits (it does not change anything)

    -limit the camera parallelization to x20 instead of x32 (it's obviously worse, but I tried)

  • In case you are using an ImageBuffer (SelectROI, or similar) you have to update the regions of interest (ROI) dimensions.

    Especially the ImageBuffer requires a ROI update on the X_Length.

    Y_Length is taken from the input image and not changed.

    The ImageBuffer applies the X_Length set independent of the input width.

  • I did a quick review of your design and it is simply forwarding the camera image into two parallel ImageBuffers.

    These ImageBuffers apply the X_Length set as parameter.

    A workaround would be to use AppendLine and SplitLine to handle the image as pure block of data and send it to the DMA.

    The DMA is handling all data as linear block and transfers it as linear block.

    By this the flexible Y_Length is used of the real amount of data. Please be aware that this will produce some strange side-effects and you need to know the input dimension for correct visualization in the sofwtare part outside of VA.

  • Download (MOD_CXP-Mono8-4672x3416-synchro+trigger.va), in there you can find a slightly modification of your VA design.MOD_CXP-Mono_FLEX.png

    AppendLine combines the full image - independent of its size - to a single line.

    SplitLine converts this line to small portions of image data that are independent of the input resolution.

    The SetDimension DIRECTLY in front of the DMA gives a default to FG_WIDTH and FG_HEIGHT for software interpretation.

    That default can be changed.

  • Do you mean that when using a camera ROI, all the following operators anywhere in the design must be adapted manually at run-time ?

    -SelectROI.XLength/SelectROI.YLength

    -ImageBuffer.XLength/ImageBuffer.YLength

    This is a pain that it cannot be factorized in some single variable.


    I don't understand that limitation. Even if the ImageBuffer has an XLength greater that the real ROI, since it is smart enough to handle EOL and keep correct frame dimensions, why does it limit the performance ?

  • The frame grabber design needs some details on the forwarded image data.


    The VA design MOD_CXP-Mono8-4672x3416-synchro+trigger.va can handle changes of the received image size without further interaction. But in parallel it does not know about the real ROI being used.


    You can use our Parameter-Translation to make it a single parameter call.


    In case you apply the native ROI approach and the X-Length is larger than the reiceved image, then the image size is increaed automatically. This leads to a higher bandwidth that may lead to a unwanted backlog(back pressure).