Description

This is meant to supersede the discussion in #1605, which contains a lot of outdated information.

In 2020, here are the pros for replacing skimage.io with imageio:

• distributing wheels is easy now
• imageio has feature parity with skimage.io. In fact, I would be surprised if 99% of our io.imread calls didn't go straight through to imageio — at least if we exclude tifffile.
• this post by @danielballan, for those that haven't seen it, gives a rough outline for implementing a single protocol for lazy image reading in Python. imageio is a natural place to implement such work, and skimage.io is at best redundant, at worst, another place for things to fall out of sync.

Things that I think need to change in imageio for us to completely drop skimage.io:

• imageio.imread does return a fancy array wrapper rather than a straight numpy array, which breaks the scikit-image API. However, this is somewhat necessary for imageio to provide metadata. Not sure where to meet on this one.
• imageio.imread only gets a single plane out of a tiff file, preferring to leave volume loading to imageio.volread. imho we should aim to be dimension-agnostic. @almarklein is this something you foresee could change? See e.g. reading array of shape (512, 512, 30) with a pathlib path returns array of shape (512, 30) #4138.

In my opinion, the existence of both skimage.io and imageio is redundant, and it makes sense to separate the two functionalities (IO vs processing/analysis) into two separate packages.

@emmanuelle argues for keeping imread. I'm ok with that but I also would contemplate removing it for 1.0.

Definition of done: All external plugins and functionality in skimage.io, other than ImageCollection, MultiImage, load_sift, load_surf, and the imageio wrappers for imread, imsave are removed.