@lagru @stefanv did you know that dask has a function, namely dask.array.image.imread, which "defaults to skimage.io.imread?!" I just looked up where 'skimage' appears in the dask codebase: https://github.com/search?q=repo%3Adask%2Fdask%20skimage&type=code

And, I believe, because of their long-form documentation about image processing applications, the use of skimage.io has propagated, as can be seen in https://matthewrocklin.com/blog/work/2017/01/17/dask-images.

Alright, I pushed an alternative deprecation approach that keeps imread, imsave and imread_collection around but deprecates everything that has to do with the plugin infrastructure.

#7552 should be merged before this one because it is required for the test suite to pass. To see whether this PR passes I temporarily included the changes from the other PR in 70ed9c2.

Very quick glance; sorry if I missed some detail.

Are we still using tifffile as the default for loading tiffs, or is that what is transparently being used by imageio? I think that behavior is important to keep.

The deprecations look good, thanks. I didn't run this branch, but checking that imread(fn) works without deprecation, imread(fn, plugin=our_default) also without deprecation, but imread(fn, plugin=some_other_plugin) warns.

Checking: the todo says to remove all plugins, but probably requires moving imageio plugin directly into io.imread function?

Are we still using tifffile as the default for loading tiffs, or is that what is transparently being used by imageio? I think that behavior is important to keep.

Yes, I changed nothing about our plugin infrastructure besides tacking on deprecation warnings, whenever something uses a function or parameter directly related to it. As far as I'm aware, imageio defaults to tifffile if it is available. E.g. after applying the following diff

diff --git a/skimage/io/_io.py b/skimage/io/_io.py
--- a/skimage/io/_io.py	(revision 99c1e625ff02d478963e7c8f17d14b5a5631bf63)
+++ b/skimage/io/_io.py	(date 1727522910971)
@@ -76,7 +76,7 @@
 
     if plugin is None and hasattr(fname, 'lower'):
         if fname.lower().endswith(('.tiff', '.tif')):
-            plugin = 'tifffile'
+            plugin = 'imageio'
 
     with file_or_url_context(fname) as fname, _hide_plugin_deprecation_warnings():
         img = call_plugin('imread', fname, plugin=plugin, **plugin_args)

the test suite passes, except that test using **plugin_args to tifffile.imread fail because imageio doesn't use tifffile.imread under the hood. However, that's not a problem, because passing extra keyword arguments to the plugin is deprecated as well. So once we want to complete the deprecation, we should be able to replace call_plugin("imread", ...) with imageio.v3.imread and so forth.

I didn't run this branch, but checking that imread(fn) works without deprecation, imread(fn, plugin=our_default) also without deprecation, but imread(fn, plugin=some_other_plugin) warns.

I don't follow. What is the reason to keep supporting plugin=our_default? I intend to deprecate the parameter plugin fully so that passing anything, including the default, raises a deprecation warning. Not using the parameter, will use our_default internally.

Checking: the todo says to remove all plugins, but probably requires moving imageio plugin directly into io.imread function?

Yes, seeing that we have some custom code about making sure that we return an editable array in there. I'll reword the TODO slightly.

I don't follow. What is the reason to keep supporting plugin=our_default?

You're right; that's a fine route to take.

Converting to draft, since #7552 should go in before this one.

@stefanv, @jarrodmillman, are you intentionally holding of on the merge because of the release preparation?

@stefanv, @jarrodmillman, are you intentionally holding of on the merge because of the release preparation?

I was holding off to see if you had anything else you wanted to do before this was merged.

Errr. Sorry, I clicked the wrong button....

No, unless the CI picks something up last minute, this should be fine to go in. :)