LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

As I see it, working with the IMAQ Image Typedef always results in problems for me, so I've gotten to where I try to avoid using it. Working with IMAQ should be so much better than what it is.

Here are some Ideas:

1. Allow IMAQ stream to disk RAW Format with a string input for a header for each Image. You could call this vi once to write a Header to the Image, then for every call after that everything you input into the string would be written between Images. This vi should allow you to append the images. Most of the time I DON'T want to write out to a specified Image format. I want to stream raw Video to disk.

Also, we are entering an era where lots of Image data is being dumped to disk, so the Raw stream to disk function would need to take advantage of multithreading and DMA transfer to be as fast and as effecient as possible. The Vi should allow you to split up files into 2GB sizes if so desired.

See the block diagram to see how this would change the Labview code required to grab Images and save them to disk.

Also, It would be nice to be able to specify what sort of Image that you want to use in the framegrabbing operation. This could be set in the camera's .icd file, or by the IMAQ create.vi

Notice in the above example, I make IMAQ create.vi create U16 Images, but when the Image is output, I have no choice but to take the image in an I16 form. I would like to have the image in its native U16 form. I am converting the image to U16 from I16 by the "to unsigned word Integer" I don't think that this should work, but it does, and the fact that it does helps me out.

In general it would be nice to have better support for Images of all Flavors. U16, U32 and I32 grayscale, and Double grayscale.

While you are at it, you might as well add in a boolean input (I32 bit result Image? (T/F)) to most Image math processing functions, so the coercion is not forced to happen.

Really though....... LETS GET TO THE POINT OF THIS DISCUSSION.....

The only reason that I have a problem with all this is because of speed issues. I feel that arbitrarly converting from one data type to another wastes time and processing power. When most of my work is images this is a serious problem. Also, after checking out the Image Math functions they are WAYY slower than they need to be compared with thier array counterparts.

Solution: spend more time developing the IMAQ package to be speedier and more efficient. For example, the IMAQ Array to Image is quite a beast and will essentially eliminate a quick processing time. Why is this? This doesn't need to be. NI should deal with Images internally with pointers, and simply point to the array Data in memory. I dont see how or why that converting an array to an image needs to take so much time.

Discussions on this subject:

http://forums.ni.com/ni/board/message?board.id=200&thread.id=23785&view=by_date_ascending&page=1

And

http://forums.ni.com/ni/board/message?board.id=170&thread.id=376733

And

http://forums.ni.com/ni/board/message?board.id=200&message.id=22423&query.id=1029985#M22423

64-bit versions of LabVIEW

Hello:

I am going to be testing the 64-bit version of LabVIEW soon. But the major code that I want to port to it also uses Vision and Advanced Signal Processing Toolkit. Therefore, I am VERY, VERY interested in 64-bit versions of those toolkits. I work at times with 100s of high resolution images and to effectively have no memory addressing limitation that 64-bit offers will be a significant advance for me. Right now, I post-process with the 64-bit version of ImageJ to do some of the work that I need with huge image sets.

View All (1)

It would be nice if it was possible to add another 'Reentrant' setting.

This setting would make sure VI A always uses a specific instance, where VI B uses another instance. Sort of a single parent sub-vi.

This would allow for look-up VIs that have a seperate set of data per VI that is calling them.

So you can store some variables that are only valid in a single VI and if another VI is calling the same VI it will be calling a second instance and gets other variables back.

Ton

View All (2)

I'd love to see a handful of built-in false-color colortable choices for the Intensity Plots.

I know there's programmatic control over these things - I wrote my own 4-5 years ago. But the black-blue-white should be one of several common selectable colorschemes.

I labeled my own as:

Greyscale B->W

Greyscale W->B

X-Ray

Yellow Hot

Rainbow

Rainbow #2

Fluorescent (green)

Blue Red Green

Planet Earth

Perhaps one of the front panel (and Property node please) off of the Z-Axis submenu, listed by title.

I also have the ability to invert top/bottom or choose the color-inverse (photographic negative) for even more colors.

Attached is a sample of some common colortables I routinely use.

