Wavefront calibration fit & correct the center of the spots array

[KaizhaoWang]

Hi,

Got two questions and one potential bug.

In the file slmsuite/holography/algorithms.py, under subclass SpotHologram, function refine_offsets(), line 2999. It seems that self.measure() function will not return anything. Thus, maybe it is intended to have something like the following.

if img is None:
    self.measure(basis="ij")
    img = self.img_ij

The first question is related to this function. The current spot array I have generated with camera feedback is not perfectly aligned to the intented grids (also seems to be the case in the doc example). I am wondering whether there is an easy way to use this refine_offsets() function within the feedback optimization to improve the precision of the location.

The second question is about the wavefront calibration. Since the camera is used as the measurement in the calibration process rather than a point detector, it seems to me that only one capture of the image would be enough to fit a sine curve and extract the phase at the the target pixel. I am just curious whether there are some reasons preventing us from doing that, or there are some advantages of stepping the phase.

Thanks in advance!

Kaizhao

[ichristen]

Thanks for finding this bug! Fixed in a977cfc.

• To your first question, I usually optimize the hologram using WGS with "computational_spot" for a few (~10) iterations such that the hologram is converged enough along the desired $k$-vectors. Then I refine_offsets() and repeat the process for a few (usually ~3) times. This is a very fast process because "computational_spot" is all internal optimization and doesn't need to wait for the hardware to respond. Then after I'm happy with the refinement, I do "experimental_spot" or "external_spot" to hone the uniformity at the corrected positions. If you want to minimize the number of calls to optimize, the suggested way to do this internally would be to feed in a callback like:

def refine_callback(hologram):
    if hologram.iter % 10 == 9:
        hologram.refine_offset()

hologram.optimize(..., callback=refine_callback)

• Your second question is on-point. @cpanuski will be interested. We've had discussions for a while regarding using much more of the camera data (currently, the wavefront_calibration() only uses one pixel, which is honestly really bad). I think a concern was with edge-cases where you're imaging on top of some feature which distorts the pattern, and/or issues with the alignment of the target and reference beams on top of each other. That said, I think this is definitely worth implementing. We even had code for fitting a 2D sinc at one point but I don't know where this went to. I'm adding a TODO list and the enhancement label to this Issue because I think implementing this suggestion will make wavefront_calibration() much better and faster.

• Reimplement 2D sinc with a sinusoidal phase function.

• Use this inside wavefront_calibration() as an option. Maybe trigger this option via phase_steps=None or something to minimize new variables and fit the theme of the package in repurposing variables with None.

• Debug.

• Figure out what to do with superpixels near the reference superpixel.

[ichristen]

Okay, did a first pass in f0e172b. Maybe will debug this week on hardware.

One major issue that I'm recalling: superpixels near the reference superpixel will not have many fringes visible on the 2D sinc (depending on parameters, etc). This is potentially breaking for these superpixels. Maybe can have a fallback or clever movement of the reference superpixel. This is not an issue if you maintain the sinc2D center at the interference point. Thus, you look for the shift in the blob due to the new sine term.

[KaizhaoWang]

Thanks for the fast reply, and super efficient implementation. I can also try the new function on my setup sometime this week. One small thing is that in the wavefront calibration function, a background and a reference mode image are taken for every super-pixels, which I assume might be possible to be moved out of the loop. Also the background image doesn't seem to be used anywhere in the later code. Maybe the intention was to substract that from the other measurement?

[ichristen]

Hi KaizhaoWang

Thanks again for this feedback!

The reference mode image is important for systems with unstable laser power. Without consistent normalization, one gets bad results for the amplitude calibration. Maybe we could add a flag for this, but I think it's important to keep on no matter what because the user may not anticipate instability.

The background image is a good point, esp. as it isn't used. I think the intent for that was to handle systems with bad scatter/etc, but you're right that it isn't used. This should be optional.

• Add a flag to enable taking the background and implementing background processing.