Tutorial, tests and parser argument for channel names in images

[LucaMarconato]

1. Create a tutorial or add documentation on how to use channel names with xarray images.
2. Add tests for the channel naming functionality in xarray images.
3. Consider adding an argument to the parser to allow users to easily add channel names when the input is not an xarray image, but something like a numpy image. -> the argument is c_coords

[LucaMarconato]

Related, a user just wrote:

One question did anything change regarding the channel names when working with xarray? I used to be able to do spatialImage.sel(c="DAPI") for example but not anymore. When doing spatialImage.coords only x and y are returned now.

FYI @giovp

[LucaMarconato]

@quentinblampey here is a screenshot that shows the usage

Could you try to see if it works?

[LucaMarconato]

@giovp is c_coords an xarray parameter? I think we should document it in the docs for the image models.

[LucaMarconato]

@melonora can you reproduce the above example? If you do import spaitaldata; print(spatialdata.__path__) what do you get? Maybe the editable install got overridden by the install from a satellite package and you are using an old version.

[melonora]

I can reproduce the example. When I print the path I get the location in site-packages

[melonora]

Ok I think I know what the problem is. Using the example above I saved the SpatialData object. Channel metadata in this case looks like this:

{
    "channels_metadata": {
        "channels": [
            {
                "label": "A"
            },
            {
                "label": "B"
            },
            {
                "label": "C"
            }
        ]
    },

This as opposed to the actual data I had converted a while back. This saved the channel metadata like this:

"omero": {
                "channels": [
                    {
                        "label": "DAPI"
                    },
                    {
                        "label": "Cy3"
                    },
                    {
                        "label": "Cy5"
                    },
                    {
                        "label": "Cy7"
                    }
                ]
            }

[melonora]

Just to note with saving the example above I can read it into a spatialdata object again and then access the channels the usual way:

[quentinblampey]

@quentinblampey here is a screenshot that shows the usage
...
Could you try to see if it works?

Thanks @LucaMarconato, it works nicely!
I also tried to select one channel, e.g. withsdata.images["z3"].sel(c='DAPI'), and it worked too

[giovp]

hi all, the way channel metadata is supposed to be saved in ome-zarr is currently broken upstream, hence decided for that solution. Once I fix it upstream then we'll just be using the way ome-zarr does it.

[melonora]

so the data can be kept in the way of using the omero part of the ome-ngff spec? As in this will be ultimately supported again?

[LucaMarconato]

so the data can be kept in the way of using the omero part of the ome-ngff spec? As in this will be ultimately supported again?

Yes, I think now ome-zarr-py saves it in the wrong location but still in the NGFF storage. @giovp will work on a fix for that.

[LucaMarconato]

When I print the path I get the location in site-packages

I think then you are not using the latest dev version of spatialdata as if you do an editable install it should show the repo path. You can fix this by uninstalling the library, and reinstalling it again with pip install -e .. Note that if you run pip install -e . on any of the following: spatialdata-io, napari-spatialdata, spatialdata-plot, it will override the editable installation of spatialdata with a non editable one.

[melonora]

yeah someone changed the environment while I was on holiday.

Question is reading the channel metadata done by ome-zarr or is it dealt with by SpatialData? In the latter case would it be possible to support both behaviours for now?

[melonora]

just checking the code in raster-io:) will get back to this topic