[Feature] Support WSI analysis

[quentinblampey]

High priority

• [x] Add a WSI reader (read a wsi into Xarray and then transform to a SpatialData object)
• [x] Add whole tissue segmentation + conversion to a shapely polygon
• [x] Support multi-polygon ROI in segmentation (or anything that uses ROI.KEY)
• [x] Tile embedding in order to encode tile-wise phenotypical information (with different pretrained models e.g., ResNet or in-domain representation learning models). The could be used in a similar fashion to spatial transcriptomics but they will be much sparser.
• [x] Tile clustering in order to generate cluster-maps with similar phenotypical characteristics. Since sopa is slide specific, the clustering should also be slide specific. Any cohort-specific clustering should be made outside of Sopa
• [x] Add the new dependencies into a new wsi extra

Low priority

• [x] Add openslide optionnal backend
• [x] Add sjoin in the API
• [x] Add some tutorials to the documentation

Will not be added for now

• hover-net segmentation method (or CellVit?)
• Save .zarr without the image, but instead keep a pointer to the original slide

[stergioc]

That could be a great feature add, thanks @quentinblampey for creating this issue!

So here are some additional features that could also be considered:

• Tile embedding in order to encode tile-wise phenotypical information (with different pretrained models e.g., ResNet or in-domain representation learning models). The could be used in a similar fashion to spatial transcriptomics but they will be much sparser.
• Tile clustering in order to generate cluster-maps with similar phenotypical characteristics. This clustering might need to be cohort specific instead of slide specific (TBD).

I can take a look on how to implement the IO for WSI and come back with a suggestion. :)

[quentinblampey]

What segmentation method should we use? CellViT? Hover-net? @HakimBenkirane is also using something else, called HistomicsTK

The method needs to have the following characteristics:

• few dependencies, easy to install (e.g., no openslide dependency)
• the method performs well, is well-validated and widely used
• not too slow

[stergioc]

While trying to make the whole patch embedding pipeline faster I have added the openslide backend at PR #26 . After some tests it is clear that openslide is much faster as a backend (x3). After a bit of digging I found this is issue that it might be related: https://github.com/Bayer-Group/tiffslide/issues/72, I am adding it here just for reference atm.

[quentinblampey]

Ok, thanks for investigating @stergioc! Since openslide is a heavy dependency, I think I will not add it inside the openslide extra: therefore, users that use openslide backend will need to install openslide themselves. What do you think? We can show a nice log if a user tries to use the openslide backend when it's not installed (as we already do for cellpose and baysor)

[quentinblampey]

Hello @stergioc, do you have any updates on the openslide backend?

[stergioc]

Hi @quentinblampey, I don't have any updates yet but I have planned some time for this next week. I will post it as soon as I have something. ;)

[quentinblampey]

Ok thanks! I'm merging the dev branch into the wsi branch, since a lot of things changed since our last push on the wsi branch

[quentinblampey]

Hi @stergioc, thanks again for your contributions, I'm closing this issue since we finished all tasks! Feel free to open again if you want to see a new feature