High speed IMAQ application in LabVIEW

[MartinP]

I'm looking at an application now, using a Basler A204090uc  USB 3.0 camera, for grabbing frames up to a framerate of 60 frames/sec, using full picture size of  2040 x 2046. We are going to do this up to 30 minutes, varying the framerate between 60 and lower. This means we have to save to disk during the aquisition, as this is a lot of data. I would like to have tips about what NI hardware and computer setup I should investigate closer to use for such a setup. Something that can handle this datastream to disk on a good way. We do not need to do anything with the frames, only save to disk. At the end, I want to create an AVI film of the series of pictures.

Anything, anybody ?

Martin

[TiTou]

Hello

2048*2048*3*60/(1024*1024) that's 720Mo/seconds so even a good SSD won't be able to save fast enough

And if you acquire at 60fps for 30 minutes that's 843.75 Go so that's quite an amount of data.

Are you sure you have to save it all?

NI has some RAID hardware (https://www.ni.com/en-us/support/model.hdd-8266.html) that should be able to handle that, I've never used all that stuff, good luck!

[NASmith]

I agree with TiTou. 

It might be worth reducing your samling rate. Also if you are interested in purchasing any NI Hardware or discussing this further I would suggest calling your local NI Branch. 

Kind Regards, 

Nathan

[BlueCheese]

This seems fairly reasonable to do. You don't need to record color data since the camera natively is sending Bayer encoded pixels (1 byte/pixel). You can de-bayer the image data into color after-the-fact when you convert it to video (IMAQdx includes VIs to do so). This cuts the data rate quite a bit and is well within the range of even single SSDs.

My suggestion would be something like the following:

-Disable bayer decoding in IMAQdx so that you can use the Ring API (otherwise it won't let you since the images need to be decoded). The ring API is optimized for higher speeds since it eliminates copies of data.

-Use a large number of buffers in 64-bit LabVIEW (so you can withstand hiccups in the file saving)

-Configure the image buffers you are using in the ring to have a width a multiple of 64-bytes and have no borders, so they end up being stored as a contiguous array of pixel data

-Use the Image to EDVR VIs (external data value references) to gain access to the image data as LabVIEW arrays without memory copies

-Write that raw data to disk in a single file containing all your images sequentially (eliminates filesystem overhead)

I'd guess using something like two high-end consumer 1TB SSDs in Raid0 would be plenty of space and speed for this application, but the NI RAID system would also be an option if you really wanted a _lot_ more space.

Eric

[Hatef.fouladi]

also first we should know what is application of your avi file
there is many kind of suggest for you but based on your reason of recording
video some of them could be useful and some of them will be useless
for example you can use ROI to decrease amount of pixel that you save
you can use monochromatic saving image if you do not have or need any color processing to reduce files size up to 40%
you can use several useful codec to reduce your image size up to 70 %
you can use image conversion method to jpg image
also you can use some hardware that just use for recording camera instead of using computer all depend on what is the reason of your recording

[MartinP]

Eric

It seems to me you have been through the hurdles I'm looking at right now, so maybe you can help me a bit further.

-Use a large number of buffers in 64-bit LabVIEW (so you can withstand hiccups in the file saving)

MaP: Whats a large number here ? 10, 100 or 1000... ?

-Configure the image buffers you are using in the ring to have a width a multiple of 64-bytes and have no borders, so they end up being stored as a contiguous array of pixel data

MaP: How do I do this ? I think I have disabled the bayer decoding via the property attribute, but I keep getting error -1074360235, "The image width must be a multiple of the image's required line alignment".

-Use the Image to EDVR VIs (external data value references) to gain access to the image data as LabVIEW arrays without memory copies

MaP: Do you mean the External Library Support ? I try searching fir EDVR but find nothing....

-Write that raw data to disk in a single file containing all your images sequentially (eliminates filesystem overhead)

MaP: could you be a bit more specific on how ? Should I flatten to string , and keep adding to an open txt-file , or... ?

[BlueCheese]

---

@MartinP wrote:

-Use a large number of buffers in 64-bit LabVIEW (so you can withstand hiccups in the file saving)

MaP: Whats a large number here ? 10, 100 or 1000... ?

---

It depends on iamge size and frame rate. You'd typically want to make sure you have a few seconds of buffering to allow for delays in disk I/O.

---

-Configure the image buffers you are using in the ring to have a width a multiple of 64-bytes and have no borders, so they end up being stored as a contiguous array of pixel data

MaP: How do I do this ? I think I have disabled the bayer decoding via the property attribute, but I keep getting error -1074360235, "The image width must be a multiple of the image's required line alignment".

---

Yes, since the underlying storage when using the ring API is as an Image datatype, it does require that the raw image match requirements of the Vision library. Just make sure your image buffers have a border of 0 pixels and the width is a multiple of 64.

---

-Use the Image to EDVR VIs (external data value references) to gain access to the image data as LabVIEW arrays without memory copies

MaP: Do you mean the External Library Support ? I try searching fir EDVR but find nothing....

---

What version of IMAQdx do you have? Newer versions should include some EDVR VIs on the Image Management palette. I think there may be an example as well.

---

-Write that raw data to disk in a single file containing all your images sequentially (eliminates filesystem overhead)

MaP: could you be a bit more specific on how ? Should I flatten to string , and keep adding to an open txt-file , or... ?

---

I'd suggest using the binary file VIs and simply appending the binary data for each image to a single file. If you want to get more avdanced you can use the TDMS file APIs for better performance, but I don't think it would be worth the effort given your performance needs.