Closed manics closed 4 years ago
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 https://github.com/ome/omero-ms-zarr/pull/55/commits/6add68047269f0d85e7dc94251445da57d43c27f#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.
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: https://github.com/ome/omero-ms-zarr/pull/70/commits/da260f26b78960c4b3d32b4753c50ec7618bf758
I've simplified the naming down to "source-image" in https://github.com/ome/omero-cli-zarr/pull/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.
Also add docs for masks.py methods
Closes https://github.com/ome/omero-ms-zarr/issues/57