Posts by B.Ru

    Hello Saito-san,


    Thank you for your question concerning compression.

    We have a JPEG compressor within VA that is lossy and will introduce compression artefacts.


    For lossless compression we do not have a direct operator.

    Things like run-length encoding is possible based on VA operators, but for real images including noise the efficiency / compression factor is limited.

    A run length encoding of the MSBs could be a straight forward way that reduces the amount of required memory a little.

    But that is proprietary and pretty application specific.


    Our runtime supports very secure mechanisms to use the host memory as transfer target for the real images and gives the compression approach to the host system CPU/GPU. But I am pretty sure that you would like to perform such a compression within the FPGA and implement it in VA.


    In case you have a white-paper on a simple lossless compression I will have a look into it and let you know if VA operators can be used to assemble such an approach.


    The only operator in VA that may help is:

    PackBitsRLE

    I am sorry, that I do not have a nice example on this.


    Best regards,

    Björn

    Hi Simon,


    The attached VA Design Pre-Processing_ObjectDetector_v017.va, top-level view:

    pasted-from-clipboard.png


    will work together with image BlobTest.tif.zip nicely and is nearly self explaining within the H-boxes:

    Segmentation + Classification + ObjectSorage


    Concerning your points:


    To 1.:

    A table inside H-box Classification will show where (parallelism + bits) you can find each object feature for classification.

    The features of general interest are normally Area, COGxy, Width and Height. Additional features to the existing ones would be beneficial, but these are not delivered by a single-pass approach. While the other features like Contour-Pixels (orthogonal/diagonal) and the X/Y offset within the binary image are available already. Compacticity can be calculated.

    I am really looking forward to see your additional results.

    From the application specific view a label-image would be the most requested feature, as far as I know.


    To 2.:

    Above you can find a test-image I am currently using as source for implementing an innnovation-time related project.

    I can not share real customer data.


    You can contact me directly for additional questions.

    Dear Silverfly,


    In the log I found:

    • PCIe Performance: PCIe is not highspeed capable
    • Currently trained PCIe speed: Gen 1 x4
    • ... payload size 128

    That at least indicates that 4 PCIe lanes are used, and a PCI payload size of 128.


    The facts above should deliver above 600 MB/s as DMA performance in your system.


    You can do a DMA performance test in mDisplay manually if you want to:

    1. Load a Acquisition Applet in mDisplay(X)
    2. Enable the simulator and the ROI at the expected target resolution
    3. Increase the frame rate step by step until you can see the buffer overflow and balance this to a working frane rate
    4. Resolution * Framerate * Pixeldepth = maximum target bandwiodth of DMA/PCIe

    Dear Saito-san,


    Thank you for this feedback. I forwarded your feedback to the product management.


    For now you can use the ParameterTranslation in order to rebuild certain details as far as possible with the aspect of making AcquisitionApplet's similar VA Designs.

    Dear Jayasuriya S.,


    Please check the DMA for the VA Design manually in microDisplay.

    So you have to build a CreateBlankImage approach instead of a camera into the design.

    Using SourceSelector would enable you to include the camera and the simulator at the same time.


    The CreateBlankImage operator would deliver as much data as the DMA can transfer.

    In microDisplay(X) you can see the obtained bandwidth and use this as a good indicator for the possible DMA performance.

    In case of further questions on this do not hesitate to contact me.

    Dear Silverfly,


    The amount of FPGA external RAM ressouces is currently restricted to a maximum of 4.

    In case of symmetric configurations and synchronization in between of the cameras an approach with InsertLine and AppendLine with ImageFIFOs directly behind the cameras it may become possible to write all camera image stream data into a single RAM ressource. That is additionally a question of the required bandwidth, because a single buffer needs to handle all 4 camera-streams at the same time.

    I have installed a Marathon VCL frame grabber with the runtime v5.6.1 and flashed my applet there. When I tried to do performance test in Micro diagnostics , I received an error attached here. Could anyone help on this?.

    forum.silicon.software/index.php?attachment/423/

    Please contact your local support center for issues like this.


    Basler Support contact list...


    From my point of view the not running perfromance test is not a real/hard issue as long as the hardware itself is present in microDiagnosis and microDisplay.

    It can be related to different version of applet in graber and existing file in runtime.

    Please let me know if our support could help you.


    Thank you.

    Dear rvdbijl,

    is the Ironman board limited to 4 DMA and 4 Imagebuffer instances? VA 3.2.0 won't let me add a 5th one in my project and pass Design Rules Level 1. The resource index won't go over 3 for either one

    The number fo DMA-Transfers is limited to 4. You can use InsertImage/AppendImage, InsertLine/AppendLine to show two images below of each other or next to each other using the Insert*/Appen* approach; please take care that these approaches require some synchronization memory for serializing lines or images. For two results/images that exist at the same time, please use InsertLine/AppendLine and a ImageFiFo (size 1 line per input) to handle the waiting time for the lines being forwarded one after the other. An image serialization is normally "cheaper" concerning hardware ressources that an additional DMA channel.

    The amount of ImageBuffers (real frame grabber hardware RAM modules) is limited to 4.

    Dear customer,


    Concerning your question. If you want to run mDisplay with a single camera and multiple DMAs,

    please make the following setting:

    mDisplay -> Tools -> Settings -> Check "Ignore Camclock status" and apply:

    304-pasted-from-clipboard-png


    That may help to start all DMA according to your requirements.


    If that is not showing the expected behaviour, then please paste your VA design here if possible.

    Thank you.

    Dear Theo,


    The Overflow parameter of the ImageBuffer operator is not stable enough to get a reliable feedback.

    That can not besolved by a parameter translation itself.


    This VA design OverFlowDetection_v01_BRudde.va will be a reliable approach:

    pasted-from-clipboard.png

    It measures the amount of pixels going into the FIFO and leaving it.

    By this the current fill-level can be seen while being the first memory behind the camera (infinite source = enabled) and directly in front of the first RAM related memory (inifinite source = disabled) operator.

    So in case the first RAM memory operator is not accepting or refusing the arriving data this can be detected.

    Additionally there is a EventToHost operator that sends an overflow event in case the small FIFO is geting filled up.

    A progressive detection on the basis of an OK, critical and error fill-level are used.

    Dear Pierre,


    I hope I understand or interpret your question correctly:

    The DMA transfer (DmaToPC's FG_FORMAT) mentions the wrong bitdepth?

    • 8 bit instead of 12?
    • Can you please check if the camera is sending 8/10/12 bit as expected?

    In case the camera sends 8 bit and the design expects 12, the representation of the data would look wrong for 12 bit visualization.