Vision Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

There are multiple places where we can configure constants in Vision Assistant, but which are not available inside LabVIEW.

 

For example: IMAQ GetKernel is severely limited by the kernel size (3,5,7). Nowadays, images are larger and computers are faster, so we often require larger kernel sizes. It is possible to create larger kernels in Vision Assistant, so porting that functionality should not be a problem.

 

Also, Vision Assistant provides more palettes than IMAQ GetPalette. (DICOM Hot Iron, DICOM PET etc). 

 

In both cases, it is possible to create code from Vision Assistant and copy-paste the constants, or create "custom" versions of the vis. But this is such a waste of time.

 

Problem:

I need to acquire images from a camera and rotate them 90-degrees counter-clockwise on a cRIO-9034 target. Rotating the image on the camera sensor is not supported by the camera.

 

Current situation:

IMAQ rotate.png

It is currently possible to rotate an image using “IMAQ Rotate.vi”. This VI has a floating point input angle which can be set to 90 degrees. It is however a bit slow (around 80 ms on a cRIO-9034 for a 3840x1200 image). It should be possible to implement a faster way of rotating an image when the angle is in increments of 90 degrees.

 

My suggestion:

Create a new IMAQ vi for rotating images in increments of 90 degrees. The VI could be similar to "IMAQ Symmetry.vi" which can be used to flip images horizontally and vertically.

 

It would be nice to be able to get multiple circles out of IMAQ Find Circular Edge. For example, if I was interested in the smaller circle below, I could sort the results by size.

Find circular edge.png

The existing LineProfile output is rather unintuitive. It gives you a dx but the dx seems to always be 1. This is made apparent by taking line profiles in a radial pattern. The profiles between 0° and 90° return smaller arrays even though the lines are the same length. My suggestion is to allow the user to select the existing behavior but make dx accurate or to interpolate and use a step size of 1 pixel.

IMAQ Line Profile Improvement2.png

 

Hi !

I have to make a project on Labview involving reading 2D bar codes (Datamatrix) with a bar code reader Matrix 210N. A software is given with this bar code reader called dl.code, to test and configurate it. I want to know if it's possible de create a communication between Labview and this dl.code software. I want to have all the informations that i need from this software on Labview so that i can work on my Datamatrix (processing datamatrix and saving informations in an Excel file)

Thank you for your help 🙂 🙂

Hello,

A Coordinate System is not actually functional in measurement applications.

 

When we define a coordinate system, it should set the x axis and the origin as 0,0 in mm or pixels depending on the calibration. Currently coordinate system is only working to define a ROI with changing positions. It always get the positions based on the camera's axis. But it also should work like a real coordinate system where you can get X,Y positions of a circle based on a defined coordinate system.

 

Currently, I am trying to create my own coordinate system by calculating angles, cosines etc. but this function needs to be implemented in standard coordinate system functions.

Hello, 

I'm working on a school project which is a resistor sorter. I'm tried to use the color segmentation from the Vision assistant but I couldn't get a match because the clasifier I used was based on a resistor and can't be used if I changed the resistor. I've also tried this VI but I can't determine the color code via the RGB profil .

1/ How can I make a clasifier file to include all possible colors? 

2/ How can I modifie my VI to get the RGB values of only the bars? 

I have run into this problem with the Vision run time, Vision Acquisition run time since I began using Labview. The problem here is that every time I upgrade my development software for example Vision Development Module 2016 to 2017 then update my customers they need to actively re-license both the VD run time and VA run times. This seems to make no sense since both run times were already activated in the previous version. This is a real issue when you are updating software on customers machines that have no internet access. The Vision Development run times need to automatically transfer from version to version since the Vision run time keys are good indefinitely for updates. This would prevent customers from having to re-license yearly like they do now which in my opinion does not make sense. At the very least there could be a way to add a 20 character code problematically when updating versions so users don't have to work their way through NI's license manager. 

With the release of LV 2017 and therefore Vision 2017 I expected the 2GB limit to be gone.

Unfortunately and with great diappointment I have found out that this was not the case and it's still not possible to create or handle image files greater than 2GB even in LV 64bit 2017.

Latest linear image sensors can go up to 32.000 pixels (per line and per channel) and we currently use a 16K sensor in our camera and easily can exceed the 2GB limit when we scan long materials specially if 16bit precision is required and RGB color is also needed. This means that we had to implement several tricks in order to break down the image size (we process each RGB color layer as a separate image file and divide the image in several chunks) but we are still anyway experiencing many bottlenecks and are frustrated in the software development because we cannot use many of the exhisting Vision tools that are limited to 2GB. And of course VISION/IMAQ libraries cannot handle image processing when image information is distributed into different images and therefore we had to write our own libraries (even for image viewing) so as to handle the images properly. 

