08-10-2017 03:08 AM
One important thing here is that the IMAQ image wire is a "by reference" type, and we are just passing a pointer around (unusual for labview where normally data is on a wire). This makes producer consumer NOT so good in general, as by the time you pass an image to the consumer, you may be modifying it. It is possible but takes more care, you'd have to create a new IMAQ buffer for every enqueue which is obviously increasing your memory, and just isn't really needed unless you are having data throughput issues.
As it is by reference, I don't see a need to use queues at all. You can simply create an array of 1024 IMAQ images, and manipulate these using 1 extra image buffer. No need to use inplace element structure to prevent copies (you are only copying a pointer after all).
In summary, create 1024 IMAQ buffers (IMAQ create in loop), make into array. One extra IMAQ create to store the new images that you are bringing in for calculations (it will get reused at least 3078 or times!). For each calculation, use the index array to retrieve the correct image. You don't even need to replace the array element after (as it is a pointer which hasn't changed). Every 1024 images you just change the calculation, see the normalise index in Matt's post. All done, you end with an array of 1024 images as required, and you only used memory for 1 extra image.
I don't have vision toolkit any more, if you really get stuck I could mock up something like Matt has done.
08-10-2017 07:03 AM
Hi Ian,
I was only looking at the .png of the program, but that wire looks more like an LV image than an IMAQ reference wire. Is the reference being passed around? Or the image data itself?
With respect to buffers, I like the solution used in this post which creates and destroys buffers as they're needed/used. This way you only ever have as many buffers as you need.
08-10-2017 07:18 AM
I saw the IMAQ type in the context help window on the PNG. As you say, there is definitely some LV image data in the diagram (this passes actual data, compared to IMAQ which passes a ref).
As I don't have the vision module any longer, I am only guessing that the processing would be done on the IMAQ datatype, unless there is a good reason it is generally a better option. I don't see a need to convert to LV image type before saving either, you can save an image directly from the IMAQ palettes.
08-14-2017 09:05 PM
Hello IanSh And Javin,
Yes, it's not just a reference but it is also passing image data too with that wire. As if you see the Context help then you'll notice that it passing lot of data as in image pixels, and other necessary data in it.
I really like your idea of adding a buffer and not to enqueue the data as I have done originally but do you really think it will be possible in my case as the image has data and information in it.
These images files and everything isn't particularly based on IMAQ but I am only saving the images through the IMAQ save bmp format.
Some part of these library files are a little complicated for me to understand being a naive labview user as some of these library files I received were from the company I purchased the camera from.
I also noticed that the Run and Inititalize block on the .png attached are actually creating the queue inside it already so there isn't any point for me to add a queue outside separately as it will add the complexity.
@IanSh: I saw the producer consumer loop idea and trying to build one in that. So, do you recommend to do all the processing I would like in consumer loop? Basically to implement the logic in the secondary loop all at once?
And, moreover, as I mentioned that I am trying to perform the phase unwrapping and my ultimate goal is to compute this equation: 3I(2)-3I(3)-I(1)+I(4)/ I1+I2-I3-I4. So, for this I am thinking to add another consumer loop but only one producer loop feeding both of them so that at the end I have the value of numerator and denominator after processing and then I will simply divide those two stacks from each other? Will this be a right approach or any other suggestion?
@Matt and JavinD are also welcome to put in their suggestions.
Thanks a lot.