Support azimuth_range in Diffraction2d.get_azimuthal_integral2d

[viljarjf]

---

Add proper support for the azimuth_range-argument in Diffraction2d.get_azimuthal_integral2d

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.

Previously the only thing azimuth_range did was change the axis limis. Now, the argument is considered also when integrating.
I added a test to ensure only the specified range is included in the final output.
With this, the angle along the azimuthal axis is consistent for any specified range, with angle 0 pointing downwards in the image.
This is not in line with Pyxem's standards, if the angle is measured along $X_L$. Currently, the angle is measured along $-Y_L$.
This affects the new template matching code for the in-plane angle, which needs to be measured from $X_L$.
It can either be handled here, or in the template matching code specifically, as we need to convert from an index into the azimuthal axis (the current TM output) to an angle in degrees regardless.

I updated the contributors but I'm not sure where in the list I slot in..

[CSSFrancis]

@viljarjf Don't worry too much about the contributor order. It's good to add yourself as it helps us remember but we will adjust the list order once a new version is released.

[viljarjf]

I added an example to show some different options. Since it uses hs.plot.plot_images, the final plot with angles in the "wrong order" (pi to 0) has incorrect azimuthal axis ticks.
When using pol4.plot, the azimuthal positions of all features in the images are consistent across all ranges.
This inconsistency is already reported in hyperspy/hyperspy#3361

[CSSFrancis]

@viljarjf Let's align this with pyxem standards. Let's force it here, document it, and then if people want to change the limits to get what they previously did, they can do that themselves. I don't think anyone is going to get frustrated with this as long as we are fixing bugs.

[viljarjf]

When I looked into this earlier, I could not find where or how the direction of angle 0 was defined in the slicing code. As you implemented it, maybe you know @CSSFrancis? If not, we can simply subtract 90 degrees from the azimuthal range before passing it to Calibrate.get_slices_2d, with a comment describing why

[viljarjf]

What I implemented so far in this PR does not change or handle the relationship between the direction of angle 0 and cartesian space. I only ensure that the azimuth_range parameter is used both for integration limits and the signal axis limits

[CSSFrancis]

When I looked into this earlier, I could not find where or how the direction of angle 0 was defined in the slicing code. As you implemented it, maybe you know @CSSFrancis? If not, we can simply subtract 90 degrees from the azimuthal range before passing it to Calibrate.get_slices_2d, with a comment describing why

To be honest I didn't think about it too much. My work usually involves autocorrelation along theta, so the direction of 0 doesn't really matter. For orientation mapping it does and we should be consistant :)