Clear Filters
Clear Filters

Image acquisition-skipping frames

5 views (last 30 days)
Mathew Cherian Carathedathu
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
  1 Comment
Geoff on 29 May 2012
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... =)

Sign in to comment.

Answers (2)

Walter Roberson
Walter Roberson on 28 May 2012
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.

Geoff on 29 May 2012
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.
Geoff on 29 May 2012
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 on 29 May 2012
Regarding the last paragraph in my comment above.... Refer to Figure 1 on Page 14:

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!