Data Acquired with Z stack on ctASLMv2 not starting at the starting position

[JinlongL]

When acquire Z stack, the starting position of the acquisition is not the first image of the stacks, but the second image. It could be the camera starts acquiring data before the NI stage moves to the starting position. Maybe adding a wait time to the camera in the ASLM software on ctASLMv2? Not sure.

[JinlongL]

Little update, this issue only exists when image in per-Stack mode. In per-Z is normal.

[zacsimile]

Related to #473.

[AdvancedImagingUTSW]

My assumption is that a small piezo settle time needs to be added. The filter wheel in the perZ mode may provide that accidentally

[zacsimile]

With #538, this problem is now common to both per-z and per-stack. This problem persists even if the stage starting position is at z=0, which suggests it is not a problem with piezo settling time. Also tried setting all wait_until_done flags to True and the problem persists.

To describe the problem in greater detail, here is a series of images where, left to right, we are at the start of the z-stack, the end of the z-stack, and the second frame in the z-stack. The first and last frames are nearly at the same position, whereas the second frame is the true start of the z-stack. This problem appears when watching the frames roll in, even when not saving the data. I believe this suggests we go to the wrong position in the first frame, but frames 2-final frame are all at the right positions and stepping in the right order.

[AdvancedImagingUTSW]

This problem does not occur on your microscope? If so, then I think the NI galvo device is worth looking at.

[zacsimile]

It occurs on every microscope. I think it's a minor bug in the ZStackAcquisition feature.

[zacsimile]

I take that back. It does not occur on my microscope, at least not on the mesoSPIM side. You are correct, the NI galvo device is worth looking at.

[AdvancedImagingUTSW]

I’m also curious if it occurs in subsequent acquisitions in a multi timepoint acquisition

[zacsimile]

Not sure about multiposition. It is worth noting that it only happens on the first channel in the z-stack. Might still be the ZStack feature.

[annie-xd-wang]

Could you upload the log files and a screenshot of the settings of the channels and the Zstack?

[zacsimile]

model_debug.log view_controller_debug.log

[zacsimile]

I also take it back, it probably isn't ZStack if it works on the multiscale. Could be stage-specific. Not sure why it would only show up in the first channel, however.

[zacsimile]

Same issue with multiposition.

view_controller_debug.log model_debug.log

[zacsimile]

Ok, this isn't an issue with the Tiger controller either. I'm starting to suspect this could be specific to the Galvo staeg or Sutter stage.

However, it is also worth noting this is an issue specific to stages where the focus axis can explicitly change z-position. On the setups where this works, the focusing stage can only defocus slightly at the start of acquisition, but cannot move the sample. It is possible that

self.move_stage(
            {"f_abs": self.central_focus + float(channel["defocus"])},
            wait_until_done=True,
            update_focus=False,
        )

in microscopy.py's prepare_next_channel() is to blame. Worth trying to comment it out and see if that fixes the issue.

[AdvancedImagingUTSW]

Figured I would remotely login this morning to see if I could look at the MP285. We are still pinging this thing far more often than we should (e.g., at every z stack). We are also evaluating things at far too high of a precision.

2023-07-23 07:19:12,616 - model - DEBUG - common_features: *** Zstack move stage: (z: -10.0), (f: 499.28000000000003)
2023-07-23 07:19:12,645 - model - DEBUG - stage_sutter: Moved MP285 to Position (XYZ):
2023-07-23 07:19:12,694 - model - DEBUG - stage_sutter: MP-285 - Position: {'y_pos': -7633.400000000001, 'x_pos': 10413.4, 'f_pos': 499.28000000000003}
2023-07-23 07:19:12,899 - model - INFO - model: ASLM Model - Running data process, get frames [3]
2023-07-23 07:19:12,900 - model - INFO - model: ASLM Model - Sent through pipe3
2023-07-23 07:19:12,968 - model - DEBUG - feature_container: running signal node: ZStackAcquisition
2023-07-23 07:19:12,969 - model - DEBUG - feature_container: running signal node: ZStackAcquisition
2023-07-23 07:19:12,969 - model - DEBUG - common_features: *** Zstack move stage: (z: -5.0), (f: 499.28000000000003)
2023-07-23 07:19:12,998 - model - DEBUG - stage_sutter: Moved MP285 to Position (XYZ):
2023-07-23 07:19:13,031 - model - DEBUG - stage_sutter: MP-285 - Position: {'y_pos': -7633.400000000001, 'x_pos': 10413.4, 'f_pos': 499.28000000000003}
2023-07-23 07:19:13,236 - model - INFO - model: ASLM Model - Running data process, get frames [4]
2023-07-23 07:19:13,237 - model - INFO - model: ASLM Model - Sent through pipe4
2023-07-23 07:19:13,305 - model - DEBUG - feature_container: running signal node: ZStackAcquisition
2023-07-23 07:19:13,306 - model - DEBUG - feature_container: running signal node: ZStackAcquisition
2023-07-23 07:19:13,306 - model - DEBUG - common_features: *** Zstack move stage: (z: 0.0), (f: 499.28000000000003)
2023-07-23 07:19:13,334 - model - DEBUG - stage_sutter: Moved MP285 to Position (XYZ):
2023-07-23 07:19:13,382 - model - DEBUG - stage_sutter: MP-285 - Position: {'y_pos': -7633.400000000001, 'x_pos': 10413.4, 'f_pos': 499.28000000000003}
2023-07-23 07:19:13,587 - model - INFO - model: ASLM Model - Running data process, get frames [5]
2023-07-23 07:19:13,587 - model - INFO - model: ASLM Model - Sent through pipe5
2023-07-23 07:19:13,657 - model - DEBUG - feature_container: running signal node: ZStackAcquisition
2023-07-23 07:19:13,658 - model - DEBUG - feature_container: running signal node: ZStackAcquisition
2023-07-23 07:19:13,658 - model - DEBUG - common_features: *** Zstack move stage: (z: 5.0), (f: 499.28000000000003)
2023-07-23 07:19:13,686 - model - DEBUG - stage_sutter: Moved MP285 to Position (XYZ):
2023-07-23 07:19:13,734 - model - DEBUG - stage_sutter: MP-285 - Position: {'y_pos': -7633.400000000001, 'x_pos': 10413.4, 'f_pos': 499.28000000000003}

