1000 fps Live Image Processing

[carlson]

End Objective:
To stream images at 1000 fps from Mikrotron MC1310 to PCIe-1429 capture card and find the centroid of a Poisson spot.

Problem(s):
    The NI-downloadable camera file for the Mikrotron does not work.  The acquisition within MAX times out.
If you go into the camera file, I think it has to do with capturing with 10 taps.  The "AcquisitionBitstream (EP1S20_CL_TC10T8_1x10.dat)" within the camera file may be the culprit (can anyone explain these .dat  files?)  If anyone has delved into 10-tap acquisition cameras and knows anything about this, I would appreciate your help.  Also, the capture fails if I turn "NeedYChip" and/or "NeedZChip" to "Yes."

    How can I tell the frame rate I am getting?  
I can modify a Photron Focus camera file to get the Mikrotron at least capturing with two taps.  However, I need the 10-tap capturing ability for full acquisition.   I can finagle it to get 10 taps but then I get vertical streams of pixels 3-wide that alternate in intensity from black to white every 10 "normal" pixels. 

There seems to be a frame rate counter in the bottom-right of MAX, but I should certainly be getting > 48 fps, even with binning!  Again. this may stem from the camera file.

Say I am streaming images using LabView, using HL Grab.vi.  If I display the loop time, is that the time per frame?  Or is this the time for the program to grab a frame from the buffer?  I need to acquire and process ALL the frames, at 1000 fps (or perhaps more realistically, 5 ms/frame.)

Thank you,
Lane

[Angela M]

Hello Lane,
You have posted many questions and I will try to help.  First, I will say that acquiring and processing at 1000 fps can be difficult.  Since a Grab is a single buffer operation, it would probably be better to use a multi-buffer acquisition so that you can access acquired images before the memory is overwritten.  I would recommend in LabVIEW looking at one of the Ring acquisition examples, LL Ring.vi for one.  The time that you measure in LabVIEW for the display is not your acquisition rate, it is the time for the image to be extracted into memory in LabVIEW.

To reach the frame rate you are looking for, it will be best to move the processing into a separate thread from the acquisition.  You can accomplish this using the queue functions in LabVIEW.

You are correct in your statement about framerate appearing in MAX.  This frame rate will depend on your camera, as well as acquisition window size.  It does appear that the camera and camera file were tested with a 10 tap configuration, if you continue to see problems with this, we should try to isolate the cause.  When you say that it does not work, it sometimes helps to see a screenshot of the error, and change as few things as possible.  If you plan to modify the camera file, it is a good idea to use the camera file generator for modifications as it takes care of formatting and compatibility concerns.

I hope that this helps, please let me know if you continue to have questions about this.
Regards,
Angela
Applications Engineer

[BruceAmmons]

Lane,

I can't help you with the hardware issues.  I do agree your best option is to use multple buffers, preferable enough to give you a good cushion.  It may not be possible to do the analysis as fast as the acquisition.

I do have a suggestion for the analysis.  I would use two line profiles, horizontal and vertical, through the centroid location from the previous frame.  From each profile, you should be able to quickly locate the peak value, which is the new location for the opposite axis.  If the spot is moving so fast that a single pass is not adequate, this will iteratively converge on the center of the spot.  I would think the two line profiles would be very fast, and might approach the speed you need.  You may need a more complex algorithm to first locate the spot in the first image, but that will depend on your application.

Bruce