For some schedulers, setting PIMS image reader's `.class_priority` is ineffective in controlling `dask-image.imread()`
See original GitHub issuecc: @jmdelahanty
Hi dask-image developers!
Normally an end-user may control which reader pims.open()
uses to load images by simply increasing the .class_priority
attribute of their preferred pims
reader prior to calling pims.open()
. See this link.
pims.ImageIOReader.class_priority = 100 # we set this very high in order to force pims.open() to use this reader
rgb_frames = pims.open('/path/to/video/file.mpg') # uses ImageIOReader
Since dask-image.imread()
uses pims.open()
, it would be great if it could mirror such functionality too.
pims.ImageIOReader.class_priority = 100 # we set this very high in order to force dask's imread() to use this reader [via pims.open()]
rgb_frames = dask_image.imread.imread('/path/to/video/file.mpg') # uses ImageIOReader
And indeed this functionality does work for dask-image.imread()
in single-machine schedulers, like “threading” and “sync”. But I do not know of a way to make all processes, in a multi-process scheduler, for example, aware of the preferred reader’s increased .class_priority
. Any help here would be greatly appreciated.
Alternatively, it might be an idea to modify dask-image.imread()
to receive a “reader” keyword argument which indicates the end-user’s preferred PIMS reader.
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:15 (3 by maintainers)
Top GitHub Comments
Many thanks @jakirkham !
I followed your first suggestion since that was the easiest one to understand (as you guessed 😄). And it works (see the following code-snippet)!
I suppose a PR that helps the end-user avoid getting his/her hands dirty with the innards of multi-process scheduler technology would be a good idea.
But before that, perhaps I should try
dask.distributed
…Initializer customization added in PR ( https://github.com/dask/dask/pull/9087 ), which should be in the next Dask release