How does labview deal with enqueuing/dequeuing images?

[lshi]

Does Labview make a copy of a image whenever it enqueues (what about dequeue) it? In the other words, if I only create one image during the acquisition, will the empty of this original one cause the lose of the images in the queue?

I am thinking of having one loop (subvi) to do the image acquisition and the other loop for the image process.  The acquisition will take 30 images (for different LEDs) in a roll,  send this image array to a queue, and then keep acquiring. The other loop will dequeue it when it has time. Could this enqueue/dequeue process slow down the acquisition (e.g. wait for the image copy of the whole array)? How to make the acquisition subvi higher priority.

[RavensFan]

There have been at least a few threads about this in the past.  An image is actually only a reference to a memory location.  If you enqueued 30 different images before you dequeued any.  You'd find that you'd have 30 identical images of the the very last image once you begin dequeuing.

[lshi]

But would this actually compromise the purpose the queue, say, if you couldn't get fast enough to process then put the images in the queue to avoid lose of information. What if the acquisition subvi finishes first and empties all the image it created. Would that cause the remaining images in the queue which are just references become somewhat undefined references?

What if I group the image array into a cluster first than enqueue. Will that make any difference?

[RavensFan · Accepted solution]

It all depends on what you are enqueuing.

In the messages I saw where people had problems, they were enqueuing a reference.  No I can't remember exactly what kind of reference it was.  Perhaps it was an IMAQ reference.

If you are enqueuing the actual data array for the image, I think you'll be just fine and won't need to do anything special.

Best thing to do is try it out and post back if you run into problems with a sample of your code.

[lshi]

Yes, I just tried it. Not actually acquiring images but read from files. Looks fine to me. It should be the data that's been enqueued. Now I need to find out if that will slow down  the acquisition or not.

Thank you,

[lshi]

Well, I found some mistake in my previous trial, looks like I have to take back what I said. It is the reference (or more like pointer I guess) that being passed around. It seems to me that putting images in queue will only work for multicores. Overwrite will happen if the process can not catch up with the acquisition.

[RavensFan]

One possibility is to create a new reference for each image and enqueue that reference.

Then when the reference is dequeued and processed, the reference can be destroyed.

[hans17]

Ravens Fan is right on here.  I needed to pass images from my acquisition loop which must run at a reliable 1 Hz rate, and my AVI storage and image processing loops.  Using a queue to pass a reference to each acquired image works well.  After the AVI storage and image processing loops create their working copy of the image using the queued image reference, they destroy the queued image reference to free up the memory it had used.

Before implementing this in my app, I created a test VI to verify that this concept works.  See attached VI, control typedef, and JPEG block diagram screenshot.

Hans

[Rick_J.]

I find myself going down the exact same path ... many copies of the same image.

I've been trying to Create and enqueue the image reference rather than the image, then destroy it after saving the actual image but I'm having some problems making it work smooth.  Can you post the three VIs again?  The links appear to no longer work.  Thanks!

[hans17]

Hi Rick J,

The links still work for me.  Perhaps you have a firewall blocking access?

Hans