Resolving misc issues and ambiguities in labels section #170
Conversation
Automated Review URLs |
| In addition to the `multiscales` key, the JSON object in this image-level `.zattrs` file SHOULD contain another key, `image-label`, | ||
| whose value is also a JSON object. The `image-label` object stores information about the display colors, source image, and optionally, | ||
| The label image .zattrs file MUST also contain the `image-label` key, whose value is a JSON object. | ||
| The `image-label` object stores information about the display colors, source image, and optionally, |
There was a problem hiding this comment.
Since there are no mandatory contents of the image-label dictionary, it would be valid to have image-label: {}.
It seems that making the spec more strict (a breaking change) to require the image-label dict is probably not worth it in that case?
There was a problem hiding this comment.
I think that that 'MUST' was in response to @sbesson's comment on my previous PR:
"For the image-label specification, my personal opinion would be to enforce it at a MUST level. Doing so would have the advantage of making it unambiguous and potentially reducing the number of graph operations."
Maybe @sbesson can comment here?
There was a problem hiding this comment.
Thanks for the ping @virginiascarlett. Trying to justify, the rationale behind my original statement, I see a label image as a specialized type of multiscales image. At the moment, the specification enforces that such data must be stored within a well-defined labels hierarchy but moving forward, I could certainly imagine a relaxation of this constraint.
A typical use case that comes immediately to mind is the one where segmentation / classification is performed against a read-only Zarr dataset e.g. public data and the output of this process needs to be stored as a new dataset. At the moment, the structure which is the most compliant with the spirit of the specification is create an artificial labels/<label_name>/ hierarchy under the root even if there is no multiscales image. Assuming we relaxed this constraint to allow label images to be stored at the root of the Zarr dataset, I would argue the image-label metadata would become a critical element to identify what we are dealing with.
That being said, Will's point makes sense and if this specification change simply leads to most implementations adding image-label: {} in the metadata, I don't find this is particularly helpful.
Happy to separate this discussion from your proposal, revert the requirement level back to the SHOULD level and come back to this discussion if we decide to specify standalone label images.
There was a problem hiding this comment.
I would be happy with keeping image-label at the SHOULD level if we agree.
Good points raised by @sbesson on having standalone label images. I agree those would be a nice addition, and worth discussing in its own issue. I may start one now, but will likely neglect it until the next release is pushed through.
|
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/save-a-single-labels-dataset-into-an-ome-zarr/93505/17 |
I would like to point to this imagesc discussion where people are quite unanimous that this is a bad idea — can we remove this line? |
Following up on my last PR. Previously, we added a lot more explanation to the 'labels' section of the spec. Now I am not just editing the language, but making some substantive, though minor, changes. Here's a quick summary of what I changed:
Thanks!