File type piracy

[rsrock]

(Not sure if that's the best title for this issue)

In tracking down a recent test failure in QuartzImageIO here, it finally dawned on me that the test image was now being assigned color channels (and an extra dimension). The reason is that FileIO is using OMETIFF for this particular file.

This is a fun error, because the mere existence of the OMETIFF.jl package broke that test, even though it wasn't being used in my package at all.

To be clear, I'm not upset about this at all-- @tlnagy's OMETIFF.jl is great, because I happen to use .ome.tiffs all the time. That fact probably helped me track down this problem quickly. But we may want to figure out how to prevent this in the future.

[tlnagy]

Yeah, this is an unfortunate side effect of the way FileIO is designed, which makes it difficult to call the more general loader if a more specific loader exists for a given type. I thought this might've been #160 resurfacing, but the file in that test is an .ome file. The only solution that I can think of right now is to make it easier to specify which loader to use or perhaps attempting to use already loaded loaders first.

As a stopgap, it should be possible to force opening with QuartzImageIO. E.g. I switch between the two different loaders in the OMETIFF tests here:
https://github.com/tlnagy/OMETIFF.jl/blob/10586a0156300f4ac3c09549df18160a6efbce65/test/runtests.jl#L89-L96

[rsrock]

Yep, that's exactly the sort of thing I'm doing now. Thanks!

[johnnychen94]

This issue only affects the backend writer and should only happen when tested locally because OMETIFF exists in your root project. In a CI environment, you generally won't have unrelated backends installed so it would not be affected.

As #172 (comment) is suggested, this can be easily worked around by calling the specific loader.

This issue also occurs when the backend writer somehow triggers a recursive call "incorrectly" to FileIO.load/FileIO.save. For example,

# in MIDI.jl
@deprecate writeMIDIFile(filename::AbstractString, data::MIDIFile) FileIO.save(filename, data)

The problem with this @deprecation is that if FileIO.save has another higher priority backend (say BetterMIDI) for this midi format, then it would be very likely to be redirected to BetterMIDI.save implementation. See JuliaMusic/MIDI.jl#140 (comment) for more explanation.