Allow input image files to be numbered '0'

[benjaminhwilliams]

• Allow input of the form image_0000.cbf, image_####.cbf:0:9, or similar.
• Add a test for the same.
• Allow passing py.path.local objects to Screen._import for ease of testing with the dials_data Pytest fixture.

[benjaminhwilliams]

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.

[graeme-winter]

To be clear, the scope of this PR is to prevent screen19 from failing if given foo_0000.cbf ... foo_0009.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.

Or have I got this wrong?

Reason I ask is this is the kind of information I may anticipate in a help string.

Otherwise the change set looks good 🙂

[graeme-winter]

et seq.

I am pretty sure general logic for this kind of thing already lives inside dxtbx somewhere which would support a more general range of filenames?

[benjaminhwilliams]

Possibly, I'm afraid I wouldn't know where to look.

[benjaminhwilliams]

Aha, dxtbx.model.scan_helpers.template_regex, I think this might do the trick!

[graeme-winter]

👍

[benjaminhwilliams]

To be clear, the scope of this PR is to prevent screen19 from failing if given foo_0000.cbf ... foo_0009.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.