Furthermore, despite the TIFF format is limited to 4GB (not 2 GB) it's relatively easy to split the image file into separate TIFF files while it's not easy to handle or process image data in separate chunks or channels. Furthermore there are also other image formats that allows for very large file sizes (i.e. BigTIFF which is extremely easy to implement as it's only a 64bit extension of the currently 32bit limit in the TIFF format).

 

So my suggestion is: to break the 2GB limit and finally allow handling very large image files directly into Labview and the Vision libraries !!!

 

Current situation:

More and more image sensors do support bit depths of more than 16Bit.

Just two examples: Aptina MT9M034, Omni Vision OV10640

 

Currently it is not possible to handle image from those sensors within LabVIEW except as a 2D-Array / Matrix.

Using the SGL image type would be possible on the first sight but it has several disadvantages: storing of those image is not possible and a lot of image processing and calculation function do not support SGL.

 

Improvement:

Add support for the image types U32, I32 and RGB128. Personally I see the priority at U32 and I32 because those types are needed to handle the RAW data from the sensors.

Very important: Do not just add those types to your typedef! There must be a real support from all basic functions!! Basic functions are in my opinion / for my usage: write to file, read from file, all functions in the palettes "Vision Utilites", "Processing", "Filters", "Operators" and the functions "Histogram", "Histograph",  "Line Profile", "ROI Profile", "Linear Averages" and all other statics functions.

The zoom tool of the image display control is antiquated. Currently (Vision 2016), you select it and then click in the image to zoom by a fixed amount.

Consider upgrading its capabilities to match modern UIs:

- Selecting a rectangular ROI with the zoom tool should zoom to that ROI, i.e., the ROI should be expanded to fill the imag display control.

- support mouse wheel (and touch screen if needed) to act as a zoom in and out no matter which tool is selected.

- support fixed aspect ratio hot key (e.g. Ctrl key): zooming with the above ROI selection while the hot key is pressed will zoom the image to fill the display with the largest (or smallest) dimension of the ROI.

 

Feel free to add suggestions below.

 

As the title says.

Currently, there is an ellipse tool, a rotated rectangle tool, but no rotated ellipse tool...

But while we are at it, why not allow rotating ANY ROI (or selection, whatever you want to call them)?

 

Application example: let the user define a ROI in the image and rotate it (as an overlay first, but as a final cut and paste later).

In some applications I've had better OCR result using Tesseract (https://github.com/tesseract-ocr) than NI's OCR.

One thing that is nice with Tesseract is that in requires no training like NI's OCR does.

 

So it would be nice to have both option integrated in VDM and VBAI.

there are some vi in vision toolkit that their controls have not any useful information in labview help for user  so many ability of these vi are not discovered by LV user like  me 
for example IMAQ Particle Filter have input control with name of  selection value  inside this cluster we have item with name of Measurement Parameter  that have many mode to select but no detail information for them to know what kind of ability they have 
I think in next version of this toolkit it should be release  with enough information about these controls of  such vis
help.png

It would be nice if NI can provide Reset to default Values for settings in Vision assistant for many functions for e.g., Shape Detection etc. Currently either the developer should be getting default values from context help or delete the fuction and add it again.

Supporting only binary images as input type for the particle analysis is reducing the use cases where this functionality can be used. In many segemtation methods, e.g. superpixel segmentation or watershed segementation, the segmentation result is a labeled image. Being able to perform particle analysis on labeled images would enhance the modularity of this function. Since the particle analysis in internally performing probably a labeling anyway, and in many cases, the label of an object which is to be analysed is known too, it could also reduce the computational cost of this function.

The Image Display control (IMAQ Image.ctl) allows the user to change the color palette.

Like for the Intensity Chart and Graph objects in LabVIEW, it would be useful to add a color scale object to the control in order for the user to be able to visualize the color <-> value correspondance.

Like for the Intensity Chart and Graph objects in LabVIEW, the color scale should also allow the user to set the display range (min and max value) as well as the out of range color values.

Functions* that insert overlay's into images can define a Group, so later you can e.g. delete the whole overlay group at once. Currently there is no VI that would be able to get a list af all Group names preset/used in the image (if you e.g. load an image saved with overlay's and you want to know the Group names, so you can access theyr properties). It could look like this:

 

group.png

Then it would be also easy to get properties if all of the overlay group's (with IMAQ Get Overlay Properties VI)... This VI could also return a array of integers, that would give information about how many Bytes each overlay group uses in memory - for debuging puposes, or if you have some memory shortage problems...

 

 

 


*

IMAQ Overlay Arc
IMAQ Overlay Closed Contour
IMAQ Overlay Line
IMAQ Overlay Oval
IMAQ Overlay Points
IMAQ Overlay Rect
IMAQ Overlay Text

...

Greetings Vision Idea Exchange Community,

 

We have a critical need to apply a 4096 element U32 Lookup Table to our IMAQ images and were really hoping that it wouldn't be to hard to modify the existing shipped VI from the VDM package (IMAQ UserLookup 2 VI to be able to handle LUT's of greater bit depth.

 

This is of course a proprietary code from NI so we can't work directly from it.  Has anyone one the community been able to write an  (optimized) look up table VI/DLL which can take as input a 16 bit image and lookup to a 32-bit image depth?

 

Our application is correcting machine vision camera output frames  for bit error and non-linearity corrections for which we need at least 22 bits of LUT so we decided to simply go to four byte pixel depths.

 

Regards, Scott

 

High Altitude Observatory Boulder, CO

In Vision Development Module, it seems new functions are being created to replace older versions from time to time. ie: IMAQ Set Calibration Axis Info.vi --> IMAQ Set Calibration Axis Info 2.vi.  This is fine, however, the Vision Examples still use the older versions of these VIs, ie. they don't seem to have been updated also. 

 

For instance: Using Vision Development Module 2014 SP1, example Simple Calibration.vi.  In this example, the following VIs are being used: IMAQ Setup Match Pattern 2.vi, IMAQ Match Pattern 3.vi, IMAQ Set Calibration Axis Info.vi.  However when you look at the LabVIEW functions pallette, the following VIs are available: IMAQ Learn Pattern 4.vi, IMAQ Match Pattern 4.vi, IMAQ Set Calibration Axis Info 2.vi.

 

This tends to confuse things.  It would be great if the examples were also updated to use these new functions available

 

Also, the help files do not seem to differentiate between these older and newer functions.