Producer Consumer, UDP, real Display and Affine Transformation

[Kenai23]

Dear LabView Community,

I have the following problem:

I have a laser scanning microscope which I am using to acquire fluorescence images from in-vivo animals (mostly the skin of the ear) either with 5 or 10 frames per second. The software is from the microscopes manufacturer and written in C++. Since in-vivo imaging is done, real time averaging and signal summation is very crucial (since the signal of fluorescence is very low in our case). Therefore the microscope has also some real time tracking implemented. 

I was interested to test different detectors wherefore I started to use LabView and the ATS9462 (since I can not access the software of the manufacturer). I am running my own programm in parallel while using the same pixel, line and frame clock of the laser scanning microscope. So far I am able to reproduce the same result (Live Image) on my computer with my hard and software while accessing the above mentioned trigger signals. 

However, I am stucked at the real time averaging. 

The microscope is sending out the information for the real time averaging (Transformation matrix as a String and also the time stamp when this matrix was created ) per UDP.

In my LabView programm (please see a very simplified version attached) I am also creating a timestamp after receiving each buffer (live image) which can help me to adress the right transformation matrix (obtained per UDP) to the right live image (acquired with my LabView programm).

In my acquisition loop im using a cluster to drop in the acquired live image including the timestamp (my LabView), as well as the information from the UDP (Transformation matrix + time stamp (from the scanning microscope)). This is actually all working, however I do not have a chance to correct for any mismatch.

It happens often that the acquired live image with labview is shifted by one frame in contrast to the transformation matrix from the laser scanning microscope received per UDP (so the next acquired live image would actually suit the transformation matrix from the iteration before...).

I was thinking that one solution would be to decouple the live and affine loop? In the new created loop I could create a buffer for the transformation matrices including their time stamps, and another buffer with the live images and their corresponding timestamps. After creating 5 or 10 buffers (1 or  2 sec) I could start to rearrange the buffers to sort the correct transformation matrices to the correct live images and then do the calculation?

Please let me know your thougths,

Thanks

[Kenai23]

Dear All,

pleae let me know whether my problem is clear or not, so I can try to explain in more detail?

I would appreciate any support from your side?

Thanks a lot!

[jfara]

Hi Kenai23,

if I understand it correctly the problem is that the LabVIEW sometimes start measurement one frame after the microscope, so the shift is present through the whole measurement.

Then, if the shift is always 0 or 1 frame the easiest solution, in my opinion, is to use shift register and compare if the shift occurred or not. If there is a chance that a bigger shift may occur than using a bigger buffer and rearranging it should be a solution but in this case, you don't have the matrices for the first n (n = size of the shift) images in the buffer.

Please let me know if this answered your question

[Kenai23]

Dear jfara,

thanks for your reply. You understood the problem correctly. In the mean time I implemented shift registers where I can access the last recorded (at the moment 5) frames (like a ring buffer). With the correct If and else If statements this seem to work. However I am not sure whether this is the most elegant solution...

I guess you meant doing exactly the same? What do you mean by bigger buffer? Can I not increase the size of the shift registers, or is there a better alternative to that?

Thanks a lot,

Kenai

[jfara · Accepted solution]

Hi,

I guess you meant doing exactly the same?

     I think so.

What do you mean by a bigger buffer?; Can I not increase the size of the shift registers, or is there a better alternative to that?

     Increasing the size of a shift register is useful for small buffers (like five elements). You can easily imagine that it starts to be a little messy for higher values. For bigger buffers, it is better to use a shift register with array and store values in it (see picture below). Also, this solution is better if you need to look up specific elements from the buffer (For example if the shift can change during the measurement).

I also add an example of a shift register with an array.

Hope that help.

[Kenai23]

Hi jfara,

thanks for your reply. I replaced the shift register with arrays and indeed the code looks much cleaner. As a next step I will also implement the for loop (instead of logical comparison (up to 5 Frames now)).

Thanks a lot!