Write up new image-label proposal #71
Conversation
spec.md
Outdated
| @@ -47,7 +47,7 @@ for public re-use. | |||
| │ | |||
| └── 0 # Multiscale, labeled image. The name is unimportant but is registered in "labels". | |||
| ├── .zgroup # Each labeled image is also a multiscaled image, and therefore a Zarr group. | |||
| ├── .zattrs # Metadata of the related image and has an extra key, "color", with display information. | |||
| ├── .zattrs # Metadata of the related image and as well as display information under the "label" key. | |||
There was a problem hiding this comment.
Should it be
| ├── .zattrs # Metadata of the related image and as well as display information under the "label" key. | |
| ├── .zattrs # Metadata of the related image and as well as display information under the "image-label" key. |
as per the changes in this PR?
There was a problem hiding this comment.
This is marked as 'resolved' but it hasn't been changed to "image-label" as per @sbesson's comment?
There was a problem hiding this comment.
Should it also contain "multiscales" metadata?
Co-authored-by: Sébastien Besson <[email protected]>
| Groups containing the `image-label` dictionary represent an image segmentation | ||
| in which each unique pixel value represents a separate segmented object. | ||
| `image-label` groups MUST also contain `multiscales` metadata and the two | ||
| "datasets" series MUST have the same number of entries. |
There was a problem hiding this comment.
I'm a bit confused where in the hierarchy the image-label metadata goes compared with the multiscales metadata.
Re:
└── labels
│
├── .zgroup # The labels group is a container which holds a list
├── .zattrs # of labels to make the objects easily discoverable,
│ # All labels will be listed in `.zattrs` e.g. `{ "labels": [ "original/0" ] }`
│ # Each dimension of the label `(t, c, z, y, x)` should be either the same as the
│ # corresponding dimension of the image, or `1` if that dimension of the label
│ # is irrelevant.
│
└── original # Intermediate folders are permitted but not necessary
│ # and currently contain no extra metadata.
│
└── 0 # Multiscale, labeled image. The name is unimportant but is registered in "labels".
├── .zgroup # Each labeled image is also a multiscaled image, and therefore a Zarr group.
├── .zattrs # Metadata of the related image and as well as display information under the "label" key.
│
├── 0 # Each multiscale level is stored as a separate Zarr array, as above.
│ ...
└── n
The "group that contains image-label dictionary" is the lower-level .zgroup (sibling of the .zattrs that contains the "image-label" metadata)? So this group "MUST also contain multiscales metadata"?
There was a problem hiding this comment.
Last changes match my understanding of the recent discussions especially with regard to the handling of unique values. My vote goes towards committing to this proposal in its current form by getting this merged and released, start pointing our community at it and drive it via our own use cases.
| ### "image-label" metadata | ||
|
|
||
| Groups containing the `image-label` dictionary represent an image segmentation | ||
| in which each unique pixel value represents a separate segmented object. |
There was a problem hiding this comment.
| in which each unique pixel value represents a separate segmented object. | |
| in which each unique pixel value represents a separate segmented object. | |
| Only integer pixel types are supported. |
Trying to compare a floating-point pixel value with the floating point in the JSON metadata is difficult.
|
Added. We can work on the wording in the follow ups with the community. |
Follows on from #70 with the color specification. Comments from #70 (review) may need re-reviewing.