LabVIEW
Fast image processing
In the title you state fast image processing, not acquisiton. Does this mean you need to perform actual image processing? If so, then the answer to whether you can process the data depends not on whether you use LabVIEW, but on what processing you intend to perform.
LabVIEW's image processing features are fast, and comparable to any other language, but as with all coding if you implement a slow solution then you will not be able to achieve the frame rates you are interested in. Having 24Gb RAM is not really important if you don't need to store all the images in memory at once.
What kind of format image are you acquiring? (8bit, 24bit RGB, 32bit ARGB)
For how long are you acquiring data? (A few seconds, minutes, hours, indefinitely)
What do you plan to do with the images (Process, simply save to file, perform complex analyses)
If you are saving 500 frames per second, with 8-bit B&W 512x512 images, then you are looking at streaming 131Mb/s to your storage media. This is a lot of data and can not usually be achieved on a standard desktop PC. Therefore you might find you need to queue the images in memory whilst saving them.
To do this you might want to look at the Master Slave or Producer Consumer architectures, that will allow you to acquire your images in one process and store them in a memory queue, whilst saving the images to file in a parallel process. If the acquisition process is faster than the saving process then the images are buffered up in the queue and not lost. The limitation to this is how many images you can keep in memory.
You say you have 24Gb of RAM, so presuming you have access to most of this for the queue buffer then you can potentially store up to 183 seconds of data. However, in reality you will likely be able to acquire for much longer because as the save process stores your images on disk you are emptying the queue and making space for the new incoming images. The true limit will all depend on the speed at which you can save the images to file. If you can compress them as compressed image files then you don't need to achieve a storage rate of 131Mb/s, but this requires CPU time so you might lose out a little to that.
When it comes to displaying the images, there's no point in displaying every image at 500Hz because you display , and indeed the human eye, cannot process data at that speed. I would suggest taking every 10th or 20th image to achieve an update rate of 50 to 25Hz on screen.
Remember though, anything you do to the data in real time (displaying, analysing, processing etc.) will take potential CPU time away from the saving process causing the buffer of images to fill much faster, and potentially reducing the maximum acquisition time.
Good luck!
