LabVIEW Idea Exchange

Background:

LabVIEW has had a recent proliferation of datatypes that essentially store the same type of data: an ordered sequence of numbers.  We now have Array, Matrix, Waveform (+ Digital Data/Waveforms), Signal (!) and Image datatypes (and perhaps one could also include Scalar).

The Benefits:

Each datatype is optimised for its own particular application, making it simple to perform a particular set of operations on the data.  However each appears to be developed independently.

The Limitations:

Each datatype has different restrictions on representation, dimension (typically only 1D or 2D), and "metadata", and most built-in functions will work on only a small subset of types.  Accessing the data as a different type usually requires copying the underlying data, with consequent limitations on speed and especially memory.  I notice these limits especially in three situations:

1) I want to use a function written for one datatype on another datatype (for example, use the Wavelet Denoising function (or even simply Square Root) on an Image),

2) I want a way to work easily with 3D images (most of the existing 2D image processing functions would have simple extensions to 3D),

3) I want to write routines that will adapt to both 2D and 3D arrays (say deconvolution).

It is certainly possible currently to work around all of these things, but it seems there should be a more cohesive approach.

New LabVIEW developments:

3 new developments in recent versions of LabVIEW show potential for addressing this issue: Classes, In Place Element Structure, and Data Value References (DVR).  However because they are all ideas "in development", and added on top of the existing LabVIEW rather than under the core, they only hint at possibilities rather than provide them.

A Possible Solution:

A low-level generic Array datatype from which all these other types are "inherited", therefore providing a single common way of addressing array-type data.  It seems like this datatype could resemble either a Class or a DVR.  It would have various attributes associated with it:

- Dimension and Size - essentially specifies the way in which indices address the array (probably always stored as a 1D array underneath)

- Metadata - e.g. t0 and dt of Waveforms, name etc of Signals, border size etc of Images, ...

The In Place Element Structure would be one way of choosing how to access the information in this variable, although it may be possible for the array information to be directly available.  Hopefully something like this would also enable the ability to "overload" existing routines, for example adding a 3D convolution to the 2D and 1D routines that already exist.

Some of my earlier thoughts are here, here and here.

PS - hope no-one said Ideas here had to be practical or reasonable!

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