Maximum amount of ImageBufferMultiRoi on a microEnable 5 marathon VCLx

    Hello,

    I am trying to implement several (6) ImageBufferMultiRois into my Design.

    However, I am limited to 4 - since I cannot enter a higher Resource Index than 3 in the Device-Resource Tab.


    Is there any way to get 6 different ImageBufferMultiRoIs into my Design with my current Hardware ( microEnable 5 marathon VCLx ) ?

    A simplistic design is attached to showcase my issue

    Thank you for your help,

    Kevin

    Dear Kevin,


    the operator ImageBufferMultiRoI requires a RAM module. See a part of the operator documentation below

    pasted-from-clipboard.png


    The VCLx grabber, like most others, provides four RAM modules. So, it is not possible to use more than four operators that require a RAM module in your design.

    pasted-from-clipboard.png


    Maybe there is a way to reduce the required number of RAM modules by combining images prior to the ImageBufferMultiROI. Could you give some more information about the input images, data rates (bit width and parallelism) and the ROIs you want to crop?


    Best regards,

    Oliver

    Dear Kevin,


    The amount of RAM modules is limited to 4 on all platforms.

    When I looked at the simplified VA design, there is an option of using a single RAM module representing the requested functionality:
    Use a single RAM module in front of the splitting branch sending all required ROIs, one after the other.

    Within in each output link of the branch you can use RemoveImage, to select the requested images.
    To keep the bandwidht and memory available as high as above you can go for a duplication of this approach.

    Please let me know of there are additional questions.


    Sketch of intended and recommended solution, file attached Multi_Simple_Rois.va:


    pasted-from-clipboard.png


    Best regards,

    Hello,

    Thank you both very much for your input.

    Two questions remain at the moment:

    1) If the image would be split up in tiles, and each branch should compute a different tile the input for the remove image can either be obtained by a LUT like now - or by a modulo count with the divisor set 5 followed by an Is_NotEqual, e.g.:

    pasted-from-clipboard.png


    What would be best practice?


    2) Can a speed up be achieved by splitting up an image into several ImageBufferMultiROIs?

    Best regards,

    Kevin

    Hi Kevin,


    Concerning your question:

    Quote from kevinh

    1) If the image would be split up in tiles, and each branch should compute a different tile the input for the remove image can either be obtained by a LUT like now - or by a modulo count with the divisor set 5 followed by an Is_NotEqual, e.g.:


    What would be best practice?

    I personally would prefer the LUT, because this would enable a decision on each single image within a sequence length being controlled by the LUT content per branch. An Is_"Condition" would be selective for the conditions complexity.
    In general: LUT in static condition would be the cheapest option for shorter sequences; and would enable a more dynamic approach with low ressource consumption.

    Best regards,

    Hi Kevin,

    Quote from kevinh

    2) Can a speed up be achieved by splitting up an image into several ImageBufferMultiROIs?

    using multiple parallel RAMs would cause a potential speed-up. Please be aware that a shared memory concept would behave differently on the VA platforms there are. Additionally the speed-up could be achieved by overlapping regions.
    If you like we can focus on this topic during a conceptual coaching... Feel free to contact me for this.


    Best regards,