Transferring variables in a loop

[svif]

Im trying to reprogram my image analysis program to increase computation speed (separate in two parallel threads). However there seems to be some problems using shift registers to transfer the variables (images) from one loop to the next.

Main program: speed test4_mod.vi

The program does the following:

Cycle i=0:
Opens new image
Does a convolution (on new image)
Sends this original image and the convoluted to next cycle using a shift register

Does the rest of the analysis on empty image.

Cycle i=1:
Opens new image
Does a convolution (on new image)
Sends this original image and the convoluted to next cycle using a shift register

Does the rest of the analysis on the image from last cycle.

Cycle i=2:
The same as 1...

There seems to be some problems. First of all, the first image that should be fully processed in cycle i=1 seems to not be processed (the result does not come out).
Sometimes the result is incorrect for a single or two of the images. It does not happen on the same image every time, but seems to be random.

Is there something wrong in the way I transfer from one loop to the next?

If the result in the “blobs” array correspond to the values to the right then the results should be correct. The first result should be 0 since an empty image is loaded. The next result should be from image number 1 which is 96. For some reason all results are shifted one space.

Thanks,

Simon

The images and sub vi's (U8 image read) needed to run the program can be found as attachment in this thread:

http://forums.ni.com/ni/board/message?board.id=200&message.id=10540

I+Coul_max_sig.zip (1452 kb)
U8 File.zip (41 kb)

[svif]

I think I solved the problem.

The linking via shift registers of two different image variables seemed to go bad.

By using imaq copy to copy the images and then send to the shift register solved the problem.

[Vladimir_Drzik]

Ugh, what an ugly code with that image copying

I think the main point to understand here is that images in LV are passed only as a reference, not as an instance. I.e. if you have an image on a wire and fork the wire, you still have only the one instance of the image and not two different copies, as you would have with arrays or other LV types. This is the case with speed test4.vi. You create four images, that is all right so far. However, you put ImA and ImB into the two input tunnels and ImC and ImD into the two shift registers. In the first iteration of the loop, ImC and ImD are used once and then not used any more, because you put ImA and ImB into the shift registers. So, in all the other loop iterations, you have ImA and ImB in both the input tunnels and the shift registers, so you are doing the image loading and image processing in parallel on the same images, which can do many different and nice effects . My solution would be to use two shift registers instead of the image tunnels. On exit of each iteration, I would put the two images that were processed into the new shift registers, so that they would be used for loading in the next iteration. Thus, in each iteration, the couple ImA, ImB would swap their functionality with the couple ImC, ImD, so you would always be doing loading on a different couple than the processing.

Hope I explained it clearly enough, good luck

Vladimir

[svif]

Yes thats right, I changed it now.

Actually on my pc the parallel runs just as fast as the serial, even though it is a single core cpu. Hopefully some improvement will be seen on a dual core cpu - if so when the conroe comes I may be able to run this a 40 Hz.

Regards

Simon

[Vladimir_Drzik]

Hi, just one more note to your code. The reading from U8 file and the conversion from array to image will be carried out before anything in the sequence structure starts, so you won't get any parallelism on that. If that was the intention, just ignore .

Vladimir

[svif]

I know. This is just a test program running on images I know.

If this is indeed a good solution I will implement it in my data recording program. The U8 read will be replaced by a grab - which will be running together with the first convolution. The grab however is very fast compared to the other operations.