HCS specification #75
Conversation
| - the fifth group defined all the individual fields of views for a given well. | ||
| The fields of views are images, SHOULD implement the "multiscales" | ||
| specification, MAY implement the "omero" specification and MAY contain | ||
| labels. |
There was a problem hiding this comment.
I expect we'll need to extend this syntax to elsewhere in the spec. For example, currently we have: "Information specific to the channels of an image and how to render it can be found under the "omero" key in the group-level metadata" suggests that an Image MUST have "omero" specification.
Probably, if this was improved then we don't need to specify the image metadata requirements here (under HCS) and under Images, but can refer from here to the Images spec (unless the Image spec requirements are different when under HCS? Probably not).
There was a problem hiding this comment.
I also noticed that currently the Images spec doesn't define whether the image contains Labels? e.g. in s3 there would be no way to know whether an image has labels.
There was a problem hiding this comment.
There would be no way to find the labels that aren't in the labels/ group, but those are discoverable.
There was a problem hiding this comment.
Yes I introduced RFC2119 as I suspect it might be useful to start thinking about these concepts both at the level of the individual keys but also at the level of the various specifications. If we agree, there will certainly be a work of reviewing the spec to introduce this terminology but a lot of this will be outside the scope of this PR.
While this terminology naturally applies to the definition of the individual keys applies naturally, I found it harder to use for the scope of each specification though. Taking your example, I don't think you MUST have an omero specification, but if you want some rendering metadata, you definitely SHOULD.
I also noticed that currently the Images spec doesn't define whether the image contains Labels? e.g. in s3 there would be no way to know whether an image has labels.
From the current spec, my understanding is that an image contains labels if the image group contains a sub-group implementing the labels specification?
There was a problem hiding this comment.
I guess that the discoverability of labels based on the existence of a sub-directory is different from the existence of e.g. Wells, Columns, Multiscale levels etc which are explicitly defined in the parent containers. To discover labels, you'd have to be aware of the spec to know to check, but for other sub-directories, you could find these by inspecting the parent metadata, without knowing the spec beforehand, which seems like a nice feature.
| dataset. There are exactly four levels of hierarchies above the images: | ||
|
|
||
| - the top-level group defines a single plate and MUST implement the plate | ||
| specification defined below |
There was a problem hiding this comment.
Don't disagree with this in general, but we might need to work on the wording. You could have a zgroup which contains 2 plates, but then the plate zgroup becomes the "top-level" that we're discussing here.
| - the top-level group defines a single plate and MUST implement the plate | ||
| specification defined below | ||
| - the second group defines all acquisitions performed on the plate. If | ||
| only one acquisition was performed, a single group must be used. |
There was a problem hiding this comment.
See ongoing slack discussion. If this is a "must" then this conflicts with the "should" in the first statement, no?
|
Migrated to: ome/ngff#5 Note there are a few open conversations here. |
Closes #73. Closes https://github.com/ome/omero-ms-zarr/issues/76
This PR captures the successive iterations for the first draft of the HCS specification
2020-10-29
The first set of changes capture the HCS Zarr layout which which was demonstrated as part of the 2020-10-29 community call.
Specification changes match the layout described in https://github.com/ome/omero-ms-zarr/issues/73#issuecomment-717206122 and include:
Implementations of the 2020-10-29 version of the HCS specification include:
Datasets created according to the 2020-10-29 version of the HCS specification on the https://s3.embassy.ebi.ac.uk endpoint URL
2020-11-09
Following, the 2020-10-29 community call, a few changes were made
namefield was added to the plate metadata (89a64fe )wellspecification as described in https://github.com/ome/omero-ms-zarr/issues/76(9713875 )
Implementations of the 2020-11-09 version of the HCS specification include:
Datasets created according to the 2020-11-29 version of the HCS specification: