IMAQ Write File 2 creates "motion blur" artifacts in the saved tiff images

[zou]

@ Ellie90

Save to file is a slow operation.  Can you create an array of images in the initial phase, and save the whole array of image to files when scan complete?

Does Hamamatsu VIs support events?

[X.]

---

@zou wrote:

@X.  Taking image when camera is moving shouldn't be a problem as long as the exposure time is short.  In one of our motion-vision project, the camera never stop when taking picture, not even slow down.

---

That is clearly not the case in this experiment, from what I gather.

[Ellie90]

@X. Thank you for the reply. I don't think the stage moving is the issue. Because I don't see those artifacts in live mode -- in this mode the stage moves the same; the only difference is I don't save any images. Also, the step size of movement is 10um, but the bluring I see in the saved images could be several tens of micros. It couldn't be that much if it is just the stage not calming down. 

I upload the code including the main VI called "Image Acquisition_RAM_tab" and some of the sub VIs. I apologize there are so many files. But probably only the main VI and "SPIM Acquisition" VI would matter. I upload the others just in case. Thanks again for all the help!

[Ellie90]

Hi Zou, thanks for the help. I will try array and see what it does. But I don't get your second question. Why do I need the events? What I am thinking to use array is first to initialize an array with 2048 by 2048 by #of images size, and then replace one of the initialized frame in each loop, and save all of them in tiff format using a while loop after the acquisition completes. Does that make sense?

I am really interested in the motion-vision project you mentioned. I am wondering how you achieved "nerve stops the camera when taking pictures" because I have to stop the camera to move the stage and I really want to speed my imaging up. Also, I just uploaded my VIs so you may want to have a look if you are interested in. Thanks!

[X.]

---

@Ellie90 wrote:

@X. Thank you for the reply. I don't think the stage moving is the issue. Because I don't see those artifacts in live mode -- in this mode the stage moves the same; the only difference is I don't save any images. Also, the step size of movement is 10um, but the bluring I see in the saved images could be several tens of micros. It couldn't be that much if it is just the stage not calming down. 

I upload the code including the main VI called "Image Acquisition_RAM_tab" and some of the sub VIs. I apologize there are so many files. But probably only the main VI and "SPIM Acquisition" VI would matter. I upload the others just in case. Thanks again for all the help!

---

That you don't think the stage moving is the issue is like... your opinion 🙂

The fact that a code behave one way when you use it in "live" mode and in another when you use the "save" mode is symptomatic of some race condition kicking in when some new piece of code is activated.

I was willing to help, but taking a look at your Image Acquisition_RAM_tab.vi (which has a load of subVIs which I don't have access to, so it is obviously a bit patchy), I don't think I qualify for this kind of Good Samaritan job.

However, I would not be surprised if you had race conditions in some corner of that spaghetti code... I am not blaming you for the coding style of these VIs, but in essence, you are shooting yourself in the foot (and in the back) by this kind of design (or lack thereof).

Luckily for you, LabVIEW Next Generation will solve all these problems. JK.

Good luck with your project and I apologize for not being able to be of much help.

[zou]

Yes. it make sense.  It's good that you are using 64bit LabVIEW.  So you can take advantage of extra memory.

You goal should be: make the save mode works as close to live mode as possible.

How many images do you need to finish one scan?

8 MB is a lot.  It makes program slow down.

We use IMAQdx to acquire images.  It has extra builtin buffer to avoid memory overwrite.  On top of that, in the initial phase, I create an array of 300 images (~2400X1024) as a circular buffer.  So only the last 300 images got saved.  We process the image on the run, save the results instead of the images.  Our images are 8bit, save as jpg, with a file size 200~500 kb.

[X.]

I took some time to analyze your code. Beside the fact that it is an absolute horror in terms of architecture (again, don't take this personally, we almost all have gone through this phase of LabVIEW programming by diagram expansion), it is quite clear that the scanning and imaging part do not "talk" to each other in the live mode and therefore CANNOT be synchronous except by chance. Therefore, you do not see blurred images for the reason brought up by zou, i.e your camera exposure is too short to see any effect of scanning.

As far as you "Imaging" mode is concerned, you are looping through X and Y steps, and within that loop, appear to do two things successively: acquire an image and save it followed by move the stage (or whatever it is that you move) along both axes. When you do that, you seem to be waiting for the motor to be "not busy", which should in principle prevent any residual motion when come the next iteration and time to take a new image.

The "Save Image" part is doing a lot of unnecessary things (such as forcing copy of your image array - don't) and recreating and disposing the image structure to put it in... Just replace this:

by that:

with a simple path through wire in the False case not shown above.

Notice that there is no wait 200 ms function in there.

See whether that helps.

[billko]

oops nvm

[Ellie90]

Thanks so much for your patience. I apologize for my current "spaghetti" code. I will keep learning and improving.

I guess there is a misunderstanding of the "Live" Mode here. The "Live" mode I mentioned before has nothing to do with the case "Live" in the code; you can just ignore the "Live" case. It is actually the "Imaging" mode when choosing not to save any images to disk, i.e. it is just not running through the "Save Image" part (the one you pasted), but still display images in front panal. 

So the issue I met was when I ran the "Imaging" mode and chose not saving images, I could see the images in front panel with no artifacts in them. However, if I chose saving images, I would see artifacts in the live images as well as in the saved tiff images.

Zou suggested storing the images in an array first and then saving them all after all the process completes, so that the acquisition wouldn't be influenced by the saving image part. I tried it and it worked. But I can't say I really solve this problem because I later found that if I add a delay time in the frame before image acquistion frame, the problem showed up again even though I store images at the end.

It is clearly not just the overwriting issue now. And I guess that the "Save image" part in my previous code may act as a delay and make the artifacts show up, but it is not the root cause. Adding delay would cause artifacts doesn't make any sense. I am really curious and confused. It might be the stage movement you mentioned before. But I have a waiting for the motor to be "not busy" as you have noticed too. 

Fortunatelly, the delay is not necessary so I can still get good images currrently. 

Your code seems more efficient than mine, and yes I will definitely try it. Thanks again!

[X.]

I need to clarify one thing (which I thought obvious, but nothing ever is): the "Init?" control that I added on my code snippet needs to be promoted as an input on the connector pane of the VI it resides in, and you should pass a "True" value when running your main VI for the first time, and a "False" value otherwise (in other words, pass a "True" value on the first iteration of the first scan, and "False" ever after).

You should also in principle dispose all images at the end your main VI, although it probably doesn't matter too much.

This being said, the symptom you describe seem to indicate that the "Motor Busy?" test doesn't tell you much about the actual motion of your setup. The motor might be "ready" but still moving by inertia, or something else in the setup is moving...

What kind of camera integration time are you using and what magnification (to have an idea of the amount of motion needd for you to experience blurring)?