Azimuthal integral off-by-one bugfix

[viljarjf]

---

Fixes an off-by-one error in azimuthal integration

Checklist

• implementation steps
• update the Changelog
• mark as ready for review

What does this PR do? Please describe and/or link to an open issue.
An off-by-one error meant the final row and column of the signal was ignored when transforming to polar coordinates with Diffraction2D.get_azimuthal_integral2d.
In the old code, the new test fails for all corner != (0, 0), i.e. all corners at the last row and/or column.
The new implementation calculates the extent in cartesian space of each pixel, accounting for the curvature of Ewald's sphere where applicable, and uses those for utils._azimuthal_integrations._get_factors.

The previous implementation relied on the Calibration.axes, where the final element was not included due to the off-by-one error. Furthermore, from looking at hyperspy plots with few signal pixels, the coordinates of the axes represent the centers rather than the edges of the pixels, which is now accounted for

[viljarjf]

It seems the docs failed because I assumed a UniformDataAxis, i.e. a flat ewald's sphere.
If the distance between pixels is not uniform, then I'm not entirely sure how to account for the width of the final row/column.
I believe I would have to replicate part of the code in the Calibrate.detector responsible for setting the axis.
Any thoughts, @CSSFrancis?

[coveralls]

coverage: 92.941% (-0.02%) from 92.965%
when pulling a4c87f7 on viljarjf:azimuthal-integral-off-by-one-bugfix
into b88a993 on pyxem:main.

[viljarjf]

Non-flat Ewald's sphere seems to work now, but apart from manually inspecting some plots with exaggerated pixel sizes and camera lengths I don't know how to test it...

The implementation now calculates the extent in cartesian space for each pixel, accounting for the curvature of Ewald's sphere where applicable.

[viljarjf]

Marking as draft, some unrelated tests fail now and I don't have more time today

[CSSFrancis]

Marking as draft, some unrelated tests fail now and I don't have more time today

@viljarjf Do you want me to look at this later? I can help with the failing tests and review.

[viljarjf]

@CSSFrancis If you want, sure! I believe the tests fail because I changed the way the center index was calculated in Calibration.detector, it might need to align with ElectronDiffraction2D.set_diffraction_calibration

[viljarjf]

It was the center coordinates. The pixel coordinate of np.arange(10) is at 4.5, which is rounded down to 4. This is different from the previous implementation, which used ax.size / 2, e.g. 5 instead of 4.5.

[viljarjf]

I also want to add support for the azimuthal_range-argument, which currently only affects the axis rather than the actual integration.
It would probably be nice for some usecases if you could specify to only integrate from 0 to pi, for example.
This would also ensure the polar unwrapping has a consisteltly defined 0 in the axes coordinates, which would be useful in #1018 to ensure the polar signal is aligned consistently.

I have the code ready, but it might fit better in another PR? Alternatively, I could change the subject of this PR to be more broad.

[CSSFrancis]

@viljarjf This is good, thanks for cleaning up my mistakes :)

We should also make an example showing how pixels are defined in pyxem. In this case we use the center of the pixel to determine the coordinates rather than the upper right hand corner?

[CSSFrancis]

@viljarjf I think this is good! Any chance you can look over the example I just added regarding the coordinate conventions.

[CSSFrancis]

I also want to add support for the azimuthal_range-argument, which currently only affects the axis rather than the actual integration. It would probably be nice for some usecases if you could specify to only integrate from 0 to pi, for example. This would also ensure the polar unwrapping has a consisteltly defined 0 in the axes coordinates, which would be useful in #1018 to ensure the polar signal is aligned consistently.

I have the code ready, but it might fit better in another PR? Alternatively, I could change the subject of this PR to be more broad.

Let's add that as a separate PR as this one seems good to go. If only to let you run the CI without approval :)

[CSSFrancis]

@viljarjf Do you want to update the changelog as well?