RFC-6: Multiscale

[normanrz]

This RFC proposes to change the multiscales array into a single multiscale object.

co-authored by @dstansby

[github-actions]

Automated Review URLs

• Readthedocs
• render latest/index.bs
• diff latest modified

[normanrz]

If you would like to endorse this RFC, please leave a 👍 reaction or comment.

[will-moore]

👍 Endorse

[ziw-liu]

One (hypothetical) use case for an array of multiscales is to store measurements of the same sample-space grid (same scale as in coordinate transforms) that are in different data types. For example, for widefield fluorescence microscopy, the raw camera frames are in unsigned integers, and the deconvolved images are in floating point numbers. In practice many people (including me) just store them in separate Zarr stores, which has it's own problems. What would be the recommended solution for this?

[dstansby]

In practice many people (including me) just store them in separate Zarr stores, which has it's own problems. What would be the recommended solution for this?

I think our recommendation would be to store them in separate OME-zarr datasets. Could you share some more details about what problems you have with storing them like this?

[ziw-liu]

I think our recommendation would be to store them in separate OME-zarr datasets. Could you share some more details about what problems you have with storing them like this?

Mostly the hassle of having multiple URLs for the same dataset. For example to visualize them in a viewer, the user needs to open each store individually; to run some simple processing (e.g. make a crop), the user needs to run the same pipeline multiple times. Each user would also need to come up with their own practices to keep track of all the associated stores, as opposed to being able to follow a standardized storage hierarchy.

[normanrz]

I agree that passing around multiple URLs is a hassle. However, I don't think multiple multiscales were intended for that and almost no visualization tools support them properly.

Your use case is very similar to grouping segmentations or predictions together with the image. It also is similar to grouping images from other modalities through coordinate transformations. Together with a few other people, I am writing another RFC that aims to introduce collections for OME-Zarr that would enable these use cases. The draft is still very early but you can have a look here: https://hackmd.io/rQPfIMw0Q9SqP9WWspCiLQ# I would love to hear your feedback there.

[joshmoore]

I think our recommendation would be to store them in separate OME-zarr datasets.

Do you mean in a separate multiscale, @dstansby? Or does datasets here == array? Or a separate Zarr fileset?

[dstansby]

(after looking at the spec for the right terms) I think I meant storing them as separate OME-Zarr images

[ziw-liu]

The draft is still very early but you can have a look here

I get 403 forbidden for the link. I'll definitely read once it's an RFC though!

[normanrz]

That link currently requires a hackmd account to access.

[normanrz]

(after looking at the spec for the right terms) I think I meant storing them as separate OME-Zarr images

I think our recommendation would be to store them in separate OME-zarr datasets.

Do you mean in a separate multiscale, @dstansby? Or does datasets here == array? Or a separate Zarr fileset?

I think you mean the same thing: a separate Zarr group with multiscale metadata.

[perlman]

👍 (endorse)
Happy to see this written down, including the concise json example.