-
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
still_process fails spotfinding on image(s) in middle of range #1180
Comments
Debugging now.
|
This has broken handling of image sequences - maybe not adequately tested though as requires big-ish data. 230 experiments in an image sequence - with this change id == 0 for all -
should be
i.e. adding |
For the moment I have reverted the commit - will add a proper test |
@phyy-nx to explain thinking here - the spot finding works old-style on the image set then we iterate through this and assign spots to the correct experiments afterwards - this allows plenty of speed and parallelism as well as fast start up time as their is only one image set, indexed into by the scan. |
N.B. test fails with the change above:
|
Trivial reproducer of error:
=>
So we can at least look at this very easily. |
I've just had a user encounter this error again, do we have any ideas on fixing at the moment? |
Currently this fails in certain cases of running stills_process with a very unhelpful error message of "13" (see #1180)
My original fix broke grid scans and so was reverted. We also need a reproducer of that error. |
@phyy-nx reproducer included above at #1180 (comment) |
Currently this fails in certain cases of running stills_process with a very unhelpful error message of "13" (see #1180)
- `dials.scale`: Allow usage of `mode=image_group` with `filtering.method=deltacchalf` when only providing a single data set (#1334) - `dials.import`: When using a template and specifying an image_range, missing images outside of the range will not cause a failure (#1333) - `dials.stills_process`: Show better error message in specific spotfinding failure case (#1180)
…rocess to work with scans Fixes #1180
Just wanted to note, working with @mewall I added a commit to the lunus_stills_process branch that fixes this issue in kind of a kludgy way. Comments invited on commit c570d44. Specifically, @graeme-winter, can you verify that grid scan processing is not borked on the lunus_stills_process branch? |
The test @graeme-winter added to prevent regression of grid scan spotfinding
Further, the example dataset above (#1180 (comment)) also works using commit c570d44. Command I used which indexed a couple images (didn't try and optimize it):
I'd like to cherry pick that commit into a new PR, but I'd like some review here first. I imagine the flag I added might be better served as a phil parameter set by default on dials.stills_process. @graeme-winter? Thanks! |
Kinda kludgy is true, peppering with |
…rocess to work with scans Fixes #1180
…rocess to work with scans (#1508) * Add is_stills parameter to the spotfinder API to allow dials.stills_process to work with scans Fixes #1180 * Add test for pseudo scan in stills_process * run test using procrunner * Add docstring entries for is_stills * Add news Co-authored-by: Markus Gerstel <markus.gerstel@diamond.ac.uk> Co-authored-by: Nicholas Devenish <ndevenish@gmail.com>
…rocess to work with scans (#1508) * Add is_stills parameter to the spotfinder API to allow dials.stills_process to work with scans Fixes #1180 * Add test for pseudo scan in stills_process * run test using procrunner * Add docstring entries for is_stills * Add news Co-authored-by: Markus Gerstel <markus.gerstel@diamond.ac.uk> Co-authored-by: Nicholas Devenish <ndevenish@gmail.com>
Using https://zenodo.org/record/55058 as a test data set:
However, normal dials import works:
The text was updated successfully, but these errors were encountered: