What I'm looking for in an IO package is proper treatment of less-common data types that are nonetheless common in scientific imaging, such as uint16 and 3D tiffs. (Prior to Steven's PRs, skimage did a poor job with those.) Can you comment on that?

Imageio supports TIFF through the freeimage plugin, but this is more the common kind of TIFF, and probably not sufficient for scientific TIFF formats. It will need some testing to see what is supported and what not. The best approach would probably be to refactor existing code that can deal with such Tiffs into an imageio plugin. There's C. Gohlke's tifffile, tiffany, pylibtif. I am not familiar enough with TIFF to say which of these sufficiently covers scientists needs (if any). But if either of them is good enough, it should be relatively easy to include it in imageio. - Almar

Thanks for the post, and for the library! — I think it will lead to good places. =)

Juan.

On Fri, Nov 14, 2014 at 9:40 AM, Almar Klein <almar.klein@gmail.com <mailto:almar.klein@gmail.com>> wrote:

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 <mailto:scikit-image%2Bunsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/d/__optout <https://groups.google.com/d/optout>.

-- 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 <mailto:scikit-image+unsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/d/optout.