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!
