Support pathlib Path input in dask_image.imread.imread()

[GenevieveBuckley]

It would be good if we supported pathlib Path inputs into the dask-image imread() function. I don't think it should be too complicated to add, so this could be a good first issue for contributors to dask-image.

[martindurant]

If dask-image uses fsspec.open_files, then you could achieve this easily by calling stringify_path in the first line of open_files

[martindurant]

(feel free to use stringify_path even if you don't otherwise depend on fsspec, of course :) )

[tlambert03]

there's also os.fspath ... but that's probably not worth dropping support for py3.5? :)

[martindurant]

os.fspath is almost identical to isinstance(urlpath, Path); then again, pathlib only appeared in py34.

Does dask-image support remote reading at all?

[GenevieveBuckley]

Hi @martindurant, dask-image does not use fsspec, we use pims. I do like stringify_path though, thanks for mentioning it!

Currently there isn't support for remote reading of files in dask-image. Pims does have support for remotely reading data via pims.ImageSequence(), but the more generalized pims.open() (which dask-image uses) does not share the same support. You can read a discussion about this at soft-matter/pims#310 and the work John did towards a solution at soft-matter/pims#316.

[martindurant]

cc @danielballan , who worked on PIMS and we talked about this a little.
(@jakirkham , you are also maybe interested in this)

[jakirkham]

Supporting pathlib seems sensible.

FWIW Dan started working on a prototype for PIMS 2. Maybe these would be good suggestions for that prototype? Dask-image really relies on other libraries to do the heavy lifting (and doesn't try to get too involved itself).

[GenevieveBuckley]

FWIW Dan started working on a prototype for PIMS 2. Maybe these would be good suggestions for that prototype?

Ok, done

Dask-image really relies on other libraries to do the heavy lifting (and doesn't try to get too involved itself).

When I say "support" from dask-image, I think that should just mean try coercing any Paths to strings for convenience, at least as long as we're calling out to a library that only accepts strings.

[jakirkham]

Yeah that’s what I figured you meant by support as well. That’s what I was trying to respond to in the first line. So yeah let’s support pathlib.

Was trying to say more involved solutions are probably something we want to handle in a proper image reading library.

[GenevieveBuckley]

One thing to double check when working on this is whether we currently support passing lists of filenames, as well as just a single string. (I can't remember if this is true or not). If it is true, the solution to this issue will also need to work in that situation as well.