Image acquisition-skipping frames

Hello, I am working on a program that starts capturing frames whenever it receives a signal from a remote computer and stores it as a TIFF stack. It stops recording whenever it receives the appropriate signal from the remote computer.

For shorter durations (~15s-30s), all the frames are stored. However, for longer durations (~5 min), it is losing frames. I have tried increasing the frame memory but it does not seem to be helping. I have reliably determined that it is receiving the correct signal, and that the stop function (stop(vi)) is being called.

The images are of size 512*512.

Thank you

Mathew

[Geoff]

Hi Matthew, I'll be quite interested to hear how you get on with this issue. It is possible to stream a multi-page TIFF to disk without doing any seeks, if you have access to the code that does the encoding. Basically, you keep the most recent frame in a buffer and only write it when another frame arrives or the file is closed off. That way you can predict all the file offsets etc that need to be written, without having to double back. I would recommend this only if you REALLY want to write TIFFs on the fly as opposed to compiling them afterwards. Who knows - someone may have already written a support routine for this... =)

Answer 1

[Walter Roberson]

If you are storing the images to disk as you go, you are going to end up with frames dropped (unless perhaps you are using a solid state disk.) Disks are much slower than main memory.

[Mathew Cherian Carathedathu]

Please see my comment to Geoff's answer below.

Answer 2

[Geoff]

Those images are 512 * 512 * 1 ? That's 256kB. These are small. What is your frame rate? I'll assume 50 fps. That's 12.5 MB per second. Peanuts for a single hard drive to cope with. A drive would still manage that at around 300 fps.

You say TIFF stack. I'm not up with the terminology here.. Is that a single file containing all frames? How often do you write this file? Once at the end, I'd hope? If not, then do that and see if you still have a problem.

Otherwise, I would be storing one image per file and see how you go with that. If there's a bottleneck encoding the file, then write out the binary data raw and process it later.

If you're pushing disk limits you need to be extremely efficient in how you write data. If you're not pushing limits, and still having trouble, then you're probably being very inefficient somewhere.

[Mathew Cherian Carathedathu]

the frame rate is 30fps. And it is 512*512*2. TIFF stack is where all the images are in one .tiff file. I will be reading it as imread('temp.tif',index).

I do not think that I am pushing disk limits in any way. I was trying to write images on the fly. However, the images that are being lost are the ones in the end. Which is why I have no clue where my problem is.

[Walter Roberson]

None the less it would be better to write in raw binary and create the TIFF later.

[Geoff]

It's a bummer I'm not so familiar with TIFFs or I might have an immediate answer for you. What I suspect is that there is some amount of book-keeping involved in adding a frame to the file, which may or may not involve reindexing all the frames, relocating frames, or performing excessive disk seeks. Or is it possible that the code you have to write these files is doing even more than that? I've encountered problems like this in low-level APIs for creating AVI files, and ended up writing my own for a performance gain of about 200%.

The simplest and most quickly-implemented solution for you will be to either:

(a) Buffer all your frames to memory and write to a TIFF afterwards; or

(b) Write each frame to individual files (a raw binary dump is fine - and fast, too) and compile the frames into a TIFF afterwards; or

(c) Similar to (b), but obviously you can just use a single file - stream the binary data to file, and compile to TIFF after.

I would be interested to see a benchmark of your TIFF writer. Just create an empty frame (I assume you're writing these files with no compression), and sit in a big loop adding frames to the file as fast as you can. Time each operation (using 'tic' and 'toc') and plot the results afterwards. Do a big test - like don't stop until you've written a gigabyte or two. If the curve increases linearly or exponentially, then the code is doing something beyond simply appending a frame.

In fact, you haven't said whether you open and close the file or just maintain a single stream. If you're opening and closing, it has to search through the file (every single frame)... Seek to frame 0, read frame 1 offset, seek to frame 1, read frame 2 offset, seek to frame 2.... etc.. That would kill your performance as your frame count gets higher. Successive seeks and reads are slow.

[Geoff]

Regarding the last paragraph in my comment above.... Refer to Figure 1 on Page 14: http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf