Posts by Johannes Trein

    Hi JSuria


    let me add some ideas:

    - enable mDisplay -> Tools -> Settings -> Check "Ignore Camclock status"

    - disable mDisplay -> Tools -> Settings -> Check "Use GenICam Camera parameter"

    - start the acquisition in microDisplay FIRST

    - after start the acquisition of the three cameras in GenICam explorer

    - last start the trigger


    If your process has multiple DMA ensure that all DMAs are started.


    I hope that one of these ideas help you. Basically your explanations are all correct and we have bring this to work in microDisplay before. In an SDK application it is no problem anyway as the cameras are started manually anyway.


    Johannes

    Dear Saito-san


    please see attached VA file which is used to output the average of a bouncy encoder and similar to the explanations given by Carmen described above.

    You need to add another DIV by 512 to get a 512 higher frequency.


    When I have time I will make a more detailed explanation of this example in another post.


    Johannes

    Hi Arjun


    Xilinx shows some system recommendations on their web pages like in https://www.xilinx.com/product…-tools/vivado/memory.html


    For mE5 marathon FPGAs Xilinx states that a maximum of 3GB RAM is used. For the future frame grabbers which are currently in development XILINX states a peak memory usage of 14GB.


    Xilinx does not recommend any specific CPU and speed. The build process for recent FPGA uses all cores.


    For VisualApplets you can use any recent standard PC. Simulation can be speed up with fast SSDs and a fast CPU. Multi cores are barely used in VisualApplets.


    Johannes

    Hello Oliver


    with the new JPEG operator released in VA 3.2.0 (See New high speed JPEG operator and examples (VA 3.2.0)) you don't need to generate the header anymore. So there are no specific JPEG functions required in the SDK sample. Simply grab the data and write to a file with extension .jpg. If you want to decode the image of course you will need a decoder. You can use any you like such as JpegBitmapDecoder coming with Microsoft C#.


    See C# wrapper documentation.


    Let me know if this'll help you


    Johannes

    Hi Cam


    That would be a nice application. The solution strongly depends on bandwidth requirements.


    The most ovious solution woul be the following:

    - store each input image in DRAM using operator FrameBufferRandomRd

    - Use CreateImage, ModuloCount, DIV, mayber SIN, COS, etc. to generate the read column and rows

    - read from DRAM


    An example using FrameBufferRandomRd together with CreateBlankImage can be found HERE. It is a more complex task but can give you some idea.


    How is the "new line" defined. Could you use a LUT to store point and gradient?


    Johannes

    Hi Janek


    In example Scaling a Line Scan Image you can find a design using scaling in x-direction using a lookup table. The difficulty of the implementation is the x-direction as we have to conquer some difficulties at higher parallelisms. In Y-direction it is more simple as you can do this as a predecessor of the x-scaling.

    To be honest the example is not the easiest to understand as it is strongly optimized for a higher parallelism.


    I don't recommend to use the examples Geometric Transformation and Distortion Correction. They will solve your problem but are implemented for more complex transformations. Your implementation should use BRAM instead of DRAM


    Let us know your input parallelism (bandwidth requirement) and maximum resolution of the image which has to be scaled. Mybe we can find another example as we have done plenty of these implementations.


    Johannes

    Dear Saito san


    we are aware of this type of request. Unfortunately AcquisitionApplets use a lot of additional software which makes it impossible to rebuild its functionality with VisualApplets.


    At this moment your request cannot be solved. The required processing functions of the AcquisitionApplets have to be rebuilt with VisualApplets.


    Johannes

    By the way, the design I provided has been successfully synthesized, and it reports timeout at runtime instead of timing errors during synthesis.

    Oh sorry. I did not see that.


    Are you using microDisplay? I have an idea: As you are using GigE Vision both cameras needs to be started at the same time and be 100% synchronous. microDisplay can only start one camera when you click the "play" button inside the program.


    If you check the buffer fill levels I think that one of them will be in overflow while the other one will be empty.


    There are two solutions:

    1. Use the new version of microDisplay called microDisplayX. It is included in runtime 5.7.0 and you can find it in %sisodir5%/bin/microDisplayX.exe. There is a synchronization option which can be used to start all cameras at the same time
    2. If you want to use the old microDisplay you need to start GenICam explorer in parallel and manually start the second camera by writing to parameter "StartAcquisition"

    Note: If you set both cameras to the same frame rate they will still be a little asynchronous. Soon or later the buffers will be filled. You ned to externaly trigger the cameras to be 100% synchronous.


    Johannes

    Hi Michael


    you wrote

    Thus, the pixel at (0,0) would be the least significant byte of the pixel, and the pixel at (1,0) would be the most significant byte. The pixel at (1,0) would have the incorrect endianness, so it would need to be “flipped.”

    Hm. I can't see that it is flipped from you CL Spec image.

    8-Bit Mono Full 8 taps mode also has a ninth 8-bit pixel which does not exist in 16-Bit Mono Full 4 Taps mode, so this must be sent to the trash.

    If you set the VisualApplets operator to 8 Tap it will not use the nineth pixel.


    I think the solution is very simple:


    • Use FullGrayCamera operator set to 8 Tap static with a Max. Image Width on its output link doubled compared to the cam width.
    • Use operator CastParallel to get 16Bit
    • Use an adaptation of the Tap Sorting examples to sort the four taps.

    I've added a VA sample. It is a little simpler compared to the examples in the VA installation directory but does the same with a little more FPGA ressources.


    Johannes

    Hi


    assume the following example:

    Input

    - CL-Base, 2 Tap @ 85MHz = 170MP/s

    - 16MP/image

    - 8fps

    - transfer time for 1 frame = 16 MP / 170MP/s = 0.1s


    Design:

    pasted-from-clipboard.png


    The camera peak bandwidth is 170MP/s

    The average camera bandwidth is 8fps * 16MP = 128MP/s

    --> Parallelism 4 is sufficient


    After "Remove3of4images":

    Peak bandwidth is still 170MP/s

    Average bandwith is 128MP/s / 4 = 32MP/s

    --> Parallelism 4 is sufficient


    After PARALLELdn the link bandwidth is 62.5MP/s. Therefore we need the buffer.


    To calculate the buffer fill level we subtract the output bandwidth from the input bandwidth to calculate the fill speed:

    Fill Speed = 170 MP/s - 62.5 MP/s = 107.5MP/s

    After one frame the buffer fill level is: 107.5MP/s * 0.1 sec = 10.75MP

    As there is a transfer gap after each frame the buffer has enogh time to get empty. It will be empty after 0.1s + 10.75MP/62.5MP/s = 0.272s which is equal to the maximum framerate of a 16MP image at parallel 1: 62.5MP/s / 16MP = 3.9fps --> 1/3.9fps = 0.256s (which is the same value as above with some rounding errors)

    pasted-from-clipboard.png


    The explanation above is only valid for line or pixel buffers like ImageBuffer or ImageFifo. If you are using a frame buffer you need to store the full image. See http://www.siliconsoftware.de/…ntent/library.Memory.html


    Johannes

    Hi Pier


    If you don''t want the value of GetStatus beeing overwritten with the next image you can do the following:


    use a fifo, use ImageValve with SetSignalStatus at the gate input, use GetStatus.

    You can now read one value after each other. The software needs to sufficiently fast enough to avoid a fifo overflow.


    Operator ImageMonitor can also be used for this.


    BR

    Johannes

    Hello silverfly


    from a logical point of view this is not possible. You will need a frame buffer between RemoveImage and PARALLELdn to buffer the bursts.


    You can calculate the required buffer size by using a function for the input. Slope = input bandwith. Gap = frame gap minus a second function = parallel 1 e.g. 160MP/s. Maybe your previous buffers or a fifo can be sufficient.


    Johannes

    Hello Oliver


    you want to output the pulse at the end of the frame correct? So if the blob ends at line 545 you still want the output at the end of the frame, correct?


    To do this you need to use operator IsLastPixel like in the example shown in the following figure.

    pasted-from-clipboard.png


    I hope this solves your problen.


    But please note: The DMA can influence the timing of the processing. To implement a 100% solution you need to resynchronize the output with the trigger, encoder or camera timing and pipeline the data in a fifo.


    Johannes


    Hello Sangrae


    may I know which decoder you are using for GPU decoding? This is also very interesting for me.


    Johannes

    I like to mention one interesting behavior of the operator:

    If the header generation is acitvated the operator will start the output of the header BEFORE image data will arrive at the operator intput. So the operator output transfer is started earlier to the image data transfer.


    This can cause problems for example in the following cases

    • Measuer the latency with operators FrameStartToSignal and SignalToDelay. Use FrameEndToSignal instead
    • putting a SourceSelector after the JPEG_Encoder. Chaning the source will be affected to the next image only as transfer of a current image has already started
    • For eVA devices ensure that the output is capable to accept data transfer earlier to the sensor transfer

    Johannes

    Hello Sangrae_Kim


    Thank you for testing the JPEG and thank you for the feedback.


    For all microEnable 5 marathon frame grabbers we recommend to use XILINX Vivado instead of ISE. The build time is much faster than with ISE and you get successful builds with Vivado where you will have timing errors with ISE. Vivado is free except for the marathon VCLx frame grabber.


    With Vivado you should not get a timing error for JPEG_SingleFullAreaBayer.va with 170 MHz. However, if you use 160MHz or 125 MHz the implementation will still work but is a little slower.


    Concerning your question about JPEG decoding in the PC:

    The decoding speed depends on

    - does the decoder use CPU or GPU

    - is the decoder optimized for restart intervals within the JPEG files

    - are you decoding multiple files simultaniously in multiple CPU cores or one after each other?

    - if you write the files to HDD and reload for decoding the HDD speed might be the limiting factor.


    There exists many articles in the internet for benchmarking of JPEG decoders. I heard that the mangolibrary uses a very good decoder, but have never testet it.

    So for example this article: https://t0rakka.silvrback.com/jpeg-decoding-benchmark


    So at this moment I don't have a recommendation for the decoding. But it is good to collect some reviews in the forum.


    Johannes