imaq requires lengthy wait effecting image capture rate

[Paul]

Hello,

I am in the process of evaluating a ieee1394 (firewire) CCD
camera to see if frames can be captured at precise time
points at a high rate. A small function was written using
manual software triggers to capture images. Of course we
will switch to hardware triggers when the camera moves to
the lab. The function produced multiple lines of the
following error:

"Warning: Cannot trigger OBJ while Logging is set to on."

followed by

GETDATA timed out before FRAMES were available.
??? GETDATA timed out before FRAMES were available.

Error in ==> simple_timings at 32
data = getdata(vid,number_of_frames,'native','numeric');"

If peekdata is used instead of getdata in the function, then
peek data errors occur.

I threw a couple pause commands into the function and that
seemed to cure the problem and at the same time reduce the
image capture rate to an unusable level.

The pause commands can be replaced with
"wait(video_object,1,'logging');" after the trigger. Is
wait it a more elegant solution than pause? Either way the
image capture rate is still to low.

Using the Profiler, I found that wait calls imaqdevice.wait,
which in tuun calls imaqgate. I think imaqgate may be where
the hold up is? Currently I am able to trigger between 10
and 14 frames per second on my windows xp box (currently it
is about 11.5 fps). The camera is capable of 30 frames a
second at full resolution of 512x512 at a 14 bit pixel
depth. 30 frames per second may be optimistic, but
somewhere in the 20 fps range seems reasonable.

My function is below. Any ideas, thoughts, pointers, or
banter would be appreciated.

Thank you,

Paul

function simple_timings(video_object,number_of_frames,
XOffset, ...
YOffset, Width, Height)
%
% a simple function for testing image capture frame rates.
% the inputs are the number of frames to capture and the
% region of interest (x offset, y offset, width, height)
% for example simple_timings(50,0,0,512,512)
%
%video_object = videoinput('qimaging',1,'MONO16_512x512');

% camera specific set up
set(video_object,'SelectedSourceName','input1')
triggerconfig(video_object, 'Manual');
set(video_object,'TriggerRepeat',number_of_frames);
set(video_object,'FramesPerTrigger',1)
set(video_object,'TriggerFrameDelay',0)
set(video_object,'ReturnedColorSpace','grayscale');
set(getselectedsource(video_object),'ClearingMode','PreFrame')
set(getselectedsource(video_object),'EMGain',0)
set(getselectedsource(video_object),'Exposure',double(0.01))
set(getselectedsource(video_object),'NormalizedGain','1.0')
set(getselectedsource(video_object),'Readout','5M')
set(getselectedsource(video_object),'ReadoutPort','Normal')

% set ROI and start video object
set(video_object,'ROIPosition',[XOffset, YOffset, Width,
Height]);
start(video_object);

% using pause or wait prevents the following error from occuring
% "Warning: Cannot trigger OBJ while Logging is set to on."
% I think wait may be the more robust and efficient solution
trigger(video_object);
wait(video_object,1,'logging');
%pause(0.5);
frameNumber = 0;

% again, using pause or wait prevents the following error
from occuring
% "Warning: Cannot trigger OBJ while Logging is set to on."

tic
while(frameNumber < number_of_frames)
frameNumber = frameNumber + 1;
trigger(video_object);
wait(video_object,1,'logging');
%pause(0.07);
end
elapsedTime = toc

% both get data and peekdata work, peekdata should be faster
%data =
getdata(video_object,number_of_frames,'uint16','numeric');
capturedFrames = peekdata(video_object,number_of_frames);

for frameNumber = 1:number_of_frames
filename = ['test_' int2str(frameNumber)];
c = fix(clock);

%tif
imagefilename = ['C:\Documents and
Settings\BrenLabUser1\My Documents\MATLAB\Testing\images\' ...
filename '_' int2str(c(1,1)) '0' int2str(c(1,2))
int2str(c(1,3)) '_' ...
int2str(c(1,4)) int2str(c(1,5)) int2str(c(1,6)) '.tif'];

% the commented out line works with the getdata line
commented out above
% the second line works with the peekdata line above
%imwrite(uint16(data(:,:,1,frameNumber)),
imagefilename,'Compression','none');
imwrite(uint16(capturedFrames(:,:,1,frameNumber)),
imagefilename,'Compression','none');
end

display(elapsedTime)
display(frameNumber)
timePerFrame = elapsedTime/frameNumber
effectiveFrameRate = 1/timePerFrame

stop(video_object);
wait(video_object);
delete(video_object);
clear video_object;
close(gcf)

[Paul]

The overhead involved with reading a 14 bit 512x512 pixel image into memory
should be relatively small. Why does a pause, wait or other time consuming
function have to be used? It seems that the Matlab image acquisition toolkit
should be able to handle reading images at a high rate without the user having
to add in some sort of manual time consuming synchronization inducing step?

Paul

[Paul]

Changing some of the camera settings has yielded a big boost
in frame rate. As well, a small increase in frame rates can
be had by replacing the while loop with a for loop and using
either the wait function or a nested while loop that waits
for a frame to be acquired before continuing.

for example:
elapsedTime = 0;
frameNumber = 0;
for i=1:number_of_frames
tic
trigger(video_object);
% use the while loop or the wait function
% while(get(video_object,'FramesAcquired') ...
% == frameNumber)
% end
wait(video_object,1,'logging');
elapsedTime = elapsedTime + toc;

frameNumber = frameNumber + 1;

end

Frame rates are up to 25 frames per minute (512x512, 14
bits, 15 milliseconds exposure time).

The Qimaging software achieves 29 frames per seconds at the
same settings. Using a 4x4 pixel binning mode (128x128)
pixels at full frame QImaging achieves 66 frames per second
and my Matlab function achieves 50 frames per seconds.

An odd facet of the Matlab function is reducing the region
of interest has zero effect on frame rates. In the QImaging
software reducing the region of interest has a big effect on
frame rates. Intuitively, achieving higher frame rates by
using a subset of pixels (region of interest) makes sense.

Paul

[Paul]

Further exploring the region of interest, I have noticed
that as the region of interest is reduced (for example,
capturing a 64x64 pixel region on a 512x512 pixel CCD with a
binning mode of 1 [no binning]) the frame rate stays exactly
the same as the full frame, frame rate. Imaqmem shows the
amount of frame memory used does decrease as the size of the
region of interest decreases. Does Matlab grab the full
frame image and then throw away the part of the image that
lies outside of the region of interest? What are the steps
between the image being on the ieee1394 bus and its final
form in the frame memory buffer

Paul

[Paul]

The full frame frame rate issue has been solved or at least
a work around has been found. When looking through the
Matlab meta acquisition times it became apparent that excess
time was being consumed during the first frame acquired.
Placing a pause of 1-2 seconds after "start(vid)" alleviates
this problem. Full frames are now being captured at the
frame rate specified by the manufacturer. Changing the
region of interest still has zero effect on frame rate.

Paul