Load label image

[tischi]

@constantinpape @joshmoore @will-moore

We currently have two zarr files on our s3 storage where one is the label mask for another.
What would it take to - within the current or potential future specs - actually load one of them as a label mask?

For me, it would be much easier right now if we could achieve this by adding a respective metadata tag to the label mask zarr, rather than storing it inside the other zarr.

[joshmoore]

The current spec would look like this:

my-image.zarr/.zgroup
my-image.zarr/.zattrs                    <-- contains "multiscales" (no change)
my-image.zarr/labels/.zgroup
my-image.zarr/labels/.zattrs             <-- contains {"labels": ["some-name"]}, i.e. the linking metadata
my-image.zarr/labels/some-name/.zgroup
my-image.zarr/labels/some-name/.zattrs   <-- contains "multiscales" and "image-label"

following the spec it's not possible currently to refer to another .zarr, though the "inner" zarr could simply be the entire contents of the other zarr.

[tischi]

Ok, let's do it properly!
@constantinpape
Could you create such a file?

[constantinpape]

@constantinpape
Could you create such a file?

A few questions on this:

• Should I create an extra file or add it to em-raw?
• @joshmoore why is the contains {"labels": ["some-name"]} part of my-image.zarr/labels/.zattrs? Shouldn't it be in my-image.zarr/.zattrs, so that we no that we have labels corresponding to the image data?
• @joshmoore where is the current spec for the "image_label" metadata?

[tischi]

Should I create an extra file or add it to em-raw?

I think "add to" as it will not disturb what is there already, is it?
@joshmoore I think your philosophy is that the raw data and the segmentation(s) should be in the same zarr container, right?

[joshmoore]

• Should I create an extra file or add it to em-raw?

Unless you think it will be somehow "disruptive" to mix datasets in which case you could create a em-raw-plus-labels. To "rollback" the addition, though, you'd only need to rm -rf labels which is pretty straight-forward.

• why is the contains {"labels": ["some-name"]} part of my-image.zarr/labels/.zattrs? Shouldn't it be in my-image.zarr/.zattrs, so that we no that we have labels corresponding to the image data?

At the moment, that's just how the spec works: https://ngff.openmicroscopy.org/latest/#labels-md i.e. to discover the labels for an image you inspect image/labels/.zattrs.

I think your philosophy is that the raw data and the segmentation(s) should be in the same zarr container, right?

Currently yes. Until ome/ngff#13 is implemented.

[constantinpape]

Ok, thanks, I think I can add it now, will do it later and let you know.

[constantinpape]

@joshmoore @tischi
I tried to add our labels now, but I am not quite sure what to do with colors.
We are using random colors via a glasbey color table, but as far as I can see
there is only a fixed color table in the spec.
What should we do about this?

[will-moore]

You can omit colors from the OME-Zarr labels and simply generate random colors when you view the labels.

[constantinpape]

Thanks @will-moore, I did this.

@tischi I have added the labels on the embl s3:
embl/i2k-2020/em-raw.ome.zarr/labels

[tischi]

@constantinpape @will-moore
I think embl/i2k-2020/em-raw.ome.zarr/labels/.zattrs should contain a multiscales key, shouldn't it? Or where would I find this?

[constantinpape]

It's in embl/i2k-2020/em-raw.ome.zarr/labels/cells/.zattrs.

[tischi]

@constantinpape

I can read it now:

What is the largest label index, do you know?

[constantinpape]

@tischi max id is 32699

[tischi]

@constantinpape @joshmoore @will-moore

reader = new OMEZarrS3Reader( "https://s3.embl.de", "us-west-2", "i2k-2020" );
em = reader.read( "em-raw.ome.zarr" );
sources = BdvFunctions.show( em ); // raw and label mask, but both grayscale
Sources.showAsLabelMask( sources.get( 1 ) ); // now the label mask in colour

Suggestions for a better name of this?

Sources.showAsLabelMask( sources.get( 1 ) )

Something with Color in the name maybe or even Glasbey?
The function is however doing more than changing the LUT, namely also disable linear interpolation for this image, as this would lead to non-sense colouring at label boundaries.