Vision Idea Exchange

When merge overlay is performed on image with multiple overlay groups, it merges selected group (correct) and clears all others (wrong!).

It seems that it should affect only what has been said to it (selected group), and do not touch what belongs to somebody else.  If you need to kill all other overlays, use clear overlay after it. Or new version needs a switch to not kill other groups - for compatibility.

Imho this behaviour is more like a bug.

I don't know what the current official status of AIPD is, but the polymorphic "IMAQ Write File 2" VI which is in the LV palette does not offer AIPD in its selector. For me this means that there is no official support for AIPD anymore.

Unfortunately there is also no alternative for storing SGL or complex images.

My request: Add the AIPD format as an officially supported file format to "IMAQ Write File 2" or offer an appropriate alternative for all image types.

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).

The title says it all, but let me expand a little...

Since LabVIEW 8, trying to create a VI from a selection containing a reference to an Image Control fails. It does absolutely nothing, nada, nitchevo, nichts, rien...

There are at least TWO CARs about it: 54165 and 35835.

Yet, years after years, nothing is done about it.

A workaround for creating VI is to remove the connections to any of the image control references in the original selection, and once in the created subVI, drop a custom control that you will have strategically dropped in your Favorites Control Palette:

Then you need to add it to the connector pane, reconnect in the original calling VI...

Not the easiest but manageable.

Now, what about managing events using a Register Event node handling several controls, including a couple of Image controls? Usually, when not using images, I bundle references to the controls and do the Event Registration in a subVI (there are typically a lot of wires and large nodes involved, therefore this would take an undue amount of real estate in a main VI).

The problem is, any cluster containing a Image Control Reference can apparently not be created as a control in a "Create subVI" or even a "Create Control" operation:

FAIL!

FAIL!

Once again, it is possible to do all this manually, but if you have a bunch of Image Control references and other references to bundle, this is becoming rapidly tedious.

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