I'm not certain how we should handle this, but I think we should probably be logging the full exception at the debug level.

The unusual-but-acceptable scenario is when we have a file format that is usually well-supported by a particular library (e.g. .ndpi and OpenSlide), but has some characteristic (e.g. compression type) that means that it only works with another library (e.g. Bio-Formats). We don't have a way to determine that in advance, but the user shouldn't be concerned if we had to fall back to our second-choice reader.

Another possibility is that we have an image where we don't really have enough information to know whether or not it is supported without letting a library or two 'have a go' (e.g. a URI).

I think that's why the current behavior is as it is, but I do agree we need to change something because it's too hard/not possible to get exceptions sometimes when we need them.

One (admittedly weird-feeling) option: log at the debug level within the loop, while keeping the exceptions, e.g. with

Map<UriImageSupport<T>, Exception> exceptions = new LinkedHashMap<>();

so that if no support succeeded we can explain that at warn or error level.

If you strongly feel this PR is better, we can use it and look out to see how often the warnings appear.

Yeah that alternative sounds good. I did consider that in usual use a server not working may be fine, but then imo the warning should be at debug level anyway. However we do need some way to propagate errors when it's needed (as you point out, when nothing works).

I'll close this and implement the alternative proposal unless you wish to do it