Resolving misc issues and ambiguities in labels section

[virginiascarlett]

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:

• Added for clarity: "Each label image MUST be stored within a "labels" group."
• One MUST --> MAY: "the datasets key MUST have the same number of entries (scale levels) as the original" --> "the datasets key MAY have the same number of elements (scale levels) as the original"
• One SHOULD --> MUST + clearer language: "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 label image .zattrs file MUST also contain the image-label key, whose value is a JSON object."
• Changed for clarity: "This array contains one JSON object for each unique custom label" --> "This array SHOULD contain one JSON object for each unique custom label."

Thanks!

[github-actions]

Automated Review URLs

• render latest/index.bs
• diff latest modified

[will-moore]

Just one comment. All the other changes look great!

[will-moore]

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?

[virginiascarlett]

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?

[sbesson]

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.

[bogovicj]

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.

[virginiascarlett]

Done!

[will-moore]

Looks good, thanks 👍

[imagesc-bot]

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

[jni]

Added for clarity: "Each label image MUST be stored within a "labels" group."

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?

[lubianat]

Hi @virginiascarlett , thank you for the contributions here! If this still makes sense, would you mind porting this PR to https://github.com/ome/ngff-spec/?

If you want to keep a pointer to the discussion, but no active PR, that is fine too. In that case, perhaps closing here and adding a summary issue with a path forward would be good.

[virginiascarlett]

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:

• Added for clarity: "Each label image MUST be stored within a "labels" group."
• One MUST --> MAY: "the datasets key MUST have the same number of entries (scale levels) as the original" --> "the datasets key MAY have the same number of elements (scale levels) as the original"
• One SHOULD --> MUST + clearer language: "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 label image .zattrs file MUST also contain the image-label key, whose value is a JSON object."
• Changed for clarity: "This array contains one JSON object for each unique custom label" --> "This array SHOULD contain one JSON object for each unique custom label."

Thanks!

[github-actions]

Automated Review URLs

• render latest/index.bs
• diff latest modified

[will-moore]

Just one comment. All the other changes look great!

[will-moore]

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?

[virginiascarlett]

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?

[sbesson]

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.

[bogovicj]

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.

[virginiascarlett]

Done!

[will-moore]

Looks good, thanks 👍

[imagesc-bot]

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

[jni]

Added for clarity: "Each label image MUST be stored within a "labels" group."

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?

[lubianat]

Hi @virginiascarlett , thank you for the contributions here! If this still makes sense, would you mind porting this PR to https://github.com/ome/ngff-spec/?

If you want to keep a pointer to the discussion, but no active PR, that is fine too. In that case, perhaps closing here and adding a summary issue with a path forward would be good.

[virginiascarlett]

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:

• Added for clarity: "Each label image MUST be stored within a "labels" group."
• One MUST --> MAY: "the datasets key MUST have the same number of entries (scale levels) as the original" --> "the datasets key MAY have the same number of elements (scale levels) as the original"
• One SHOULD --> MUST + clearer language: "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 label image .zattrs file MUST also contain the image-label key, whose value is a JSON object."
• Changed for clarity: "This array contains one JSON object for each unique custom label" --> "This array SHOULD contain one JSON object for each unique custom label."

Thanks!

[github-actions]

Automated Review URLs

• render latest/index.bs
• diff latest modified

[will-moore]

Just one comment. All the other changes look great!

[will-moore]

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?

[virginiascarlett]

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?

[sbesson]

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.

[bogovicj]

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.

[virginiascarlett]

Done!

[will-moore]

Looks good, thanks 👍

[imagesc-bot]

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

[jni]

Added for clarity: "Each label image MUST be stored within a "labels" group."

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?

[lubianat]

Hi @virginiascarlett , thank you for the contributions here! If this still makes sense, would you mind porting this PR to https://github.com/ome/ngff-spec/?

If you want to keep a pointer to the discussion, but no active PR, that is fine too. In that case, perhaps closing here and adding a summary issue with a path forward would be good.

[virginiascarlett]

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:

• Added for clarity: "Each label image MUST be stored within a "labels" group."
• One MUST --> MAY: "the datasets key MUST have the same number of entries (scale levels) as the original" --> "the datasets key MAY have the same number of elements (scale levels) as the original"
• One SHOULD --> MUST + clearer language: "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 label image .zattrs file MUST also contain the image-label key, whose value is a JSON object."
• Changed for clarity: "This array contains one JSON object for each unique custom label" --> "This array SHOULD contain one JSON object for each unique custom label."

Thanks!

[github-actions]

Automated Review URLs

• render latest/index.bs
• diff latest modified

[will-moore]

Just one comment. All the other changes look great!

[will-moore]

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?

[virginiascarlett]

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?

[sbesson]

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.

[bogovicj]

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.

[virginiascarlett]

Done!

[will-moore]

Looks good, thanks 👍

[imagesc-bot]

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

[jni]

Added for clarity: "Each label image MUST be stored within a "labels" group."

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?

[lubianat]

Hi @virginiascarlett , thank you for the contributions here! If this still makes sense, would you mind porting this PR to https://github.com/ome/ngff-spec/?

If you want to keep a pointer to the discussion, but no active PR, that is fine too. In that case, perhaps closing here and adding a summary issue with a path forward would be good.

