Determine the location to store the mapping of the segmentation custom labels

[kabilar]

Description

In the BIDS specification, a sidecar <matches>.tsv or top-level dseg.tsv file can specify how the integer values of the segmentations map to custom labels. There also might be an option to store this mapping in the .zattrs/zarr.json file. Let's decide on where we should store this data.

Action items

1. Determine if there is a location to store the mapping of the custom labels in the .zattrs/zarr.json file.
2. Reach out to the OME and BIDS community to determine if this mapping should be in the .tsv file or .zattrs/zarr.json file.

cc @jingjingwu1225 @jssyq @elissabell

[kabilar]

Filed bids-standard/bids-specification#2000

cc @jingjingwu1225 @balbasty @satra

[balbasty]

@kabilar do I understand correctly that OME-Zarr requires labels to be stored in the same zarr as the image?

E.g. it would look something like

path_to_asset.ome.zarr/
|- zarr.json
|- 0/
|- 1/
|- 2/
| ...
|- n/
|- labels/
|  |- zarr.json
|  |- first_label_map/
|  |  |- zarr.json
|  |  |- 0/
|  |  |- 1/
|  |  |- 2/
|  |  | ...
|  |  |- n/
|  |- second_label_map/
|  |  |- zarr.json
|  |  |- 0/
|  |  |- 1/
|  |  |- 2/
|  |  | ...
|  |  |- n/

If yes, I don't think it's something that makes sense for us. Segmentation is always something that we'll obtain by processing an existing asset, and I'd want to store the result as a new asset, not by -- in effect -- modifying the original asset (even if most of the content is untouched and we're adding a group).

It make more sense for us to follow the BIDS convention as if all our data was in nifti format, even though in practice it is in zarr format. So I am in favour of saving label dict in a BIDS tsv file.