Fastest image capture method for tiny image?

[mvonstein]

I want to capture and add to a memory buffer a series of  90 x 144 images.  It needs to be hardware triggered and I need it to go absolutely as fast as possible. 

My question is:

- What camera interface is best?   (LVDT, firewire, camera link, gigE, etc)

- What image capture hardware is best?  (NI CVS, Compact RIO, PXI, PCI card, etc?) 

I would like everything to be hardware,  rather than software based if possible to provide more consistent timing.

Thanks in advance,

Mike 

[BruceAmmons]

The first thing to do is pick a camera.  Most cameras can capture at a faster rate when you are only looking at a small region.  Most likely, you will reach a point where the shutter speed is the critical parameter.  How fast do you want?  Can you come up with a number for fps?  Would 1000 fps be good enough?  You can probably reach almost any frame rate desired, but the price keeps going up and up and up...

For example, there is a Basler camera that can acquire 640x480 at 210 fps.  If you reduce the area of interest to 90x144, you can probably get about 1000 fps.  The increase in speed depends on the camera design.  Rotating the camera 90 degrees and using 144x90 might be faster as well.

After you pick a camera that can handle it, just pick the matching interface.  I am guessing it will most likely be a GigE camera, since they are very fast and relatively easy to configure and connect.  My second choice would be firewire b, which is also pretty fast.  A PCIe card will probably be the fastest interface.

I would call Graftek at 800 441 2118 and discuss it with them.  They are great at helping you pick out the best camera for your application.

Bruce

[Robert_Eastlund]

The fastest would be a Camera Link camera.  Of these, the fastest camera that I sell for use with the NI PCIe-1429 Camera Link frame grabber is the Baumer HXC13, see http://www.baumer.com/212+M52087573ab0.html.  For inormation about the PCIe-1429, see https://www.ni.com/en-us/support/model.pcie-1429.html.  However, this solution, pricing in at about 13K (camera + framegrabber), may be outside of your budget.  Please let us know the price range that you would like to stay within.

-Robert Eastlund

[Steverino]

Another choice is Point Grey's GrassHopper camera. It has 640x480 resolution at 200fps and might run faster as the image size is reduced. FireWire-b interface. Should work with IMAQdx. Costs about $1200 USD. Only issue might be the amount of available light as the sensor is 1/3" format and at 200fps the shutter speed is less than 5ms.

www.ptgrey.com

[mvonstein]

Thanks for the ideas.  Wondering what a realistic cycle time would be to trigger, acquire, & save to memory.  Assuming, I would be have enough light could a loop be done in less than 3 msecs?

Thanks,

Mike 

[Tejinder_G.]

Hi Mike,

You should be able to make some quick calculations to get an idea.  If each pixel represents 8 bits, then you know the size of each frame.  So a 90 x 144 frame represents about 13 KB of data.  You can then compare that to your framegrabbers bandwidth and your camera's frame rate to see which will be your bottleneck.   

[mvonstein]

Thanks, Tejinder.  I will do that.  Is there any typical, worst-case time values I can use for the amount for the time period between when the trigger is first generated and the image transfer starts?

Thanks again,

Mike

[BlueCheese]

At very fast frame rates with small image sizes your latency between image exposure and processing is likely much higher than the time between frames. In other words, your throughput could be 10,000 frames/sec (10 per millisec) but your latency from the time the image is exposed might be 10 millisec. This is because there is latency of the image transfer off the sensor, latency transferring the image over the PC's bus, latency between the hardware signalling a frame done interrupt and the driver processing it, and the time needed to actually process the image. If you add all this up it could be several frames long.

Thus, it is important if you are talking about "cycle time" that you either can pipeline things and be processing one image while new ones are being captured or else you need to figure out your worst-case latency if you really need to process every image before even capturing the next (which if many people's definition of a "cycle"). I believe we have seen latencies of around 1-4ms measurements on a real-time system, depending on camera sensor, camera bus, etc.

Hope this helps, 

Eric 

[mvonstein]

That helps a lot, Eric.  Thanks!