Open perlman opened 3 years ago
I thought a bit about this feature, here are some thoughts:
If there are a large number of channels, it may be desirable to only download the channels actually required by the shader. But that would require some way to determine which channels are required; in general the shader could make data dependent accesses to channels, which would be tricky to figure out. Requiring the user to manually specify the list of required channels would avoid this problem but would be somewhat inconvenient; the one mitigating factor is that if all data access is through invlerp controls, then the channels are already indicated. Otherwise, the required channels could potentially be determined by:
Perhaps it would be sufficient initially to always download all channels, though I suspect very quickly someone would attempt to use this with an array with a large number of channels.
Then there is the question of how to support this during rendering:
The other (more natural) option would be to retain the original chunking of the data, where each chunk is loaded as a separate texture. The total number of chunks that could be used at any time would be limited by the number of textures that can be bound (32 on most implementations) --- i.e. 32 channels if channel chunk size is 1. That limit might be more of an issue if there is no mechanism for determining the set of required channels.
However, this does make the rendering code more complicated, because it becomes necessary to check for whether multiple chunks are available in GPU memory rather than a single chunk.
Thanks for looking into this.
The OME-Zarr spec can specify which channels are currently active
(visible). See
https://ngff.openmicroscopy.org/latest/#omero-md
Although this metadata is not guaranteed to be present, it should allow in many cases to know which channels to load initially.
:+1: for: "Perhaps it would be sufficient initially to always download all channels, though I suspect very quickly someone would attempt to use this with an array with a large number of channels." Would be more convenient for me than just re-chunking my zarrs/n5s and nothing is stopping someone from trying to load an excessive number of channels right now, they just need to make sure its not chunked.
I just want to suggest that downloading all channel based chunks might be a good v1, and is not incompatible with making a smarter dynamic solution later if it ends up being more complicated.
I agree right now that someone could also break things with a 1000 channel image right now if it were chunked into 1 channel chunk.
Hey Jeremy, in #238 you mentioned:
Support for channels spanning chunks would be useful for supporting ngff/ome-zarr. While the specification does not require channels be split, most of the current tooling does (bioformats2raw, ome-zarr).