surfacing issues during `determine_reader` and `is_supported_image`

[tlambert03]

Use Case

In working on napari-aicsimageio (really want the experience of loading any potentially AICSImageIO-supported image to be smooth there) I came across this situation that would be impossible for any user to understand:

If you call AICSImage.determine_reader(path) (as napari-aicsimageio does) on some bioformats file in a pip environment where openjdk is not installed... then what you see is this:

In [7]: rdr = AICSImage.determine_reader('/Users/talley/Downloads/coupe shg stack_0001.oir')
...

UnsupportedFileFormatError: AICSImage does not support the image:
 '/Users/talley/Downloads/coupe shg stack_0001.oir'. File extension suggests 
format: 'oir'. Install extra format dependency with: `pip install bioformats_jar`. 
See all known format extensions and their extra install name with
 `aicsimageio.formats.FORMAT_IMPLEMENTATIONS`. If the extra dependency 
is already installed this error may have raised because the file is corrupt or 
similar issue. For potentially more information and to help debug, try loading 
the file directly with the desired file format reader instead of with the 
AICSImage object.

of course, if you follow the instructions, you do see the actually useful message:

In [10]: im = BioformatsReader('/Users/talley/Downloads/coupe shg stack_0001.oir')

RuntimeError:
BioformatsReader requires a java executable to be available
in your environment. If you are using conda, you can install
with `conda install -c conda-forge scyjava`.

Note: you may need to reactivate your conda environment after
installing opendjk. If you still have this error, try:

# mac and linux:
export JAVA_HOME=$CONDA_PREFIX

# windows:
set JAVA_HOME=%CONDA_PREFIX%\Library

Even just in a pure aicsimageio scenario (outside of the napari-aicsimageio context) it would be nice to somehow surface a reason for why an image isn't supported (rather than a simple boolean). Perhaps is_supported_image could return a bool or a string with an exception that could be injected into the error message?

[tlambert03]

as a side thought for when we are in the context of napari-aicsimageio, we run into an issue where both aicsimageio and napari are trying to catch as many errors as possible so as remain "maximally compatible" or something :joy:. it makes perfect sense, but there's just so many layers between the actual exception that the user needs to know about, and the message that makes it to them.

it would probably be very handy if AICSImage .determine_reader was broken into a couple smaller methods that napari-aicsimageio could use more directly. For example: the multiple loops of for format_ext, readers in FORMAT_IMPLEMENTATIONS.items(): in determine_ reader could be broken into an AICSImage.iter_reader_candidates(path) method. Then napari-aicsimageio could use that a bit more directly and possibly just raise an exception (if Reader.is_supported_image() was also extended to be allowed to give more information)

[evamaxfield]

In working on napari-aicsimageio (really want the experience of loading any potentially AICSImageIO-supported image to be smooth there)

Wholeheartedly agree.

Perhaps is_supported_image could return a bool or a string with an exception that could be injected into the error message?

Ohhhh I like this idea!

as a side thought for when we are in the context of napari-aicsimageio, we run into an issue where both aicsimageio and napari are trying to catch as many errors as possible so as remain "maximally compatible" or something 😂. it makes perfect sense, but there's just so many layers between the actual exception that the user needs to know about, and the message that makes it to them.

I was thinking about this recently with the recent Twitter reported / image.sc reported / napari GH issue follow up about FileIO. It would be nice if I could launch napari with --debug or something and all the log.debug outputs are shown. If that is already possible then ignore this comment.

it would probably be very handy if AICSImage .determine_reader was broken into a couple smaller methods that napari-aicsimageio could use more directly. For example: the multiple loops of for format_ext, readers in FORMAT_IMPLEMENTATIONS.items(): in determine_ reader could be broken into an AICSImage.iter_reader_candidates(path) method. Then napari-aicsimageio could use that a bit more directly and possibly just raise an exception (if Reader.is_supported_image() was also extended to be allowed to give more information)

Fully agree again and I will say we already sorta started to do this on the 5.0 work. I wanted a "dry-run determine reader" + "show all possible readers" + "show me the default reader" functions and more.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tlambert03]

I think this is still pretty relevant. Stale perhaps due to lack of implementation, but still relevant

[SeanDuHare]

@tlambert03 @toloudis @evamaxfield As a preface, I'm not super familiar with how napari & AICSImageIO interact. How do we think this should play out in the new bioio world?

Breaking down / translating some of the features proposed by Eva as individual items here are my thoughts:

• "show all possible readers" - This seems like the existing bioio.plugins.dump_plugins() or bioio.plugins.get_plugins() here
• "dry-run determine reader" - This seems like it'll ideally be less confusing since you can control which plugins are available via your environment, but there is still a BioImage.determine_plugin() method here. As it goes through readers it will log at a warning level the exception that prevented it from being used until it finds one that works. Is there any more information we need to provide in there?
• "show me the default reader" - I think this is the same as BioImage.determine_plugin(), but the "default" gives me pause, perhaps I am misinterpreting this.

[SeanDuHare]

Moving this issue over to bioio.

aicsimageio is moving into "maintenance" mode where only easy to implement bugfixes deemed critical (or community contributed) work will be done in aicsimageio. Instead of aicsimageio, we are creating a package soon to be released called bioio and plugins like the one aforementioned. See the reason for this change here.