Wavefront calibration fit & correct the center of the spots array about slmsuite HOT 4 OPEN

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.

from slmsuite.

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.

from slmsuite.

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?

from slmsuite.

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.

from slmsuite.