LabVIEW animation picture ring memory allocation

[Fibo]

I'm creating an animation in labview, I have 1,000 images that I need to flip through, I'm using a pict ring and flipping through the images... problem is after loading about 200 images (they're 20k each) my computer throw in the towel, the RAM is full the Virtual RAM might be full.... I'm wondering if there is a workaround around this?  Any kind of way to manipulate the memory so I can finish?  Maybe it's more of a computer thing than a LabVIEW thing... I was thinking, if I increase my machines virtual memory to "alot" and tell LabVIEW not to use th RAM just use the virtual memory that maybe I'd be able to continue, but I don't know if this is possible or how to do it... any suggestion/advice?

much thanks!

PS - I realize that there are other programs that are well suited for this and that LabVIEW really isn't animation software, but I MUST use LabVIEW to do this and I'm lookin for advice to find out whether or not this task is possible in LabVIEW. thanks.

[smercurio_fc]

For that many images you're probably better off making an animated GIF and playing that. If you're not going to need to change the animation at run-time then you can simply drag the animated GIF right onto the front panel and save the VI with the animated GIF embedded. Note that animated GIFs can be CPU hogs.

Alternatives? Are you on Windows? If so, you could use a browser ActiveX control to play the GIF or you could use an animated GIF ActiveX control. If you Google for "animated GIF ActiveX control" you should be able to find some.  You could also make a video out of your images and use a video ActiveX control.

[Fibo]

Thanks for the tip, they are PNG files, I'll look into what your describing

[tst · Accepted solution]

I would advise not to use the picture ring, if only because it's not very convenient.

You can use the picture control, which will allow you to read in and display the PNG images one after the other (using the VIs in the picture palette) and here you have two options:

1. Read the files in one at a time. This might be a problem if you do this quickly and repeatedly, but will solve any memory issues you might have.
2. Read the files in once and keep them in memory. Note that the picture control does not have any compression, so the actual size of an image in RAM would be PIXELS x 3 bytes (or x 1 byte and a bit, if you have an 8-bit color depth), so the amount of RAM will depend on the size of the image. For a 200 x 200 image, this should be 120KB, assuming I did my math correctly.

[Fibo]

Much Thanks, the picture control option worked!

[avictor]

Hopefully I can reingnite this older post...

I am doing a very similar project.  I have 17 separate Picture Ring indicators each containing 30 stills (png) which will be used to create user demand animation (ie. explode a picture, retract a picture).  For this reason, the picture ring is the perfect candidate.

After loading most of the images, I receive an Low Memory error from LabVIEW.  I am convinced that this problem is more than just RAM.  I have 16GB and monitor it...don't even come close to 16GB.

Any help or suggestions would be greatly appriciated.

Thanks!

P.S. I need the images to be very repsonive.  This is why I load them all into labview.  I have tried using the Picture Function to load sections of images from HD, hopeing this would help;  I run into the same memory issue.

[Hooovahh]

For that many images, and that much data, I'd still suggest trying to load the images as needed, or maybe load the image, and the next one into memory, and then when you need to change the image, you already have the data for the next image, then load the next image while that one is being displayed.  What I'm getting at is if the load time is too long, maybe you can load when the user isn't caring about what the program is doing.

Alternativly have you looked into the .NET picturebox stuff at all?  It might load and display an image faster than the LabVIEW tools because it doesn't have all the data from every pixel, it is all just in references instead of values.  Here is an example of loading a picture from a path.  The browse dialog defaults to BMP, but any normal picture format including JPG and PNG should work.

http://forums.ni.com/t5/LabVIEW/NET-picturebox-example/m-p/602767#M280961

[avictor]

Thank you for your fast response!

I have tried loading images via Picture function Read PNG.  Unfortunately, having these images in memory is an itegral part of the program and a time delay of even 0.5 second is unacceptable.  This program is used for display purposes and must be ready at all times to load the selection of any one of the 30 picture animated sequences at anytime.

What I don't understand is the labview memory error when I have an available 4GB of RAM.  Is there something else that could cause the program to have this error that is not RAM related?

I will look into the .NET picturebox as well!

Thanks.

[tst]

To get a sense of scale, I assumed a 500x500 image size, which comes up to a total of ~400 MB. You're right that this is less than 16 GB, but here are a couple of points for consideration:

1. Your LV is probably 32 bit. Even in a 64 bit OS, there's a limit to the amount of RAM a 32 bit process can get. It used to be 2 GB, but it's probably higher in newer versions of Windows. In any case, it won't be more than 4 GB.
2. 4 GB is still more than 400 MB, but then comes the next thing - memory allocations for certain things need to be contiguous and finding 17 contiguous blocks of 20+ MB might be an issue. I'm not sure about the requirements in this case, because I don't know how picture rings are stored and picture controls are basically a string, which is a pointer, so it shouldn't be contiguous, but I'm not sure they allocated like strings. I expect it should be possible to load your images in a non-contiguous manner, but avoiding copies of them might be more tricky.

I expect the easiest option for you (other than using the .NET control, which should use compressed images directly) might be to convert the images to videos and then play those in an embedded player.