[FR] Add a per-call `channels` argument to `read_region`

[erikogabrielsson]

Hi and thanks for your work on this library.

In the python api, channel selection is only available via set_visible_channels(), which mutates per-reader state (visible_channels_). Since every read does request.channel_indices = visible_channels_ (slide_reader.cpp:178, slide_image.cpp:59), there's no way to read different optical paths/channels from a single FastSlide handle in a thread-safe way — two threads selecting different channels race on visible_channels_. The only thread-safe workarounds are to block optical path changes while reading or opening a separate FastSlide object per channel to read.

Is there a reason for channel selection to be different the focal plane selection? I.e. why is one in the read_region call and the other not?

[jonasteuwen]

That’s indeed not a thread-safe approach (also only partially implemented and not well-tested) and was intended to serve as a means to select channels in mIF in web applications. What’s your use case? What would the ideal API look like to you? We could have the Python API read_region[channels]

[erikogabrielsson]

Hi @jonasteuwen

I'm looking into adding fastslide as a source for wsidicomizer, primarily as a compliment to openslide. Primary access pattern is then to read tiles in an approximately the DICOM order (optical path, focal plane, row, column) using parallel threads. As optical path is the slowest changing index, it would not hurt terribly to have a blocking wait. But it would be cleaner if one could do it directly in read_region().

[jonasteuwen]

@erikogabrielsson Right now, a ReadRegion/read_region immediately materializes the array, I could change that to once it's accessed (keeps the API stable too). That way you could select channels on the region itself. That would avoid having extra parameters in the read_region and allows syntax such as region = slide.read_region((x, y), level, (h, w))[1::-1].

Would that satisfy the requirements? If we do this well, we can also make sure the data down the pipeline isn't materialized either - as far as this is possible -.

[erikogabrielsson]

@jonasteuwen That would work for me!

[jonasteuwen]

@erikogabrielsson Can you explain a bit more the use case why you want to do this? For mIF imaging it makes sense, but for RGB the internal data structure stores it intertwined so subselecting a channel is not efficient. So it would be the same as subselecting a channel yourself after reading.

[erikogabrielsson]

I do not ask for sub-selecting RGB-components, but to select different channels representing optical paths (e.g. fluorescent channels).

[jonasteuwen]

Ah - perfect, that can be done.