Thanks for the announcement! Can you expand on how you see the
eco-system of scikit-image, imread and imageio interacting?
Since imageio has a pretty good plugin system, it could be a good place to implement io for all the weird scientific file formats that exist. Next to imread(), volread(), etc. imageio also provides the read() function, which returns a reader object specific to the plugin. This reader object can have additional methods and may yield other data then just 2D/3D numpy arrays if this makes sense for the format.
So I suppose I am hoping for skimage devs to embrace imageio and help move it further.
With that, I suppose skimage could focus on the processing rather than the io, since ideally, we'd have one library for processing images, and one for reading/saving images.
<rant>
Developers tend to have a fear for dependencies. I understand this, and I try to minimize dependencies myself, but reading/writing images is a task that warrants a standalone package IMO. It troubles me a bit that different libraries are each rolling their own image io functionalities.
</rant>
As for the imread package: Zach and I considered it when discussing plans for imageio, but imread is based on C++, which is harder to maintain and makes it a harder dependency. imageio is pure Python with ctypes bindings to some libs that are auto-downloaded.
- Almar
PS: some fancy stuff that imageio can do which might be interesting for skimage users: stream images from webcam, export visualizations to animated gif or mp4.
--
You received this message because you are subscribed to the Google Groups "scikit-image" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.