-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
omero IDs in napari layer metadata #16
Comments
Few initial thoughts:
which we might be able to unify with the Zarr metadata work. |
I like |
Connection info (excluding the password of course) occurs to me as another entry. |
Thinking over this again:
So maybe something like:
I guess it might be possible that we need multiple objects for some of these, but I think that would be the exception and making all of them lists would be painful. Could always have a list of e.g. |
this seems safe. there might be a many-to-one relationship between napari layers and an OMERO image, but probably never a one-to-many, right? I agree with all of your points and I think this would be a fine starting point. if we need to modify later, no problem |
cf: https://gitHub.com/ome/omero-marshal I realize it's a bit overkill at this point, but at least to have an example of where we might be going both with general OMERO metadata as well as specifically with Zarr metadata, I've added some json-ld below. It's partially cleaned, but there's obviously still more that could be stripped for napari. Salient points are likely the use of My overall hope would be to not build yet-another-parsing library for metadata. The flip-side, that I/we recognize, is that the format itself is going to need to get more usable. That's possible with json-ld, but so far there just hasn't been a driver. E.g. it's possible to inline values like 'monochrome' so that using the json becomes much more natural. json-ld output from /api/v0/m
|
See #14 (comment)
When opening an Image from OMERO, it will be useful to store the ID of that Image in the layer metadata,
E.g.
get_omero_metadata()
could includeThis can then be used by other code to e.g. load / save ROIs back to OMERO etc.
Since this becomes a potential API with other code, need to think about what we want to store (and not change it without warning / versioning etc).
Simplest example above. But, we might have opened a HCS Well (as we can do with e.g. iviewer) or have other OMERO IDs we wnat to store.
so maybe
omero_id
is not a good key. Or evenomero_object: Image:1
since there might be other objects?Maybe
omero_image:1
andomero_well:2
could work?cc @joshmoore
The text was updated successfully, but these errors were encountered: