IMAQ --- 4 cameras high resolution and high frame rate acq

[owh]

I would like to create an acquisition system to monitor the motion of the
human body with LEDS.

Here follow the main caracteristics of the future system :

- 4 cameras
- min resolution : 500x500
- frame rate : 400 frames per second (or lower but highest possible)
- monochrome
- 2, 4 or 8 bits per pixel
- I will probably use the National Instrument PXI-1409 board or the PXI-1424 board.

My questions are the following :

1. If the camera has an embedded pixel clock (eg 25 MHz) and provide
a frame rate of F frames per second, is it possible to use the pixel
clock on the NI board (50 MHz) in order to get a double frame rate (2*F) ?
2. If I connect 4 cameras, is the frame rate di
vided by 4 ?
3. Does anyone have any suggestion for the system ? (camera/board(s) types).

Thanks a lot.

[BruceAmmons]

This project is not going to be easy, and you aren't going to be able to use standard equipment to do it.

For the frame rate and resolution you want, each camera is going to be sending back data at 100 MB/s, assuming you use 8 bit B&W cameras. The fastest any NI board can go is 40 MHz (to the best of my knowledge). If you find a camera with these capabilities that can send 4 channels of data, the NI1424 board might be able to do it for short durations.

Another detail: You can only use one camera per board, especially in a situation like this. If you put four boards in one PC, they will overload the PCI bus with data.

Why do you need to have 400 frames per second? That seems awfully fast for what you are doing. How long do you plan on monitoring the people? If it i
s more than one second, you need to slow down your frame rate.

[MG]

To answer your question about the camera frame rate - it all depends on the camera.

Most cameras that interface with the 1409 are putting out either "NTSC video" - 60 fields per second or 30 frames per second, or "PAL video" - 50 fields / 25 frames per second. I've not seen other frame rates available in an analog video cameras, although I'm sure they exist.

On the other hand, there are a lot of high speed digital cameras on the market that can deliver the 400 frames per second, but they're not cheap.

Take the DALSA CA-D1-0128 camera for example. It does 736 frames per second (and slower), at 12 bits per pixel but it only has 128x128 pixels. This camera costs about $3000. The data rate to support 4 of these cameras is 4 cameras x 128 x 128 x 2 bytes per pixel x frame rate = 131072 bytes per frame (where a "frame" in this case is one image per camera). 400 frames per second would be 50MBytes per second. The NI PCI-1422 card can handle this type of data rate, but you would need an intermediate interface box to handle the interleaving of the 4 camera's data into it.

Or you could possibly use 2 PCI-1424 cards, with 2 cameras per card but I don't think it can switch among the 2 cameras at the 400 Hz.

If you must have the 500x500 resolution, the the data rate skyrockets to 382MBytes per second for an 8 bit per pixel system (not possible on a PC).

If spatial resolution and high frame rate are both hard requirements, then you would want to have an interface that takes the camera down to the 2 bits per pixel that you mentioned, and pack the output from all 4 cameras into a single byte before pulling it into the PC (or pack 4 pixels from the same camera into a byte - whichever suite the application s/w). This way you still have a pretty high data rate (25 MB/Second) but it is feasible.

The comes the question - what are you going to do with all this data? If you plan to process it in memory, then through it away, that's pretty easy. If you want to actually capture it to disk, then you'll need a JBOD or RAID array to handle the data rate. We built ours from SCSI disks, but you can buy one from www.videoguys.com that is built from IDE drives. Either way it's going to cost several thousand $$ depending on capacity & data rate requirements.

If you can live with compressed video (such as MPEG) then this becomes a much simpler (cheaper to solve) problem because standard IDE drives can keep up.