Import Movie-type Raw Data File

[DonRoth]

Hi Folks - this one should be an easy one but having problems.  Been given a single file that is a series of 10 frames with 256 rows x 320 cols for each frame.  Data representation is I16 or U16 (I have tried both [also tried I8/U8 just in case]). I am using the following simple piece of code to try to open but getting error 71 (File datalog conflict).  Any thoughts - need a second set of tired eyes to look at this.  The raw data file I have named .doc just because the forum post would not accept .raw extension which is what you can rename the raw data file to.

 

Message Edited by DonRoth on 09-04-2008 03:27 PM

Message Edited by DonRoth on 09-04-2008 03:28 PM

Message Edited by DonRoth on 09-04-2008 03:29 PM

Message Edited by DonRoth on 09-04-2008 03:30 PM

[DonRoth]

ps. for the VI, the representation needs to be changed to I16 or U16 for the record type (it is currently at U8)....thanks, Don

[DonRoth]

Realizing I might have misinterpreted the way the data was stored (all at once as a data cube per my prior post), or possibly frame-by-frame, I tried again with the latter approach but still no luck.  Will now consider looking at the bytes.

 

Message Edited by DonRoth on 09-05-2008 10:05 AM

[johnsold]

Don,

Is there a particular reason why you are using the Read Datalog function rather than reading the file as binary?  According to the help the datalog functions expect the data to be in records which are interpreted as clusters of whatever datatype was written.  I looked at your data file with binary read.  It appears that  there may be some kind of header because the first 20-30 bytes are quite different from the next several hundred.

Lynn 

[DonRoth]

My impression when I got the file was that all of the frames were first stored in an array prior to just writing to a file.  (The acquisition was done with a non-LabVIEW controlled instrument).  Then I thought maybe each frame acquired was then stored, followed by next frame acquisition and storage, etc.  Now, my next approach is the byte (binary file) reading using options of I16, U16, big-endian, little-endian as options.  For example, here is the code to do one variation and this seems to be getting me closer (I am not in touch with data acquirer to see what the actual frames should look like).  With this code, I am definitely opening the data frames and displaying them. 

Message Edited by DonRoth on 09-05-2008 11:08 AM

Message Edited by DonRoth on 09-05-2008 11:09 AM

[Captain_Kirby]

Hi Don,

You have quite a difficult task in front of you. When reading a binary file, the key is understanding the format it was stored in, not necessarily what the content is. You might come upon the correct answer through much trial and error, but keep in mind, there is little that can be done from a troubleshooting standpoint besides the random or systematic elimination of all the different possible methods of storage. I will mention one thing that might help (or hurt.) I know this file was not originally created with LabVIEW, but if it was created in LabVIEW, and an N dimensional array were written to a binary file (which would be the correct method in this case,) you would have the choice to prepend a header onto the data which contained information about the size and dimensions of the array. You could then use this when you read the file to reconstruct the array. Since you too see slightly different bytes at the beginning of your file as well, maybe the same method was used. Just an observation that might help as you try to piece together this jigsaw puzzle.

[DonRoth]

Well I cracked it pretty quickly by getting a image of the first data frame from the researcher. It turns out the data is I16 and little endian, with no header bytes.  By getting ahold of the first data frame as it was displayed in another program and performing trial and error as detailed in prior posts, it turned out to be relatively painless.  I have had much more difficult interpreters that I have had to write than this without knowing all of the information.  Thankfully, many people on this forum have helped over the years when I came to a dead end.

Sincerely,

Don