Closed phonghnguyen closed 1 year ago
The underlying reason probably has to do with how skimage.transform.warp_polar chooses default radius for non-square images.
The fix seems relatively straightforward: the radius for integration should be implicitly fed to skimage.transform.warp_polar. In the example notebook (in the zipped file), I load the included data into an xarray and integrate it in the same way as integrateSingleImage is implemented in WPIntegrator. This returns the result as above, but by including the radius to be the same as the longest dimension of the original image, the issue seems to be fixed. This fix appears to be general and should be compatible with other workflows that use WPIntegrator. This fix seems to be incorporated in my pull request with the latest push to the fork main branch. #73
I believe this is fixed in #73 and this issue can be closed, but major PyHyper-cyrsoxs users such as @pdudenas and @delongchamp should take a look at the change and feel free to reopen if this unexpectedly breaks something in your workflow.
There are cases where integrating with WPIntegator will output cropped results for non-square images.
Attached plots show the qx, qy image where the peak is near q = 0.4; however, WPIntegrator outputs a chi, q image with the same peak near q = 0.6.
This seems to be due to the returned data array having been cropped so the generated q axis does not match the source image qx, qy axes