Images which are to big for one ImageBuffer Operator

  • Hi there,


    after some time I have another Question for you:


    Currently I am working on a specification for a Color linescan camera with a big sensor (19000 pixel) and I want to achieve an Image height of 16364 pixels. As I am working with the gate Operator I have to go into the 2D Image Format in front of my Image Buffer Operator. The maximum Image size is ~ 900 MB which is of Course to big for one Image Buffer ( I am working with Marathon VCX-QP which has 512 MB per RAM). As I can use all my 4 Buffers for this Task I am workin on an idea to split the Image and put it into two Buffers.


    Would the idea I have (see attachment) work as intended or do you have a better solution for me?


    Input Link is 24 Bit Pixel Format and Parallelism of 8.


    Kind regards (und bleibt gesund)

    Theo


    BufferSize.PNG

  • Hi Theo


    Operator ImageBuffer is a line buffer. So the operator will not store the complete image before readout, only one line or more if blocked at the output. So you can use an image size which is larger than the RAM for one of this operator.

    Basically if there is no reason it is better to not store the full image to reduce the latency.

    See file:///Q:/Silicon%20Software/VA/Releases/VisualApplets_3.2/Docu/en/manuals/content/library.Memory.html to find out which memory operator has a line or frame delay.


    The mE5-VCX-QP has a RAM data width of 512 bit. So you should use as much as possible of the data width to speed up the DRAM in the shared memory platform and not to waste memory. As you are using 24 bit per pixel a parallelism of 21 is good in your case. A following SelectROI after the reduction of the parallelism will remove the dummies.


    Johannes


    Johannes Trein
    Group Leader R&D
    frame grabber

    Basler AG



  • Hi Theo,


    In case your scenario requires the memory - maybe there is a reason for that - you can go CastParallel to the parallelism = N = number of RAMs you would like to use. Then SplitParallel these to N and for efficiency please ParallelUp to the maximum the RAMs allow for your plattform.

    Input Link is 24 Bit Pixel Format and Parallelism of 8.

    If you tell me what latency in MB your require and paste at least a part of your VA design in here I will modifiy the VA source for you.

  • Good morning,


    thanks for the fast answer, I really appreciate this. I hope you guys are doing well! Please keep it that way.


    I just wanted to be sure about the possibilities as I never worked with such big Images before. So to sum it up: I have to think about frame sizes only if I am planning to keep the complete image in the buffer. In my case it will work as a line FIFO as I am not planning to stop the image flow after the buffer.


    Also thanks for the hint with the parallelism. I am porting from the VCL, which only has a 256 Bit RAM Data Width. Thats why I am still on 8 (10 would have been better I think, but it worked very well).


    @Björn: Thanks for your offer but I will figure it out myself. That way I hope it will finally get into my head =D


    Schönen Tag euch,

    Theo

  • Hello Theo,

    I just wanted to be sure about the possibilities as I never worked with such big Images before. So to sum it up: I have to think about frame sizes only if I am planning to keep the complete image in the buffer. In my case it will work as a line FIFO as I am not planning to stop the image flow after the buffer.

    Yes, in case you do not need to store the full image think of the RAM as a large line FIFO. It will handle a 1D line stream, that is by definition: an image of infinite height.


    Certain side effects/limitation on the 1D image height are related to the simulation.

    Additional detail can be found here for the ImageBuffer.

    Latest the DMA will require a SplitImage or similar operator for 2D images.

    As I am working with the gate Operator I have to go into the 2D Image Format in front of my Image Buffer Operator.

    Please be aware that a 1D ImageBuffer in between of the Camera and the SignalGate will detach the exact timing behaviour from the line itself, since the RAM can potentially change the transfer timing.

    By using the PixelToImage operator you can sample the gate trigger-status into each line, store it through the RAM and then re-sample the bit to an gate again...

    In case you have questions to this, please feel free to contact me again.

  • B.Ru

    Closed the thread.
  • Hi,


    I just sumbled over a good example.

    This time I have one Image (420 MB) which I have to store completely in a FrameBufferRandomRead-Operator to sort the Pixels afterwards.


    This whould work with the Marathon VCX-QP because there I have a Ram-Size of 512 MiB.
    However, it will not work in the Ironman VQ8 as there I have only 256 MiB.


    Is this correct or did I miss something?


    regards,

    Theo

  • Hi Theo,


    In case of single 420 MB image inside a RAM module, you require at least 420 MB inside the FrameBufferRandomRead.

    For marathon 512 MB is fine.
    You can use several ones in parallel for ironman : 2 x 256 MB.

    Reason: First you write the full image into the buffer, then you can adress the readout.

    Hint: while one full(max dimension) image is occupying more than half of the RAM module no second image can be received while read-out period of previous one.


    Please be aware that the bit-depth of RAM module needs to be used by KernelElements*BitDepth*Parallelism! More details on this here: ImageBuffer, section Available Memory Space


    Best regards,