I have a microscope system that can image a large sample by moving and imaging it in x and y directions and then create a mosaic image. The process is like this: take one image --> move one step --> check if moving is completed --> take another image --> move one step -->...... I am using IMAQ Create --> IMAQ Array to Image --> IMAQ Write File 2 --> IMAQ Dispose to save the images in a tiff format (attached a screenshot of the code). The problem is, if I save the images, they will give me some artifacts that look like a " motion blur", as if the sample is not moving as a unit from top to bottom which is not possible, and are random in time and space (attached one example of the normal and the "motion blur" images cropped from the same position of two images took with different delay time). However, if I am using live mode (without saving the images), the images are quite smooth. I tried to add delay when saving images; it helped when I increased the delay time to 1 second, but that was too slow and wouldn't solve it throughly. The artifacts still happened. I am pretty sure the xy movement has been finished before each image acquisition, but I am not sure how to check if the acquistion has been finished before the movement. Could it be the speed of writing file that causes this issue? If so, is there any way to solve it without sacrificing the speed? Other information that may needed: Software: Labview 2014 Windows 64bit Acquistion card: NI PCI 6255 Camera: Hamamatsu ORCA Flash 4.0 Image size: 2048*2048, 16bit (about 8MB per image) Thanks!

LabVIEW

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

Adding delay can easily cause a problem if the acquisition can continue. The purple wire coming out of the IMAQ VIs is a pointer to the image rather than passing the entire image around. Each time your wire splits, you create a copy of the data. That could add up quickly with a full image so it's better for you to pass the reference around in most cases. This also means it can be modified in other locations. If the new acquisition starts while you're writing to file, you'd expect to see part of the new image show up in the writing.

It's generally a bad idea to be confused AND tell others they can't possibly be correct. It's better for both sides to ask more questions to understand where they're coming from. This will allow you to learn from their thought process as well as allow them the chance to re-think things if more information you add makes them find another conclusion.

If you believe the write is the culprit, that's easy to test. Set up a loop to continuously write images to file. Remove acquisition from the equation. If this fails, you're right. If it doesn't, there's more to it than the write and you're chasing a red herring because that's the easiest place to look at. I'd expect you'd find the latter.

In terms of the acquisition, it's unlikely we COULD use the IMAQ functions. When we discuss cameras, we should be careful to work with a shared definition. As far as IMAQ is concerned, it needs to match a vision protocol of some sort. The camera being used here is a CMOS sensor by that definition. This is why the acquisition card is just an analog DAQ device. The drivers provided by the manufacturer are likey wrapper VIs around their dll so they can talk to the device that way. We shouldn't focus much on the idea of acquisition as something we can change. It's most likely set.

Instead, we'll want to focus on finding a way to make things more manageable. Have you viewed the community example to stream images to TDMS files? Does that result in the same "artifacts" you're seeing now?