Image Size Mismatch Question

[MattA1]

Hello forum,

I've had a lot of help from you guys in the past, hopefully you'll be able to give me some tips on this as well.

In the attached .zip archive is a vi I've made to get an image from a confocal scanning laser microscope. The

main has the same name as the zip folder and all the subVIs should be in the necessary folders.

The idea is that the computer running the microscope (call it "FLUO") waits for a "Trigger In" signal from the

computer running my code (call it "LV"). Once it receives this signal, FLUO starts to scan the sample. Every

time it starts an image line, one of the outputs from FLUO (called "Line Active") goes TTL high. LV is listening

for Line Active to go high (using the digital reference polymorphic) and when it does, it collects one line's

worth of light intensity values and puts them in a 1-D array, pre-initialised to the "length" of the whole image

(eg. 512x512=262144 elements). Once it has received the expected number of Line Active signals (for example,

512) it exits the loop and reshapes the 1-D array to a 512x512 2-D array. This is then processed into a grayscale

image and displayed in the two FP boxes.

The problem is manifesting as LV appearing to hang, even when FLUO has finished all its acquisition. If I take

FLUO off the Trigger In setting and do a second scan manually while LV is still "stuck", the resulting image appears

to contain all the data from the first scan, "squeezed" into the top 2/3 or so of the image, and a portion of the

second scan appearing in the rest.

I'm not really sure what's going wrong here; it seems as though LV receives all the data from FLUO, but quicker than

anticipated. As a result, the image is finished before the loop can exit, but I really don't know why. My code is below,

so if anyone can help me, I would very much welcome it.

Thank you in advance.

[Tori.M]

Hi MattA1,

Thankyou for posting with so much detail and including your code, though sorry no-one has got back to you before now!

Initially, it seemed as though the issue could be due to sequencing in your code. If the data is passed to the IMAQ ArrayToImage before the data acquisition has finished i.e. the code from Send FluoView Trigger.vi. This could be rectified by wiring an error cluster through as shown in the image below.

 

However, what I feel may be a better option would be to add another case to your enum which disposes of the previous image.

Currently your IMAQ Dispose VI is outside of your while loop, therefore it will only dispose of the image when your VI finishes executing. I would advise to make a case that executes just before you acquire each time and in this case dispose of the previous image, before you use IMAQ create in the acquiring stage. This will hopefully prevent having two images present at the same time.

Hope this helps and let me know how you get along!

[rpursley8]

You might have a timing issue.  It appears you tell the microscope to acquire, and then you configure you acquisition and then tell it to go.  The configuration takes some finite amount of time and you might be missing the beginning of the data.  I think you need to configure your acquisition task during 'Initialising' and then since it is a triggered acquisition, tell it to go when you get to 'Acquiring' first thing.  Then you should send the pulse to the microscope.  That way the acquisition is ready to acquire before the possibility of data being sent.

[MattA1]

Thanks very much for your suggestions!

I've just got back into the office after a weekend away and I'm keen to try what you've suggested.

Tori, I will make the changes you recommend, as that makes a lot more sense than my present set-up, although I'm not sure to what extent that's contributing to the main problem,

as the image is wrong in both FP indicators (the "picture" display as well), and not just the IMAQ display.

To better explain the problem I'm seeing (I think my description may have been misleading), I've attached some images. The red false-colour image (starch1F) is a reference from a separate computer to show what my program *should* be producing (the colour is inconsequential). The grayscale image starch1 is what's actually produced by my code, and the third image, starch stacked, is a composite image where I've resized a region of starch1, swapped some of the image over to the other side, and overlaid it on starch1F to see where they match up.

Randall, that's an interesting idea. I'll try removing the task configuration from the acquisition subVI in my code and separating it out to see if that helps. However, based on the images I've acquired so far (and attached below) it looks as if all the image data is in fact there, just some of it's in the wrong place. Still, it can't hurt to be sure!

[Tori.M]

Hi MattA1,

Thanks for the images. Let me know how you get along implementing the suggestions 🙂

If I think of anything in the meantime, I'll also let you know.

[MattA1]

Hi guys, thanks for all your help!

In the end I decided to use a different method to synchronise the lines. Instead of waiting for a trigger every line, I ended up doing something much simpler, which I'd been considering for a while; just using the "start frame" trigger and throwing away an arbitrary number of pixels at the end of each line to account for flyback. It's not perfect, but it works for now.