How to represent rounds and channels in ISS data

[tischi]

For using ISS data one needs to know the "round" and "channel" for each image.

Is it within scope to represent this metadata in SpatialData?

I could not see anything about this here: https://github.com/scverse/spatialdata-io/blob/main/src/spatialdata_io/readers/iss.py

[LucaMarconato]

The images are c(z)yx, so you could store the channel/round as the additional channel, but if something like rc(z)yx (r for round) is needed, then one would have to store different round in different images.

From the coordinate alignment perspective, we don't allow to have different coordinate transformations for different channels. So in that case I would recommend to store all the images that need alignment into different single-channel images. It is then possible to stitch all the images together for a common area (I have some scripts to do this if interested).

@BioinfoTongLI could you also comment on this please? Is the reader assuming that the various images have already been aligned or do you also have the need to encode channels and rounds?

[melonora]

Overall you can pass c_coords right now which is a list with length equal to the number of channels. Here you can set a prefix for the round as well (as well as put the round in the image name. For example c_coords=["round1_DAPI", "round1_cy3", "round1_cy5", "round1_cy7", "round1_FITC"]. You would then have 1 image with 5 channels per round. Each round ofcourse is already aligned so you would basically add transformations to the subsequent rounds to align them with round 1.

There is the plan for storing the metadata in a more sophisticated manner in SpatialData using ro-crate, but this is longer term.

[BioinfoTongLI]

In our case, we assume our 7-round, 5-channel-per-round image is one single multichannel stack, and they are pre-aligned. So, it's in the end one stack with 35 channels. I didn't know about @melonora mentioned. It seems to be a neat solution for now.

[melonora]

Note that it only works if affine transformation is enough. Bilinear transforms are not supported yet but it is in the planning.

[tischi]

you can pass c_coords right now

Would/could that also be serialised to disk?

[LucaMarconato]

Yes, it is serialized on disk in the OMERO metadata (handled by ome-zarr-py), you can find the relevant code here in spatialdata and here in ome-zarr-py.

[tischi]

Thanks @LucaMarconato, however I could not find anything specific to store round and channel indices.

Summarising the previous conversation, my feeling is that one can simply define arbitrary channel names or is there anything else that I am missing?

[melonora]

Yes you can indeed just create ordinary channel names and store the information like that. Personally I would give the images the name of 'roundn_suffix_of_choice' and then store the channel names using 'c_coords'.

As stated before we are going to more properly support this kind of metadata.

[tischi]

Hi all, again, were there any new developments regarding "officially" supporting the notion of imaging rounds and channels in SpatialData.

To be honest, personally, I am not even sure this is a good idea, image data is so diverse that one cannot have a spec for everything :-)

One the other hand, both protein and gene based spatial-omics assays seem to have this data structure...

I think I'd be happy with having one multi-scale image for each round, containing all the channels, and indicate the round in the image name. That should be also easy to generate from microscopy input data, because, I think, typically it would already have this structure.

[melonora]

not directly in SpatialData. I would say this is more some work with the current OME-NGFF challenge on metadata. The structure you state here is also what I use myself and then with c_coords that I mentioned before you can give the names to each individual channel.

I do have some work on metadata and how to support particular specifications, but exactly what the specification looks like is not something SpatialData specific.

[LucaMarconato]

I think I'd be happy with having one multi-scale image for each round, containing all the channels, and indicate the round in the image name. That should be also easy to generate from microscopy input data, because, I think, typically it would already have this structure.

This is what currently is implemented 😊