The code here generally makes sense, but I'm unsure what http://github.com/ome/ome-zarr-py is intended to do if it finds one of these remote URLs.

Sorry for having missed the merging of ome/omero-ms-zarr@6add680#r450996719, but I think at the moment, the "image" key is in a bit of an intermediate state. E.g. what do you intend with the "source" subkey?

The code here generally makes sense, but I'm unsure what http://github.com/ome/ome-zarr-py is intended to do if it finds one of these remote URLs.

For now nothing, since all our masks are in the same Zarr as the image data. In future it could load the data. Alternatively this could be managed at the application level, where a user could choose to fetch the image or not.

If it's a relative URL the viewer it should only show the mask if that array is displayed. This handles @jburel's requirement to generate masks using a lower resolution from a pyramid.

what do you intend with the "source" subkey?

I've taken it out for now, it's become less useful as we've developed the spec.

cf.

• Multiscale labeled images ome-zarr-py#45
• Multiscale support #25

With the change to multiscales, the logic here is somewhat in flux. I'd like to simplify this by not dealing with URLs for the moment, i.e. rolling back to the change to the spec. See: ome/omero-ms-zarr@da260f2

I've simplified the naming down to "source-image" in #25, but happy to move to your naming once we're ready to expose "federated" datasets that link remotely.

A more immediate next change will be to rename the image.array key and integrate it with the rest of the labels metadata (color, etc.) Once all of that is done, would be good to get your docs from here open against the mainline.