Writing to separate files is very slow. The operating system has to open and close many different files. Reading is also slow, because a lot of time is lost locating, opening and closing the files.
If it is all going to be in LabVIEW, I would consider using flatten to string, if it supports 64 bit color. You can configure it to compress or not (although if you compress you lose the benefit of 64 bit color, may as well just use 32 bit). For each image, flatten it to a string. Write the strings consecutively to a single binary file. It will write much faster if you keep the file open and append the strings as you generate them. Reading them and restoring the image is pretty quick also. If it is a small movie, you can load the entire file into memory as an array of strings. Larger movies will require streaming from the disk.
Is there a major reason to stick with 64 bit RGB? Computers can't display it, so they automatically reduce it to 32 bit RGB. If your movie is just for display, go ahead and reduce it to 32 bit RGB. Does your analysis really need those extra bits? Just because your camera is capable of measuring greater than 8 bits per color plane doesn't mean it is necessary to use it. I haven't seen too many applications that require high bit counts, which is why I ask.
Bruce
Message Edited by Bruce Ammons on 11-24-2008 11:59 AM
Bruce Ammons
Ammons Engineering
