Posts by Johannes Trein

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

Quote from Sangrae_Kim

Hello Johannes,

Thank for your update.

We confirmed the increase in Jpeg decoding speed on the GPU.

** Test Result : 2048 x 2048 = 150fps , 2048 x 1024 = 295fps

Thanks.

Best regards.

Display More

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

Check an overview of new features and changes in

VisualApplets_3.2.0_Features.pdf

Also see release notes: Release Notes

Johannes

Check the thread New high speed JPEG operator and examples (VA 3.2.0)

Silicon Software Product Information PI-2019/ VA3-03out.jpg

Dear Silicon Software customer,

Dear Silicon Software partner,

The new VisualApplets release VA 3.2 is now available.

VisualApplets 3.2 contains a lot of new features. The most significant ones are the following:

The Compression Library has been updated with a new JPEG Compression Operator. The operator performs a JPEG compression of grayscale 8-bit images, includes header generation, and is scalable to any bandwidth. For JPEG compression of color images, a new user library JPEG_Color is implemented. The compression operator and library are suited for a wide variety of image processing applications, such as process monitoring, railway inspection, and image archiving or motion control, especially for medical image processing applications. The new compression Operator and user library JPEG_Color are available for microEnable 5 marathon and ironman frame grabbers.

For an efficient and reliable development process, VisualApplets 3.2 offers a new simulation engine and information on the maximal data throughput rate for each link: The new, much more powerful simulation engine gives a very realistic depiction of the data flow. Directly after designing the image processing, you can test and verify your algorithm. For monitoring and calculating the bandwidth on links during design time, the design window optionally displays the maximal data throughput rate of each link.

With the new Script Collection pane, it will be much easier for Tcl users (Expert feature) to manage, parametrize, and execute their Tcl scripts. Additionally, four new build-flow commands are implemented.

Good news also for Embedded VisualApplets (eVA) users: eVA platforms with Ultrascale or Ultrascale+ FPGAs are now supported as well.

Beside these exciting new features, VA 3.2. comes with a lot of other new features and improvements. For detailed information, please check the Release Notes in our online documentation.

Get the download link using the update tool in VisualApplets or contact your vendor.

Enjoy the new possibilities!

Hi Pier

I think it is not very likely that your question will be answered from someone outside of Silicon Software as it is quite complex. The Silicon Software members can support solving design issues or give you some ideas within the forum. So if you upload some VA design with edge detection we can provide some ideas. For getting a solution to your application please contact your sales representative.

So I hope to help you soliving your implementation issues with this project soon.

Johannes

Hello Lily Li

to get the latest release of VisualApplets click on Help -> Check for Updates. If you do not have a copy so far contact the sales team.

The official VisualApplets release does not support the Line camera from Dalsa at this moment due to incorrect handling of the CLHS specification by the camera. Please contact your sales representative for individual consulting.

BR

Johannes

VisualApplets 3.2.0 includes a brand new JPEG encoder
replacing the old one!

pasted-from-clipboard.png

• Super fast! Scalable to any bandwidth
  In comparison to the old operator with a fixed parallelism, the new operator allows arbitrary configurations to adapt to any bandwidth.
• Super flexible
  Compatible with Mono, RGB or Bayer CFA cameras or any other like IR or linescan
  One, two, three, four, ... JPEG encoders and cameras on the same frame grabber.
• Optimized for todays FPGAs
  The new operator will extensively use the FPGA features of the mE5 and mE6 frame grabber series as well as eVA devices using the XILINX 7 series and above. The operator is ready for future frame grabbers,
• Mono and Color
  The new implementations can be used for monochrome images and color compression.
• Ease of use:
  The JPEG output includes the JPEG file interchange format header. The DMA transfer can be directly written into a file which can be opened by any image viewer following the JPEG standard.

You can include the JPEG to any VisualApplets design. Mono, RGB, Color, Area, Line, including pre-processing, including 1 or several DMA channels, etc.

The microEnable 5 series frame grabbers offer enough FPGA resources for various configurations. The following table lists only some of the possible configurations.

VisualApplets Examples and Documentation

The usage in VisualApplets is very easy. For monochrome applets, you can directly use the operator. VisualApplets uses a lot of examples make your integration as easy as possible.

