Vision Idea Exchange

Lately I've been working on projects that use high-resolution cameras (10+MP). Typically I use the Vision Assistant to quickly prototype a vision inspection, then rewrite the inspection in LabVIEW.

When working with large images, I often need to pan around to different parts of the image. However, the only way to pan the image in the Vision Assistant is by using the scrollbars, which often feels clunky. I would love to be able to navigate around the image more easily and fluidly.

A few possible ideas:

• Add the Pan tool to the toolbar, like the Image Display indicators have in LabVIEW, so that the image can be navigated by clicking + dragging
• Click the middle mouse-wheel to toggle panning with the mouse position, like in Chrome/Firefox/Excel
• Click + hold the middle mouse button to drag and pan the image, like Paint.NET
• Change the behavior of the mouse scroll-wheel to align with familiar software, like Chrome/Firefox and Paint.NET, instead of just having the school wheel be zoom, that is:
  
  • Scrolling up/down would pan the image up/down
  • Shift+scroll wheel would pan the image left/right
  • Ctrl+scroll wheel would zoom in/out

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.

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:

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.

When Vision Assistant steps are converted to LabVIEW VI, the overlay of result (i.e. edge detect, particle counts) is lost.

Adding overlay function on VI requires not only LabVIEW skills, but Vision knowledge due to image memory handling.

So it'd be nice to have an option to keep the overlay functionality on Vision Assistant even when converting to LabVIEW VI to have a smooth transition.

Ryuji Kuwajima

Similar to Draw Line/Draw Multiple Lines function available for Picture, it would be good to have line styles(as mentioned in the attached image) for IMAQ Overlay Line, IMAQ Overlay Multiple Lines 2.

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. 

This is probably not a simple thing for NI to implement but I always thought it would make sense to make the IMAQ image a native data type. When I first started using LabVIEW, it took me a while to get used to the image data type and understand that it is just a pointer to a named image in memory and the pointer is passed between image operators. I am used to it now but it still seems clunky to me. Why can't an image constant or control implicitly create an image and they can be implicitly destroyed at the end of a program. Branching a wire would create two copies of an image that could be operated on independently. At the moment my imaging code always looks quite messy because I often need to create temporary image buffers for intermediate operations.

I think this would make the imaging tools a more wholistic addition to labVIEW and make it feel less like something that was adapted from another language. Sure there would be some impact on performance, but isn't that why we use LabVIEW? Simpler programming at a higher level.