specifying byte stream type for Read File with Type Descriptor

[Tim Williams]

Hi.

I'm trying to write a VI that reads an image file format that can have
different datatypes. What I have so far is that I open the file, read
the header, and get the width, height, number of frames, and datatype.
I calculate number of pixels by nrows*ncols*nframes with no problem,
but I'm not sure how to tell Read File the correct datatype to read
the data into.

I tried using a Case structure where I have a Read File in each case
with the correct type constant as input for that case. The problem is
that the tunnel graduates the datatype to the highest representation.
I found in Application Note 154 the discussion about Type Descriptors.

Is there a way to generate a Type Descriptor and output it from a C
ase
structure? I tried just returning the value (e.g. 0x0402 for a Word),
but Read File will just see that the byte stream type is a uint32.

Is there any other way to do this?

Thanks for any help.

[DFGray]

Your problem is that LabVIEW is strictly typed. You need a way to pass data around that is not strictly typed. A custom functional global is probably your best bet. See the tutorial Managing Large Data Sets in LabVIEW. Select or scroll down to the topic Shift Register Databases for Large Data Storage. Download the code and look at it, then create a custom one with "data" of each type you need. You can also include all your header info in it, so you essentially get a singleton data object of your image in memory. Just zero out the arrays you are not currently using. When you access it, you will need to access the currently valid data, so you may w
ant to write a couple of wrapper functions to make your job easier. Good luck. Let me know if you are still having trouble.

[Tim Williams]

DFGray wrote in message news:<506500000005000000DBD90100-1079395200000@exchange.ni.com>...
> Your problem is that LabVIEW is strictly typed. You need a way to
> pass data around that is not strictly typed. A custom functional
> global is probably your best bet. See the tutorial
> href=http://zone.ni.com/devzone/conceptd.nsf/webmain/6A56C174EABA7BBD86256E58005D9712?opendocument...
. Select or scroll down to the topic
> Shift Register Databases for Large Data Storage. Download the
> code and look at it, then create a custom one with "data" of each type
> you need. You can also include all your header info in it, so you
> essentially get a singleton data object of your image in memory. J
ust
> zero out the arrays you are not currently using. When you access it,
> you will need to access the currently valid data, so you may want to
> write a couple of wrapper functions to make your job easier. Good
> luck. Let me know if you are still having trouble.

Thanks for the reply. I'll look into this. In the meantime, I'll just
limit my function to handle only up to unsigned shorts. I'll revisit
this when I need to start reading/writing floating point image data.

[Tim Williams]

DFGray wrote in message news:<506500000005000000DBD90100-1079395200000@exchange.ni.com>...
> Your problem is that LabVIEW is strictly typed. You need a way to
> pass data around that is not strictly typed. A custom functional
> global is probably your best bet. See the tutorial
> href=http://zone.ni.com/devzone/conceptd.nsf/webmain/6A56C174EABA7BBD86256E58005D9712?opendocument...
. Select or scroll down to the topic
> Shift Register Databases for Large Data Storage. Download the
> code and look at it, then create a custom one with "data" of each type
> you need. You can also include all your header info in it, so you
> essentially get a singleton data object of your image in memory.
Just
> zero out the arrays you are not currently using. When you access it,
> you will need to access the currently valid data, so you may want to
> write a couple of wrapper functions to make your job easier. Good
> luck. Let me know if you are still having trouble.

Let me say first that I'm a newbie at this.

I tried running the code, but I have LabView v6.1, so I got errors
during loading.

I changed my Case structure to flatten the data after I read it, then
pass out of the structure the type string and data string output from
the Flatten To String function. The problem I get is that the datatype
of the wire output from Flatten is a 1-D array of type Word. That
seems to make sense, since the type descriptor is supposedly a list of
words (Application Note 154), but why can't I use this to do an
Unflatten From String using the wire output from Flatten to the input
to Unflatten? Is the problem that the wire coming *out* from Unflatten
is strictly typed, so I just can't do this? I
f this is so, then how
do the routines that take 'any' type work?

[DFGray]

I converted the code to LabVIEW 6.1 for you and attached it below.

Don't worry about being a newbie. We all start there. Keep asking this type of question and you won't stay there long.

As you are discovering, being strictly typed means that you must rewrite code even for a simple data type change, or convert everything to the same data type first. For image data, conversion can result in a lot of extra space being wasted. Use a modified version of the GLV_WaveformBuffer.vi to hold your data. Use the array functions, which operate inline, to add to and delete the data wires in the buffer. This allows you to save several different data types. You will need several different inputs and outputs to handle these data types. I ha
ve also attached a similar file created for exactly the problem you have - storing arrays of different data types (data from NI-SCOPE devices, in this case - can be float, I8, I16, or I32).

Routines that take any type work in one of two ways. LabVIEW primitives, such as plus and minus operators, work by figuring out the type and doing the right thing in the C code layer of the LabVIEW environment. Users of LabVIEW can't do this. Users can make polymorphic VIs. Polymorphic VIs are actually a single VI for every data type that are referenced by a "wrapper", the polymorphic VI. Users still need to write a different VI for every data type they need.

Take home message - if you need to work with different data types, you will need to rewrite your code for every data type or convert your data to a common data type. Polymorphic VIs and case statements are your friend.

Let me know if you need more help.