LabVIEW
Image capture with LabVIEW
That’s a mere 1000 frames per second!
Considering that your camera only has USB-2 connectivity as you say, my answer would be a very hard DEFINITLY NOT!
Looking at the specs the chip can handle 24 fps at full resolution and 600 fps at 64*64 pixel resolution.
As far as your speed requirements go for full resolution you are looking for cameras with probably at least two zeros more at the end of the price tag, and yes I’m talking before the comma! 😀
Also even a GigE interface won’t be enough to satisfy the necessary transfer speed! So you end up with even more complex interface solutions or a camera with local memory that can buffer frame bursts and send them on the slower connection (but GigE or USB-3 at least anyhow).
@Stan1378 wrote:
Is it possible to create a VI ,which can capture the image per 1 ms for 50ms with camera ?
If "the image" is an (tiny) ROI, it's still not possible (but you can get close):
usb2-0-monochrome-1-3mp-cmos-cameras-enclosed:
and the frame rate can be as high as 24 fps in full resolution and up to 600 fps using ROI mode
It could be tricky to get LabVIEW and the camera to return an ROI though. Or not. I'm not sure if there are (build in) standards for this.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
It could be tricky to get LabVIEW and the camera to return an ROI though. Or not. I'm not sure if there are (build in) standards for this.
There isn't afaik. With Genicam compatible cameras you could most likely use attributes to configure the camera to do that, but the attribute names and characteristics are likely very camera specific. But for an USB-2 camera it is very questionable if it would supporrt Genicam.
@rolfk wrote:
wiebe@CARYA wrote:
It could be tricky to get LabVIEW and the camera to return an ROI though. Or not. I'm not sure if there are (build in) standards for this.
There isn't afaik. With Genicam compatible cameras you could most likely use attributes to configure the camera to do that, but the attribute names and characteristics are likely very camera specific. But for an USB-2 camera it is very questionable if it would supporrt Genicam.
So I guess it's up to the manufacturer to tell how\if this is possible?
Their software can do it, so there still is a change it's possible form LabVIEW.
Without the camera to toy with, there's little we can do I suppose.
Of course even if it works, the required ROI to get to the max. of 600 FPS (not 1000) will be tiny. Probably pixels.
wiebe@CARYA wrote:
Of course even if it works, the required ROI to get to the max. of 600 FPS (not 1000) will be tiny. Probably pixels.
The data sheet I found said 32 * 32 pixels.
Ah, there's also a SDK there. Pretty sure the manufacturer will refer to that when asked about this.
So it is possible to set these values with the SDK, and use it to read images. It won't fit IMAQ\NI Vision out of the box though. After glancing through the SDK, I don't think it will be that difficult to make it fit.
How small can you accept to have your pic for acquisition? As explained in this thread it depends on the size of the image you actually tell the camera to transfer. It has a so called ROI mode where you tell it what Region Of Interest (ROI) of the entire image you want to actually have transfered to your computer. If you can live with 32*32 pixel you can go up to 600 fps = 1.7 ms.
At 64*64 pixels you have 450 fps = 2.222 ms frame interval and at 160 * 120 pixels it is 300 fps = 3.333ms. If you need the full 1024 * 1280 pixels you have 24 fps = 41.7 ms.
What about those data in the datasheet I linked to wasn't clear to you?
Your comment about delay is not clear. If you mean if you will see the image instantanously in the computer the microsecond it is acquired on the camera, then no of course not. The image is streamed through the camara on board image processor to the USB connector, from there to the computer USB interface, through several layers of drivers in the OS and finally into LabVIEW. All this typically can take many milliseconds latency but as long as each of these parts can keep up with the datastream, you still can read the images frames as fast as the camera can produce them as the video acquisition processing chain is optimized to keep delays constant over the entire chain, not to make them as short as possible. Video streaming can't work if the driver works itself into sweat to deliver part of an image within microseconds but then decides to take a break and go for a coffee before the rest of a frame is processed. Instead it tries to do continously junks of work in a steady but not necessarly maximum speed to guarantee a continous stream of data without large interruptions inbetween.
@Stan1378 wrote:
If I change the capture time to 2 ms or 3 ms per image.
Is it possible to use this camera?
Probably, if the ROI is small enough.
Those are big steps though, going from 1000 FPS to 500 FPS to 333 FPS.
@Stan1378 wrote:I wonder that how long the delay time with that camera during the capture?
Do you mean latency? On Windows, who knows? 50-250 ms?
@Stan1378 wrote:Will it bring about any loss with the image?
The camera has an option to decimate. So even though your image ROI is 64X64 pixels (for example), you only get the 32X32 (even or odd) pixels. Then there will be loss. But you can make the area bigger.
@Stan1378 wrote:Causing the time can’t control accurately in 2 ms or 3 ms .
Not sure what that means.
The camera will have it's own timer, set to the desired framerate. The camera will feed images to the PC. The PC needs to read them fast enough, but precise timing isn't required on the PC.
