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.
Get the download link using the update tool in VisualApplets or contact your vendor.
Enjoy the new possibilities!
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.
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.
VisualApplets 3.2.0 includes a brand new JPEG encoder
replacing the old one!
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.
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.
Configuration Mono / Bayer Frame Grabber Input Bandwidth JPEG Bandwidth Camera Link Dual Base Mono mE5-MA-VCL 2 x 255 MB/s 2 x 255 MB/s, total 510 MB/s Camera Link Single Full Mono mE5-MA-VCL 850 MB/s 850 MB/s CoaXPress, 1 camera, 6 Gbit/s, 4 links Mono mE5-MA-VCX-QP 2400 MB/s 2400 MB/s CoaXPress, 2 cameras, 6 Gbit/s, 2 links Mono mE5-MA-VCX-QP 2 x 1200 MB/s 2 x 1200 MB/s, total 2400 MB/s CoaXPress, 4 cameras, 6 Gbit/s, 1 link Mono mE5-MA-VCX-QP 4 x 600 MB/s 4 x 600 MB/s, total 2400 MB/s Camera Link Dual Base Bayer mE5-MA-VCL 2 x 255 MB/s 2 x 765 MB/s, total 1530 MB/s Camera Link Single Full Bayer mE5-MA-VCL 850 MB/s 2550 MB/s CoaXPress, 1 camera, 6 Gbit/s, 4 links Bayer mE5-MA-VCX-QP 2400 MB/s 7200 MB/s CoaXPress, 2 cameras, 6 Gbit/s, 2 links Bayer mE5-MA-VCX-QP 2 x 800 MB/s 2 x 2400 MB/s, total 4800 MB/s CoaXPress, 3 cameras, 6 Gbit/s, 1 link Bayer mE5-MA-VCX-QP 4 x 600 MB/s 4 x 1800 MB/s, total 5400 MB/s
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.
For color RGB and Bayer applets VisualApplets comes with pre-defined user libraries enabling color compression.
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.
- streaming to cloud services
- recording systems
- rail / road inspection
No CPU load for compression with FPGA implementation!
- Super fast! Scalable to any bandwidth
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.
Lily you can attach your .va files to the post. Maybe this will clarify a little.
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.
... 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.
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.
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.
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.
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?
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)
you need to update VisualApplets instead of the runtime. As mentioned VisualApplets version 3.2 will generate correct SDK examples.
However, of course you can manually correct the generated source code. Here is one example:
we updated the SDK generator recently with VisualApplets version 3.1.2. See Relese NotesQuote
SDK code generation has been updated so that generated code compiles with recent versions of the runtime API. (8841)
There was an error in
for reading and writing of string (char ) parameter. So the runtime was changed some time ago. Thus the SDK generator in VisualApplets had to be adapted.
we have a VisualApplets example for shading correction which also uses an offset correction. See LINK
This example and the corrections we usually do are based on the idea of saving the dark noise as an image file to the PC and uploading it back to a correction value buffer on the frame grabber.
If I understand you explanations correct you want to directly use a camera image e.g. the first image after acquisition start and store this in a buffer on the frame grabber. I made a simple VisualApplets example for this. You can select a camera image for "re-use" in a loop.
Open the design and start the simulation for e.g. 10 image. The build in image simulator will generate a first image of pixel values 100. After this a rolling pattern is generated. The design will use this first image as reference. Note that you need to load any 1024x1024 image do Sim Source "Any dummy imge as PixelToImage has no simulation" as PixelToImage cannot be simulated.
The design will not do the correction for a given area e.g the first four pixel. The implementation is quite simple.
See VA file attached.
unfortunately this is not possible yet. I made a feature request but it has not been decided yet if and when it will be implemented. (8437)
It seems that I misunderstood the use of LoadCoefficients. It must be set to 0 then to 1 to trigger loading. The doc is not clear on this point.
are you using any version of microDisplay? In fact you simply need to rewrite a value 1 to LoadCoefficients. My doubt is that the GUI of microDisplayX (the new microDisplay of runtime 5.7) does not rewrite the parameter if the value did not change.
Did you check the SDK example in "%sisodir5%\SDKExamplesNew\examples\fglib\Parametrization\FgParameterIteration\FgParameterIterationExample.cpp" ?
Maybe you'll find your answer there.