2nd attachment is a snap of the VI I use to create the colors based on colortable constants.

3rd attachment is my messy but functional code (Block Diag of attachment 2)

Smart Iterators with Loops

LabVIEW loops are quite flexible and allow me to do just about anything I want, but I often find myself writing the same code over and over again trying to iterate across different data types and data structures. There are several situations where smarter looping constructs could greatly simplify my code. One simple example is stepping by a delta between a minimum and maximum value. Currently, I have to calculate the number of iterations required ahead of time (for a for loop) or do a comparison with the maximum (with a while loop) and use shift registers to maintain the intermediate value. I'd like to be able to wire the max, min, and delta to my loop and have LabVIEW do the required calculations for me. The iteration terminal could also adapt to the proper data type given the input parameters. Perhaps the iteration terminal would have two outputs, one with the current iteration count and the other with the proper iteration value.

Another useful feature would be allowing me to wire a queue reference to the loop count terminal of the for loop and having it automatically pop each value from the queue and feed it to me through the iteration terminal. It would do this until there are no values left in the queue or until the code stops the loop. One could write an algorithm that pushes new points into the queue from within the loop or push the current value back onto the queue for later processing.

I'm sure there are other useful iteration strategies that are fairly common, please share them with the community.

View All (2)

Coersion Dots

View All (1)

Cluster to Case Selection

Currently, we have to use Unbundle By Name from Cluster and select an element for Case Section

It would be great if we could just wire the Cluster Directly and have a Right-Click Option at Case selector to select an element (one element only).

P.S. If it is a reasonable suggestion and gets enough Kudos to get R & D team’s attention for feasibility of this idea, then we ask for more logical operators support that would be useful. Also multiple elements and/or more statement node i.e. (type == Array and # elements <= 2)!!!

Only sometime I miss “if statement” support in LabVIEW.

Message Edited by Support on 07-16-2009 11:56 AM

These function names create undue confusion. Every semester, new students to LabVIEW post questions on the NI and LAVA forums asking how to use these functions to open, edit or load data from an Excel file (.xls).

Unfortunately, the name spreadsheet file has become synonymous with Excel. Even experienced computer users have an expectation of some sort of intelligent file when reading the title "Read from Spreadsheet File".

These functions should really be renamed to 'Read from' and 'Write to' DSV file...

Delimiter Separator Values (wikipedia link)

While creating a labVIEW vi directly from vision assistant, the buffer needs to be manually allocated.

I have faced this minor hitch of changing the palette to actually view the image when i am starting with a color image and ending with a binary image. Automatically allocating optimized buffer for image destination will save some time as well as avoid "Incompatible image type error". The problem will get multiplied when you have created a subvi and have used a "imaq extract function" before this. The buffer will automatically get overwritten. Hmmm I know this is a luxury but still.......................

Hough Transform

View All (1)

Extension of the search 1D array function

View All (2)

While the Image datatype is very useful for working with images, there are many functions that are not available (e.g. Square Root, or the Wavelet Transforms). In order to achieve this, it is necessary to convert the Image to an Array, thereby duplicating the memory required, and then convert back again. (IMAQ GetImagePixelPtr/IMAQ MemPeek also duplicates data). I would like to be able to directly access the Image data as a LabVIEW Array. Perhaps the In Memory structure could be used to achieve this, e.g.

One potential problem is the extra information (border pixels) which are part of Images - for most use cases it would probably be ok to retain these (i.e. the array is larger than the image, though perhaps there could be an option as to whether they are mirrored or zero etc. RGB images would provide an array of U32/64, but even better might be a cluster of arrays for each colour plane.

Bonus points for the ability to access an Array of Images as a 3D Array!

View All (5)

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.

View All (9)

Unzip to memory

This idea will probably have a narrow audience... those of us who use the "zip" functions in LabVIEW. There is currently an unzip function that takes a zip file on disk, then writes the unzipped files back to disk. To manipulate zipped files, you must then access the disk and load into memory. In other words, 3 disk operations... read zip, write file, read file.

There needs to be a function that unzips the files into memory, with the output of this function as an array of flattened strings, byte arrays, or data pointers.