Clarify lab coordinates system

[pierrethibault]

Should be added in documentation.

[alexbjorling]

Yes, I'm trying to understand this now (doing a first attempt at reconstructing our first ptycho scan here...) and am confused. Until this gets documented, are there any pointers to how this info can be found without going deep into the code?

[bjoernenders]

To some extent, these are "natural" coordinates. So z runs positiv in the direction of the beam, while x and y run positive with the index of all 2d arrays. In your (N,2)-array of positions, the first position refers to the row and the second to the column in the object array. If you coordinate system has 'x' associated with horizontal movement and the camera has its row-readout in parallel with horizontal direction, then the positions are sorted [(y_0,x_0),(y_1,x_1),...etc ]. The direction of the shift is counted as observed in the object frame, which means, that if you needed to move negative with your sample motor driver to get from the sample edge to the center, you will need to count this as a positive shift. If you moved the illumination, (like a zone plate) you are fine. The last step is to determine whether or not the rows and columns of your detector count upwards with positive x and y in this lab system. If not, consider flipping the respective switch in the 'orientation' parameter of PtyScan (it eventually calls u.switch_orientation). In practice, it usually suffices to guess the orientation with the 8 possible options of 'switch_orientation'.

[alexbjorling]

Thanks, this helps a lot.

[alexbjorling]

Since this issue is still open, I'll have another go at this. So we've been happily ptychographing for four years, but now @kahntm is pointing out that

1. We need to give the near field propagator negative numbers to propagate downstream,
2. our phase differences between air and 500nm Ta have the wrong sign. and
3. viewing the reconstructed object as numpy array, it is flipped (horizontally at least, vertically I don't know).

So something is wrong, as if we've flipped the lab frame and the detector images. But I can't see that we have! Seeing as Storages always have top-left origins (scaled by positive numbers and shifted), the object viewed along the beam is oriented like this.

o ----->  x
|
|
v  y

Our sample motors have their axes as follows, viewed in the same way.

      ^ y
      |
x     |
<-----o

So naturally, I've been supplying the positions as follows in our PtyScan subclasses.

positions = - np.vstack((y, x)).T * 1e-6

Since the detector frames (from our Pilatus or Eiger, the Merlin is different) are also indexed like numpy arrays, we just supply them as-written with no further operations.

p.scans.scan00.data.orientation = None

So at the end I think I've followed @bjoernenders's description from 2016 above. Still, Maik's observations are true. Is there some convention which I'm not taking into account or am misunderstanding?

edit: tagging in some knowledgeable people @aaron-parsons @pierrethibault @daurer

[bjoernenders]

Hi @alexbjorling and @kahntm ,

Sorry for not getting back to you earlier. Feel free to poke me if I don't respond snappy enough.

1. The nearfield propagator can deal with negative arguments, but for some inexplicable reason we put in a lowerlimit of 0, which is pretty stupid. So that limits need to be removed.
2. Have you checked what our sample.py module produces for 500nm Ta?
3. This always a confusing bit. I was quite certain though that I covered all possible options. If you get your orientations wrong the thing that usually happens is that the reconstruction goes up in smoke. If you can see a good reconstruction, it means that the you have at least internal consistency. I'm not so concerned that the reconstruction is flipped as long as its accurate. But as you provide negative positions to comply with ptypy's geometry model it might appear flipped to what you are used to for monitors that display in line with your motor system. Would you mind providing an image of the reconstruction and the reference?

Last but not least there is the issue that defocused geometry often let's you reconstruct at both positive or negative defocus with one of your images flipped vs the other. For example, if you had a negative defocus but can only provide positive defocus to the propagator it might turn flip the image around to comply. It could also be the reason for the reversed sign of you Ta.

I have a weekly meeting with @daurer to discuss ptypy. I happily add you to the event and you can drop in to discuss this further.