Open benjaminhwilliams opened 4 years ago
DXTBX is separately broken for support of files numbered zero (cctbx/dxtbx#186), so these files will still be ignored and dropped from the DIALS spotfinding and integration routines, but at least this PR means screen19 doesn't throw a separate error.
To be clear, the scope of this PR is to prevent
screen19
from failing if given foo_0000.cbf ... foo0009.cbf however it will still fail in the underlying code, however our end user could then say foo####.cbf:1:9 which would take frames 1...9 and then work.
With these changes, screen19 will be able to ingest the input as you describe. That is limit of these changes.
It will not then fail in the underlying code. DIALS spotfinding and integration simply drop the problematic first image, which they try to label with index [-1]
, and continue to process the rest. I agree that a warning message would be desirable but I don't think screen19 is the place to raise it. I would suggest that since the image indexing problem exists in DXTBX, rather than in screen19, and since it doesn't prevent the user getting a meaningful restult from screen19, the warning message about an ignored first image should be produced by DXTBX. The logging mechanism would then ensure that the user of screen19 saw the message (subject to choice of logging level) and the warning could be removed from DXTBX in the future when there is a fix for cctbx/dxtbx#186.
image_0000.cbf
,image_####.cbf:0:9
, or similar.