ANN: imageio v1.0

[Almar Klein]

> 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 at gmail.com
> <mailto:almar.klein at 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 at __googlegroups.com
>     <mailto:scikit-image%2Bunsubscribe at 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 at googlegroups.com
> <mailto:scikit-image+unsubscribe at googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.