[Bug] Overlapping rings in phase transfer function

[ziw-liu]

When debugging #151 I saw this overlapping pattern in the phase 3D transfer function:

# in napari
viewer.add_image(np.fft.ifftshift(np.abs(tf_zarr_group["real_potential_transfer_function"])))

Without shifting:

Is it because the parameters didn't match the example data array?

[ziw-liu]

It appears to be the same for a previous dataset: /hpc/projects/comp.micro/mantis/2023_08_09_HEK_PCNA_H2B/2-phase3D/pcna_rac1_virtual_staining_b1_redo_1/transfer-function.zarr

[talonchandler]

Thanks for finding and flagging this @ziw-liu.

The raw data is sampled out to 1/(0.15 um) = 6.66 um^{-1} so I would not expect overlap since 2NA/lambda = 2(1.35)/(0.45 um) = 6 um^{-1}. Equivalently, we're correctly Nyquist sampling the underlying signals, and I think this is a waveorder bug.

[ziw-liu]

I also discovered that I was indeed using the wrong config (0.85 NA of illumination instead of 0.52), while the problem still exists with lower NA, the overlap is smaller.

High NA:

Low NA:

[talonchandler]

Details:
I made an error in my response above. I said that the data is sampled out to 1/(0.15 um) = 6.66 um^{-1}, but this is the frequency extent. The data is actually sampled out to 1/(2*0.15 um) = 3.33 um^{-1}.

I will also refine my estimate of the transverse cutoff frequency to (NA_ill + NA_det) / lambda, which is (1.35 + 0.52)/0.45 um = 4.16 um^{-1}.

These numbers are consistent with the overlap you've observed here @ziw-liu, where the transverse cutoff frequency is about 25% larger than the data's extent. In the current waveorder implementation, this leads to wrapping behavior.

Summary and takeaways:
@ziw-liu @edyoshikun @ieivanov @mattersoflight this means that:

• the labelfree mantis arm is undersampling in the transverse direction by ~25%. It's completely up to us if this improvement is worth pursuing with an increased magnification.
• the current waveorder reconstruction has a bug that wraps the transfer functions for these undersampled datasets. This bug leads to oversuppression of the highest spatial frequencies, so I expect a (relatively small) improvement in resolution/contrast after I fix this bug.

Next steps:
@ziw-liu @edyoshikun and I chatted about a fix over lunch. I am planning to:

• begin my transfer function calculation with checks for undersampling
• if the data is undersampled, then I will compute the transfer function on a twice-as-large grid, then clip it afterwards
• this means that undersampled data will require more expensive transfer function calculations, but the transfer functions are precomputed so this is not a major issue.

[ziw-liu]

EDIT: this artifact is the result of a small (~3 degrees) rotation angle during registration.

This issue might be related to the grid artifacts we see with the binned Zyla camera, which is under-sampling by a large margin. The wrap-arounds in the phase transfer function could be enhancing the fixed pattern noise.

Edit: add a 63x example: