Blazing orientation + wavefront correction

[LeoKonzett]

Hello,

I have a one question and a possible bug:

1. This example in the docs uses a blazing vector of vector = (.002, .002). The spot is displaced in the lower left corner. I'm a bit confused about this: What's the coordinate axes orientation of the kxy grid, i.e. which corner is (+, +)? In particular, if I use e.g. blaze_vector = (.002, .002) I get a spot in the lower right corner.

2. I think the exclude_superpixels flag does not work as intended. Changing to

# Line 1096 in meth: FourierSLM.wavefront_calibrate()

            if nx < exclude_superpixels[0]:
                continue
            if nx > (NX - exclude_superpixels[0]):
                continue
            if ny < exclude_superpixels[1]:
                continue
            if ny > (NY - exclude_superpixels[1]):
                continue

should do the trick.

5. I'm asking this because my wavefront calibration (see image below) contains rather steep phase gradients. This means that when blazing the corresponding superpixels, the spot is not at its expected location but displaced. While this in itself is not a problem, I would have expected the gradients (per superpixel) to be steep at regions away from the interference point as the optical path length between the (+, +) SLM corner and the (+, +) camera corner should be smallest. Also, when recording an image with the wavefront correction mask applied, the image quality rapidly decreases away from the interference point. I am sure this is a problem with our setup and not with the algorithm, but wanted to ask if you have experienced similar issues.

I still suspect there is some issue with rotations / flips, but I cannot seem to pinpoint it.

[ichristen]

Hi @LeoKonzett ,

Thanks again for these great questions and glad to see that Fourier calibration is running, even if it isn't perfect for your setup.

1. The kxy grid is the grid of the SLM, not the grid of the camera. So there may be any number of flips and rotations causing this SLM-coordinate to appear in a different direction in camera-space.
2. Thanks for finding this bug. Fixed in 9ac3ecb.
3. This is actually working as intended. Wavefront compensation only works best around the point of calibration (though we have not seen aberration outside the point of calibration to this degree). The issue is somewhat fundamental: an SLM is more akin to a vector-vector operation than a matrix-vector operation. If you run wavefront calibration more times with different reference points, you'll probably find that the result is slightly different. This is because in your case, different corrections are needed for each point. This is what I mean by a vector-vector operation: light targeting different points is sourced from different angles in SLM $k$-space, but the pattern displayed on the SLM is imparted the same way for each $k$-vector. The behavior of a desired far-future SLM which could implement a "matrix-vector" product (at the cost of many more degrees of freedom) would be to impart different phase for each of the $k$-vectors. In this same vein, this is why people can't do arbitrary basis transformations for spatial light with only a single SLM. Sure you can turn a $HG_{10}$ into a $LG_{10}$ mode, but doing $HG_{10}$ to $LG_{10}$ at the same time as other conversions ($HG_{20}$ to $LG_{20}$, $HG_{30}$ to $LG_{30}$, ...) is a huge challenge and is an active field of research for spatial mode multiplexing (the solutions usually involve multiple SLMs or multiple bounces off of the same SLM to reach toward matrix-vector products). All that said, there are a few things that you might be able to do to fix this:

• Better alignment is better. Having the SLM precisely in the Fourier domain will generally yield better results. This includes making sure that the beam incident on the SLM is collimated. What does your setup look like? Are you using a $4f$ system?
• On one of our setups, we found wavefront calibration at different points produces different amplitude distributions. Unlike phase error across the field, amplitude error is fixable because an iris in front of the SLM can clip all patterns to the same amplitude distribution. A comment about this was tucked in a supplementary "We find that the amplitude distribution becomes significantly clipped as the reference position approaches the edge of the field of view. To compensate for this, we purposefully overclip the SLM with an iris such that the amplitude distribution is equally clipped regardless of the reference position (clipping oval from the iris is visible on the amplitude distribution pictured in Fig. S5a). This allows us to generate more accurate holograms across the region near the edge of the field of view where the input grating array is located." I don't think it will help in your case because your amplitude distribution is already small, but it might be worth seeing the differences between calibrations produced by two different reference points.
• I think you probably would be able to get better results with two SLMs (separated in $z$), but I don't think it's worth the complexity.
• We also have plans to use Zernike Polynomials to generate the best "average" phase correction to compensate for aberration. There are several groups who have contacted us with interest for such a feature, so this is becoming a priority. Let me know if you're interested in implementing this. The algorithm would involve iteratively cancelling Zernike orders.
• We have other plans to try to implement a James-Webb-type wavefront calibration, which might also work better for you.
• As a last comment, depending on what you're trying to do, you can do wavefront calibration at the point at which you want to do science, and then restrict yourself to operation inside that region. Expanding your input beam size can give you more effective resolution inside that region of low aberration.

[ichristen]

Hi Leo,

I think we have found a way to fix this issue and get diffraction-limited spots across a field of view despite aberration. Stay tuned. ETA a month or so depending on how things go. Let us know if you would be interested in helping with this!

I'm going to close this issue in the meantime.

[tpr0p]

@ichristen re-opening since it is still an active issue in slmsuite

[tpr0p]

This issue will be closed since this is a faithful execution of the current wavefront calibration algorithm as implemented. Improvements to wavefront correction will be discussed in #60