LINK: Check the VisualApplets user manual to get a description and location of the examples.

For color RGB and Bayer applets VisualApplets comes with pre-defined user libraries enabling color compression.

pasted-from-clipboard.png

LINK: Check the user manual for examples on VisualApplets color compression.

pasted-from-clipboard.png

Each of the user library elements comes with a dedicated help site. This is the same for the mono operator LINK.

Questions? Requests? Feedback?

Let us know if you have questions about the JPEG operator.

The user library elements for color compression are made for specific configurations. If you need another configuration please let us know and we might be able to generate your desired configuration.

Application Areas

• streaming to cloud services
• recording systems
• medical
• postal
• rail / road inspection
• security
• entertainment

No CPU load for compression with FPGA implementation!

sd

Johannes

Hi

first of all thanks to Robert B. I am very happy that VisualApplets users help each other.

First of all let me add some idea on the recursion algorithm. As Robert mentioned you need to add a seed just as Robert did in his example. Note that operator ImageNumber can be set to a single shot counter which avoids overflows and another seed in the second image.

The recursion loop will definitely require a buffer inside the loop. Otherwise you will obtain a deadlock when you use the implementation in hardware. Note that deadlocks cannot be detected with the simulation as they are timing dependent.

Lily let us know if the recursion shall be performed for each image or each line? Could you explain the desired algorithm to us?

About SplitImage. I assume you are using a line scan camera, so the output link of the camera module is set to VALT_LINE1D. Is that correct?

Otherwise if you want to convert from 2D to 1D use operator AppendImage. This module has a parameter to define the number of simulation lines.

pasted-from-clipboard.png

Lily you can attach your .va files to the post. Maybe this will clarify a little.

Johannes

Hi

currently there is no possibility over the DMA format. You could use a Metadata parameter or an EnumVariable module in your designs to make the information available. See the following screenshot which shows the two methods.

pasted-from-clipboard.png

Johannes

Hi

Quote from Pierre Chatelier

... if I emit a 12b stream, I get a 12b stream, whatever the FG_FORMAT value. Why would it be limited in that case ? This is just a incorrect information returned by the applet.

Yes it works but the setting of FG_FORMAT is simply not defined in VisualApplets.

Quote from Pierre Chatelier

it works with FG_GRAY10 : if I set a 10b stream, FG_FORMAT is set to FG_GRAY10 and my client software is informed that it must be interpreted as 10b. Why would 10b be different from 12b ?

You are right, there is no difference. 12 bit is simply not defined as it was not supported in older versions at all and not added to VisualApplets once it was extended. We have a feature request in our database for this.

Johannes

Hello Pierre,

VisualApplets can only set FG_FORMAT to FG_GRAY, FG_GRAY16, FG_COL24 and FG_COL48. So when you set a link bit width of 12 bit, VisualApplets will ignore it and set the default 8 bit instead.

FG_FORMAT is used for displaying in microDisplay. You can use the workaround to force microDisplay using 12 bit. For your software SDK integration FG_FORMAT can be ignored if you wish to.

Johannes

Hi Pier

I think your application requires the following tasks:

1. Find x-positions of fabric wires: Use a suitable algorithm like center of gravity, edge detection, slope, etc. The requirement is similar to a laser line detection. You could adapt the CoG algorithm from the SiSo example.

2. Get the frequency of the lines: The important question would be over which time the measurement should take place? The FFT operators are not available for mE4VQ4-GE, however the min-positions could be used to get the period time of exactly the last period. Besides that many more options exist. The selection depends on the requirement.

3. To detect the phase shift again the question would be: Use a specific area for the measurement or is the phase shift just the distance between two wires?

4. IO Output: I don't clearly understand you IO output format but this should not be the most difficult part of your application.

Johannes

Hello Jesse,

which exact information do you want to get from the frame grabber?

1. Is it the link property Max. Img Width of DMA 3 in VisualApplets?

2. Is it the actual image width of the last image transferred over DMA 3?

3. Is it the number of byte of the last image transferred on DMA 3?

Johannes

Hi Jesse,

thank you for the report. Yes I can see that the figure is not correct. We will update it with a new VisualApplets version.

Thank you very much!

(internal note: 7319)