-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calculate image size limits correctly for data access in dials.rs_mapper
#2364
Conversation
…xy had been calculated incorrectly
Merging this into the My current understanding is that the problem was actually in the limits passed into |
dials.rs_mapper
dials.rs_mapper
xlim, ylim = imageset.get_raw_data(0)[0].all() | ||
nfast, nslow = panel.get_image_size() | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid any further confusion, this is the critical change. The rest is just cosmetic.
Codecov Report
@@ Coverage Diff @@
## main #2364 +/- ##
==========================================
- Coverage 82.90% 82.83% -0.07%
==========================================
Files 593 593
Lines 68592 68592
Branches 9221 9221
==========================================
- Hits 56863 56817 -46
- Misses 9613 9658 +45
- Partials 2116 2117 +1 |
This was spotted during testing of #2362 with I23 data. The program would segfault,
which was eventually tracked down to the indices used to access image data being reversed from expected given their accessor.This was only noticed now, because I23 panels are highly elongated, with size (195, 2463). For previous uses with squarish single panel images it is likely that the pixels within the specified resolution limit (default 6 Å) had indices that were valid for either x or y.
The resultant output is clearly quite different. Here is a comparison of the resultant maps in Coot for the dials-data insulin dataset (
dials.data get insulin
), with the map from this branch in purple and that from main in greenIt is not merely a case of transposing one to the other, because the pixel is also rotated to a particular position around an axis with fixed orientation wrt to the image.
This may have consequences for
dials.export format=json
.I think this might need more testing to understand the issue before it is merged.