object initalization via STXM vs detector orientation

[kahntm]

I recently took a ptycho scan near the focus.
Here a STXM-like map... the STXM signal (summed diffraction patterns as a function of position):

I tried initializing the sample using the 'stxm' option using these three lines:

• p.scans.scan00.sample = u.Param()
• p.scans.scan00.sample.model = 'stxm'
• p.scans.scan00.sample.process = None

Checking the initial dump file (...None_0000.ptyr) I noticed that there is a decently looking object amplitude, but the object phase is slightly wrong:

In the phase image, horizontal and vertical phase features have opposite signs, where they should have identical signs. Later iterations get it right, but ideally it would be right from the start.

The error as above can happen when either the vertical or the horizontal DPC map has the wrong sign.
I checked my detector orientation and it has been what it always has been.

• p.scans.scan00.data.orientation = (False, True, False)

When wrongfully setting it to (False, False, False), I get the correct looking amplitude and phase in the initial object:

But of course the later iterations result in wrong reconstructions, as the diffraction patterns are used the wrong way around.

As changing the detector orientation clearly affected the object that was created, the given orientation is taken into account and the DPC is calculated from "pre-processed" diffraction patterns.
Assuming there is nothing else funky with my installation or the NanoMAX class, the error must be in the DPC calculation.

Looking at the code in question (/core/sample.py) I see three ways of fixing this:

1. We could change stxm_analysis(s) (defined in /utils/scripts.py) to return either an inverted (in sign) dpc_row or dpc_col
2. We could keep calculating it as is and invert the sign of dpc_row or dpc_col when passing it to the phase_from_dpc funtion
3. We could account for within the phase_from_dpc function (defined in /utils/scripts.py)
4. The detector orientation needs to be accounted for the right way when calculating the DPC.
5. The STXM init option needs arguments that would allow to invert the dpc components as needed.

Before changing anything anywhere, it would be good if someone else could confirm with their data that this is a systematic error. Option 5 is the most flexible, but also the one that allows for the most errors when using it.

[kahntm]

Just confirming that for me, locally, options 1-3 work.

[kahntm]

Binning seems to be accounted for fine.
Cropping sizes that are not a power of 2 also seem fine.

Once the cropped area on the detector contains any masked pixels, the STXM object initialization does not fail, but creates nonsense object inits. That might be connected to the very high value in the "to be masked pixels" in my data.

[kahntm]

replacing all usage of "pod.diff" in /utils/scripts.py with "(pod.diff * pod.mask)" takes care of the troubles when there are masked pixels.

[pierrethibault]

Hi @kahntm, many thanks for looking into this rarely-used and thus rarely-debugged feature! My slight preference is for your suggested solution number 3. If you can also implement the pod.mask trick in the same PR that would be great.

[kahntm]

I pushed the changes described above to a new separate branch ''debug_stxm_init".

I did not yet make it a pull request, as I am still not sure if the fixing of the sign is just a thing for me or if I mess-up a working feature for everyone else.

[daurer]

Hi Maik,
Thanks for looking into this. I've managed to reproduce your issue and fix on some of the datasets from the tutorials.
The data has not been collected in-focus but the image quality is good enough for this comparison.

Here is the STXM map as calculated from the data directly:

Here initial ptypy sample model with current master branch:

And the same from the debug_stxm_init branch:

[kahntm]

Hej Benedikt,

thanks for checking. Then I can make that a PR.
I would like to keep the branch though. I would like to try implementing a different method for doing roughly the same:
See F. Witter et al. Optics Express Vol. 30, Issue 19, pp. 33652-33663 (2022)