And strangely, when I try to print self.stage_x_pos, self.stage_y_pos, and self.stage_z_pos to the logging.debug file, I get a TypeError...

[AdvancedImagingUTSW]

I'll make a push shortly. During the acquisition for testing purposes, I noticed that there were far more images than I initially expected. I was initially concerned that maybe the change I made was causing some higher order logic to go wrong. But again, the multi-position thing keeps popping up. It is not selected, yet it is operating in a multi position mode.

I implemented some basic logic into the MP285 to make sure that we do not tell the stage to move, unless the move is greater than some threshold. The threshold chosen arbitrarily was 200 nm. It is specific to this class, and the MP285 should never be used to acquire image slices for a z-stack, which is the only time we would have a step that size.

Side-effect: Much faster since we are not pinging the stage at every z-slice, and this could help us avoid the stupid scrambled screen if it arises from too many pings.

[zacsimile]

The multiposition fix is in #537. Unfortunately, I didn't port it to the #541 branch.

[AdvancedImagingUTSW]

That's great, just wanted to log it in case it hadn't been addressed. Can't keep up these days...

Had a moment to look into the disk space/image size estimate. Off by factor of 8 :)

[zacsimile]

Ah, that will do it. My bad.

[AdvancedImagingUTSW]

I was thinking about this on my bike ride in the relentless heat. It does make sense that the NI card will be sitting at whatever the last voltage is, if it is not updated.

Started looking into the stage galvo device, and the debug file seems to be throwing an error:

2023-07-23 15:23:01,889 - model - DEBUG - feature_container: running signal node: ZStackAcquisition
2023-07-23 15:23:01,889 - model - DEBUG - common_features: *** Zstack move stage: (z: -15.0), (f: 499.28000000000003)
2023-07-23 15:23:01,889 - model - DEBUG - model: *** stage move failed: not all arguments converted during string formatting

The pos_dict being passed to the stage is not correct, which is located in common_features:


pos_dict = dict(
    map(
        lambda ax: (
            f"{ax}_abs",
            self.positions[self.current_position_idx][ax],
        ),
        ["x", "y", "theta"],
    )
)
self.model.move_stage(pos_dict, wait_until_done=True)

self.model.logger.debug(f"*** ZStack move stage: {pos_dict}")

[AdvancedImagingUTSW]

Okay, I think the pos_dict thing is a false lead. It's just the wrong pos_dict for the piezo since that is z, and what is being passed to it is f, x, y...

However, there is another lead worth looking into. I think this stage is supposed to be 0-10V analog input, and we may be trying to send it something below its minimum?

https://www.piezosystem.com/product/30dv300/

Baby crying. This is hard.

[zacsimile]

Commented out the focusing code in prepare_next_acquistion() and the problem persists. Moving onto the GalvoNIStage check.

[zacsimile]

GalvoNIStage has a calculate_waveforms() call in microscope.py's calculate_all_waveforms(). This is probably necessary for Bingying's stage. However, in our case, for z-stacking, we want to let it use the normal move_stage() approach where we're only outputting DC values. This is what it does for all z-movements within z-stack. However, at the beginning of the acquisition (prepare_acqusition()) it creates a one-off remote_focus_ramp().

[AdvancedImagingUTSW]

That’s a smoking gun…. Nice find

[zacsimile]

Fixed in #541.

[AdvancedImagingUTSW]

I still think a piezo settle time prior to the first image in a stack would be a good idea. If we are at z=100, then start a stack from z=0-100, for example, the sample still shakes.

[zacsimile]

This one is tricky, because the piezo is controlled in the same way as the GalvoNIStage right now. The GalvoNIStage definitely cannot have a settling time by default in between voltages, or this will make Bingying's acquisitions slow. My current thinking is either we add an optional settling time in the configuration.yaml or experiment.yml or we make a different class, which includes a settling time, for voltage-controlled piezos. In the meantime, moving to z=0 prior to starting the acquisition works to get rid of the first frame's shake.

[AdvancedImagingUTSW]

Yeah, I was only advocating for a settling time between stacks, not slices. A separate piezo class could make sense given the large differences in speed

[zacsimile]

We have a settling time in between stacks (StackPause), but I think this won't quite solve the issue. What could solve this is a wait time only after the first z-movement. However, this pre-supposes the remaining steps are all small enough to not require a settling time. There is no guarantee of this. The settling time I think needs to be a property of the piezo device, so that any large change in voltage is accounted for.