fast multiscene loading

[toloudis]

Use Case

Let's write a very simple first possible implementation of multi scene. The purpose here is to deliver something quickly that is demo-able for scientists and others. This need not be the final UX, nor the final input format, nor the most general internals.

Requirements:

• a multi-scene slider in XY mode, or below Z and T. ("Below" because we put T below Z, so scene should go below that)
• some basic input format to test with
• it's ok if we require same x,y,z,c dims but better if we don't. Will know better with test data, and will confirm whether we can assume this

TBD, open future questions:

• ome-zarr collection spec? hierarchical zarr groups? what is the data organization?

• how do we pass the information in to the viewer to tell it what to load?

• where in the user interface does scene switching happen?

• is this more like a dimension or more like a file system?

Solution

a "scene" is just a single 5D zarr image. so multiscene for our purposes right now is just a collection of zarrs.

Let's start with a slider above the time slider if multiscene data is requested.

Simplifying assumptions:

• each zarr scene is single-source
• if T dimensions are different, we can just clamp T slider (so newly loaded scenes might just jump to their last T if it's less than the current T of the previously loaded scene)
• if Z and C are different we should do the most similar claming/truncation.

Minimal input format:

json with:
{"scene name":"zarr url", ...}
create a new url query parameter for this, something like ?collection=url_of_multiscene_json

One motivator for this might be to open collections that come out of BFF in csv format.
csv would look for two special columns: "Name", and "File Path". "File Path" is a special hardcoded column name in BFF.

Implementation details:

• I don't know if it makes more sense to keep a collection of Volumes or to swap out all of a single Volume. In order to be optimal like Zen, you'd ideally want to change as little as possible and just swap in new Channel data.
• then what if scene dims are different?

• how much stuff do we keep the same vs resetting?
• is this the time to change transfer function control points be raw intensities for their x values? Probably not, in order to deliver the demo faster... but after that, maybe.

[toloudis]

Suggested "collection" format:
https://www.npmjs.com/package/ro-crate
TODO find how OME prefers to use rocrate to organize zarr image collections.

[toloudis]

Suggested steps to get a demonstrable implementation:

• start with ro-crate as a json schema.. alternatively we could start simpler but this might help bootstrap us for production-ready data down the road
• get multiscene example zarrs from Antoine
• put separate zarr urls into a ro-crate IN THE SIMPLEST WAY POSSIBLE FOR NOW
• write simple code to parse the ro-crate using npm ro-crate package?
• allow the viewer to be handed a ro-crate in the url query params, something like collection=url_to_rocrate.. collection, rocrate any keyword for now. This needs some thought for a permanent solution.
• the parsed rocrate results in a list of zarrs that we can put in a dimension slider above the time slider, to imitate what people are used to in Zen viewer.

[frasercl]

• Multiscene loading vole-core#275
• Multiscene: parse ro-crate vole-core#276
• Multiscene UI #351
• Irregularly-shaped multiscenes vole-core#277