In yesterdays meeting discussed the state of and the future plans for our plugin infrastructure in skimage.io:
Plugins like fits_plugin.py, gdal_plugin.py are if at all only sparingly covered by tests and are probably outdated. There are also unused files in skimage/data like simple.fits and multi.fits.
imageio and its own plugin system seems better maintained than our own system and is probably able to replace all features of our own system.
So we would like to deprecate the plugin system entirely in favor of a convenience wrapper around imageio in the form of skimage.io.imread and skimage.io.imsave. Effectively, going forward we’d tell users
“We deal with arrays and don’t really care how you get them or store them but here are two simple convenience functions. For anything more advanced have a look at imageio.”
This could be aligned with skimage2 but I think it doesn’t have to and can probably be done just with conventional deprecation cycles.
I’m curious what others that haven’t attended the meeting think. I’ll let this stew for a bit and if no concerns are raised, we can make a PR to figure out how to get there.
So we would like to deprecate the plugin system entirely in favor of a convenience wrapper around imageio in the form of skimage.io.imread and skimage.io.imsave. Effectively, going forward we’d tell users
I have wanted to do this for a long time, and I would even get rid of the convenience wrapper altogether, but @stefanv thinks that would be too inconvenient. So a simple wrapper makes sense to me, and further plugin work can go into imageio.
one thing that becomes quickly apparent: preserving imread and imsave while deprecating the underlying plugin infrastructure is quite tricky. I’m not sure if it’s worth it. I’m curious if you think the keeping them around is worth it after looking into the PR above.
An alternative is to use skimage2 to just flat out change behavior and signatures, that might be a lot simpler.
preserving imread and imsave while deprecating the underlying plugin infrastructure is quite tricky. I’m not sure if it’s worth it.
Sorry for not yet looking at the PR , but I think the vision was to offload the plugin-ness to imageio, so imread and imsave will be small shims for imageio.v3.imread and imageio.v3.imsave. What am I missing?
I looked at the PR, and I have the same confusion. I don’t think the goal is to preserve the underlying plugin infrastructure, but to get rid of it, so I imagine almost the only thing that is left is imread, imwrite (from imageio), as well as ImageCollection and MultiImage. These may need to invoke imageio’s imread explicitly to get the required TIFF functionality.
So a simple wrapper makes sense to me, and further plugin work can go into imageio.
, but I think the vision was to offload the plugin-ness to imageio, so imread and imsave will be small shims for imageio.v3.imread and imageio.v3.imsave. What am I missing?