Posts by Johannes Trein

    Hi Saito

    Welcome to the VisualApplets forum!

    On a DMA transfer the width of each individual line is discarded. Only the frame data will be stored in the PC memory. By using FG_TRANSFER_LEN the number of byte of the transfer can be obtained. Any line length information is discarded.

    So information about the image dimensions have to be appended as a trailer to the image.

    Solution 1:

    In the post Extact ROIs from linescan images using a Blob Analysis images of different sizes are cropped using ImageBufferMultiRoIDyn operator. I think in this thread most of your question is answered.

    Solution 2:

    Instead of the presented solution above you can measure the current image width and height just before the DMA transfer.



    See the attached VA design.


    In microDisplay variable image dimensions cannot be displayed. Because microDisplay is a test only tool you could increase the size of each image with SyncToMax and SyncToMin to have a constant image size. However this is only for testing as it will require more DMA bandwidth:


    Let me know if you have further questions.


    Hi Pierre,

    Welcome to the forum!

    In VisualApplets an acquisition process is reset and restart when starting the acquisition or stopping the acquisition.

    A process without a DMA channel will be started immediately when the applet is initialized.

    Unfortunately the AppendImage operator has no reset parameter or clear input. So the only way to reset its concatenation is by restarting the process i.e. restarting the acquisition.

    It might be possible to rebuild the function using operator SignalGate. But this needs exact verification in hardware and as signals are used cannot be simulated in VisualApplets. The timing is crucial. I made a short sketch to show the idea. I am not very sure this will work but I am confident there can be a workaround.


    We have another thread where the reset of processes is discussed. See: Reseting operators, image buffer and signals


    A similar but much easier example is using the same camera input but uses one interleaved BGR and one IR output in separated DMA channels.

    The attached VA design can directly be build and used in microDisplay. The attached VA example will show how to synchronously get the images and write RGB and Gray TIFF files to disk.



    Enable the build in simulator so you don't need a camera.



    Hello Sangrae Kim

    welcome to the forum.

    There are two examples for bilinear linescan cameras in VisualApplets 3.1

    Advantages of the Bayer De-Mosaicing in the frame grabber instead of the camera are:

    • Higher bandwidth: Transfer the RAW data on Camera Link and increase the data inside the frame grabber with high speed DMA channel
    • Higher Quality: The frame grabber can do a very high quality Bayer De-Mosaicing. With VisualApplets you can use any algorithm you like.

    We also have AcquisitionApplets for these cameras to use them on A-Series.

    You are asking for camera EV71YC4CCP1605-BA0 of E2V. This CXP camera can only output RGB color but not RAW Bayer data. In this case you can directly use the RGB data from the camera and don't need color interpolation. Unfortunately the advantages of the FPGA processing on the frame grabber cannot be used with this camera. See the manual of the camera User Manual ELIIXA+ 16K/8K CXP C OLOR Section 2.2

    Best regards


    Hi Aron,

    microDisplay can only display images having the same line length. It will be the one you define in the DmaToPC operator and will be by default the link properties.

    The only chance you have is to expand the line length of the blob output to the line length of the image. However this will generate an enormous data overhead in the DMA transfer. I do not recommend this solution.

    Anyway for demo purposes in microDisplay it might be OK. See the attachment



    Hi Aron

    a DMA transfer will always discard the line length information. The software application needs to know about the image dimensions and pixel format of the transferred image. microDisplay will use the link properties of the VisualApplets design to get these information.

    In your case you used SetDimension and defined the output format to 8192 x 6 @ 8 bit.


    If you change the dimensions to 2 x 65536 microDisplay will display your results as you need.


    Note that this change does not change anything in the implementation or DMA transfer. It is just the way microDisplay will show the DMA result. The number of byte of the transfer are the same.


    Hi Lothar

    you can use 12 Bit DMA output on marathon and ironman frame grabbers without limitations. On marathon the product of parallelism and bit with has to be a multiple of 8,

    So parallelism 2, 4 and 8 are allowed among others. Parallelism 16 is not allowed as it will exceed the 128 Bit. To use the maximum bandwidth of the marathon you need to cast the parallelism to get 8 bits and parallel Dn to 16.


    The PARALLELdn might add dummy pixel at the end of each line. You can append all image lines to a single line to avoid this.


    microDisplay cannot show the result of this correctly as it will display the result as 8 bit and not 12 bit as well as the full image in a single line.

    Internal note: FR 8543



    Hello Jayasuriya,

    We totally revised the C# SDK interface in the current runtime versiones. I recommend to use the current Runtime 5.6 which includes the C# interface. See subdirectory \SDKWrapper\CSharpWrapper

    See the documenation in…per/doc/CSharpWrapper.pdf

    You can find the full setup in…-v5-6-win64-with-applets/

    Let me know if you prefer the old version instead.



    Hello Jesse

    Thank you for your post. You obtained a very good understanding of VisualApplets.

    The platform microEnable 5marathon(mE5_VCX-QP) has shared memory concept.

    So these RAMs data width needmore than 64*1(RMA1) + 8*8(RAM2) + 8*9(RAM3) = 200 bit.

    Then increase parallelism to 32 before RAM1 and RAM2, and set ffc_factor parallelism to 4.

    So these RAMs will share 256 bit. Then RAMs all have enough bandwidth. Is it right?

    You are using a mE5-MA-VCX-QP. The total bandwidth of this platform is 12.8GB/s. To use the full bandwidth you need to use all 512bit = 64 byte of each DRAM.

    Now lets have a look at your configuration:

    - RAM1:

    Required 1200 MPixel/s (Max CXP6x2 Speed)

    Use parallelism = 32

    --> 1200 MP/s / 32 * 64 byte * 2 = 4.8GByte/s used in RAM1 (*2 because of read and write)

    If you use parallelism = 64 instead you will only use 2.4GByte/s in this RAM

    - RAM2:

    Same as RAM1: 4.8GByte/s. Because you are using 6Bit/s you cannot use parallelism 64,

    - ffc_factor:

    Required: 1200 MPixel/s. Because of 16Bit --> 2400 MB/s

    Unfortunately operator CoefficientBuffer is inefficient for the configuration with only one link. See explanations in this post: CoefficientBuffer: Maximum memory size and bandwidth on marathon frame grabbers


    So you need to change it to a configuration with 8 output links:

    Therefore the total required RAM bandwidth is

    RAM1: 2400MB/s (at parallelism 64)

    RAM2: 4800MB/s

    ffc_factor: 2400 MB/s

    Total = 9600 which is less than the theoretic maximum of 12800 MB/s. Therefore the memory bandwidth is enough.

    If move this design run on mE5VQ8-CXP6B. mE5VQ8-CXP6B doesn’t has shared memory concept.

    The RAMs have independent data width. So I do not modify the parallelism to 32 and RAMs all have enough bandwidth?

    On mE5VQ8-CXP6D you also have a bandwith of 3.2 GB/s for each of the four individual DRAMs. The data width is only 128 bit.

    RAM1: Parallelism 16

    RAM2: Parallelism 16 -> you will need to use two ImageBuffer operators in parallel

    ffc_factor: 4 outputs at parallelism 2

    This design use 96% LUT with mE5_MA_VCX-QP. It is possible to add applet in the future.

    I try to reduce parallelism to 4, and modify board frequency to 250 MHz( Compilation will fail(CmopileError.PNG).

    If I want increase board frequency, Is there any detail in design that needs attention?

    You can change the FPGA clock for marathon frame grabbers but we cannot guarantee that you will meet the timing requirements of the FPGA during the build process. In practice it will always work with 125MHz. Up to 160MHz you have good chances to meet the timing. Everything above will most likely not work correct.

    The DRAM will not get faster when you change the FPGA clock. It it will only affect the speed of processing between the operators i.e. less parallelism required.

    In your case you need to save some FPGA resources. You are using 96% LUT but only a few of the embedded ALU types.

    Here are some tricks to reduce LUT and use ALU:

    1. Use ADD instead of FIRoperator like for the mean filter:


    2. Use the same idea for the Gauss and Laplace filter


    3. Replace SCALE by CONST and Mult operator. Mult will use ALU, Scale will use LUT

    4. Use DIV at low parallelism

    I hope my information will help you to solve this project.



    Hi Mike,

    today I could test the apple in frame grabber hardware on FPGA. The "" runs sufficiently fast enough for your application.

    See the following screenshot.

    We get 1024x1224*47fps = 58MPixel/s which is already the theoretic maximum of parallelism 1. As you will need 20fps only the applet is much faster than your requirements.


    Applet "" can be used for faster inputs like non-downsampling or Camera Link inputs. I needed to increase the parallelism after the buffer to use the fast speed. So the "fast" file above is incomplete. I will update this file for others having the same request.


    Hi Mike

    if your camera runs at 2448 x 2048 * 20fps with 12 Bit packed format the bandwidth will be 150MByte/s which is more than the theoretical maximum of Gigabit Ethernet vision.

    Anyway I made two designs which fulfill your requirements.

    You can fully simulate the design and test the maximum bandwidth in hardware using the build in pattern generator. You will need a Silicon Software mE4-VQ4GE FPGA frame grabber together with VisualApplets for testing. The applet can be adapted to other frame grabbers but needs some modifications because of shared DDR3 memory compared to the DDR2 on the microEnable IV.

    Note: DRAM gets slow when it comes to non-linear write or read access. That's why such a simple task of 90° rotation is difficult for both technologies FGPA frame grabbers but also standard PC systems. The "fast" implementation uses all four DRAMs to increase the bandwidth.

    At this moment I have no access to frame grabber hardware so I could not measure the resulting bandwidth. Once I have access to the hardware I will do the measurement.




    Hi Jayasuriya

    Yes the applet that you have provided is working well!. Lets consider a scenario like, " if i generate 200 images and it has a pixel with value 1 at the 100th row of it, then in simulation it will be separated as two images each of height 100 where in the first image only a pixel 1 occurs". Here I want to set that particular pixel value to 1 for the next 10 images i.e from 101 to 110 lines of the 2nd image in the simulation , but in the output I get pixel value 1 at the 100 th row only. Could you please give me a solution where this SetToSequence works even between set of images?

    It will work correct in hardware. In the simulation the 1D protocoll is considered as 2D images. Therefore, if you want to simulate a sequence of 200 frames you need to set SetToSequence_To1D_LinesToSimulate = 200 to get a single 1D image.

    I like to mention one more thing: If the number of past images is much more than 10 or dynamic you should consider a loop operation. Check the rolling average examples in the VA documentation for this.


    Hi Jayasuriya

    the attached VA design should solve your task.

    It generates a random pattern representing your input images. Next all small images are appended to a single image of infinite height i.e. 1D image. Now we can check if one of the pixel in the same column of the last 10 rows was 1 and output 1.

    To simulate the design you need to set the simulation cycles to 100 which is the same value as in SetToSequence_To1D_LinesToSimulate.





    Hi Mike,

    image rotation is a task for an FPGA which cannot be solved by the one algorithm. Factors are bandwidth, FPGA and board generation as well as specifications for the rotation.

    To you need a fixed rotation by 90, 180, 270°? Or a variable roation by e.g. 15°? Should the rotation angle be dynamic or static?

    We have different examples included in the VisualApplets example list. See the examples in…ric%20Transformation.html

    These examples can be adapted for rotation only. Depending on the bandwidth requirements they work well with small rotation angles.

    For 90° rotations the implementation will always depend on the image dimensions and bandwidth requirements.

    I hope my post will give you some ideas for your further work on this.