[virginiascarlett]

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:

• Added for clarity: "Each label image MUST be stored within a "labels" group."
• One MUST --> MAY: "the datasets key MUST have the same number of entries (scale levels) as the original" --> "the datasets key MAY have the same number of elements (scale levels) as the original"
• One SHOULD --> MUST + clearer language: "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 label image .zattrs file MUST also contain the image-label key, whose value is a JSON object."
• Changed for clarity: "This array contains one JSON object for each unique custom label" --> "This array SHOULD contain one JSON object for each unique custom label."

Thanks!

[github-actions]

Automated Review URLs

• render latest/index.bs
• diff latest modified

[will-moore]

Just one comment. All the other changes look great!

[will-moore]

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?

[virginiascarlett]

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?

[sbesson]

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.

[bogovicj]

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.

[virginiascarlett]

Done!

[will-moore]

Looks good, thanks 👍

[imagesc-bot]

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

[jni]

Added for clarity: "Each label image MUST be stored within a "labels" group."

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?

[lubianat]

Hi @virginiascarlett , thank you for the contributions here! If this still makes sense, would you mind porting this PR to https://github.com/ome/ngff-spec/?

If you want to keep a pointer to the discussion, but no active PR, that is fine too. In that case, perhaps closing here and adding a summary issue with a path forward would be good.

[virginiascarlett]

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:

• Added for clarity: "Each label image MUST be stored within a "labels" group."
• One MUST --> MAY: "the datasets key MUST have the same number of entries (scale levels) as the original" --> "the datasets key MAY have the same number of elements (scale levels) as the original"
• One SHOULD --> MUST + clearer language: "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 label image .zattrs file MUST also contain the image-label key, whose value is a JSON object."
• Changed for clarity: "This array contains one JSON object for each unique custom label" --> "This array SHOULD contain one JSON object for each unique custom label."

Thanks!

[github-actions]

Automated Review URLs

• render latest/index.bs
• diff latest modified

[will-moore]

Just one comment. All the other changes look great!

[will-moore]

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?

[virginiascarlett]

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?

[sbesson]

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.

[bogovicj]

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.

[virginiascarlett]

Done!

[will-moore]

Looks good, thanks 👍

[imagesc-bot]

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

[jni]

Added for clarity: "Each label image MUST be stored within a "labels" group."

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?

[lubianat]

Hi @virginiascarlett , thank you for the contributions here! If this still makes sense, would you mind porting this PR to https://github.com/ome/ngff-spec/?

If you want to keep a pointer to the discussion, but no active PR, that is fine too. In that case, perhaps closing here and adding a summary issue with a path forward would be good.

[virginiascarlett]

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:

• Added for clarity: "Each label image MUST be stored within a "labels" group."
• One MUST --> MAY: "the datasets key MUST have the same number of entries (scale levels) as the original" --> "the datasets key MAY have the same number of elements (scale levels) as the original"
• One SHOULD --> MUST + clearer language: "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 label image .zattrs file MUST also contain the image-label key, whose value is a JSON object."
• Changed for clarity: "This array contains one JSON object for each unique custom label" --> "This array SHOULD contain one JSON object for each unique custom label."

Thanks!

[github-actions]

Automated Review URLs

• render latest/index.bs
• diff latest modified

[will-moore]

Just one comment. All the other changes look great!

[will-moore]

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?

[virginiascarlett]

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?

[sbesson]

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.

[bogovicj]

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.

[virginiascarlett]

Done!

[will-moore]

Looks good, thanks 👍

[imagesc-bot]

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

[jni]

Added for clarity: "Each label image MUST be stored within a "labels" group."

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?

[lubianat]

Hi @virginiascarlett , thank you for the contributions here! If this still makes sense, would you mind porting this PR to https://github.com/ome/ngff-spec/?

If you want to keep a pointer to the discussion, but no active PR, that is fine too. In that case, perhaps closing here and adding a summary issue with a path forward would be good.

[virginiascarlett]

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:

• Added for clarity: "Each label image MUST be stored within a "labels" group."
• One MUST --> MAY: "the datasets key MUST have the same number of entries (scale levels) as the original" --> "the datasets key MAY have the same number of elements (scale levels) as the original"
• One SHOULD --> MUST + clearer language: "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 label image .zattrs file MUST also contain the image-label key, whose value is a JSON object."
• Changed for clarity: "This array contains one JSON object for each unique custom label" --> "This array SHOULD contain one JSON object for each unique custom label."

Thanks!

[github-actions]

Automated Review URLs

• render latest/index.bs
• diff latest modified

[will-moore]

Just one comment. All the other changes look great!

[will-moore]

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?

[virginiascarlett]

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?

[sbesson]

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.

[bogovicj]

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.

[virginiascarlett]

Done!

[will-moore]

Looks good, thanks 👍

[imagesc-bot]

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

[jni]

Added for clarity: "Each label image MUST be stored within a "labels" group."

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?

[lubianat]

Hi @virginiascarlett , thank you for the contributions here! If this still makes sense, would you mind porting this PR to https://github.com/ome/ngff-spec/?

If you want to keep a pointer to the discussion, but no active PR, that is fine too. In that case, perhaps closing here and adding a summary issue with a path forward would be good.