sopa.segmentation.transcripts.resolve for Baysor segmentation fails

[Marius1311]

Thanks for this amazing tool!

Description

I have an sdata object with more than one image (MERSCOPE data with 7 z slices), and I used Baysor trough the sopa pipeline for segmentation. When running

resolve(
    sdata=sdata, temp_dir=baysor_temp_dir, gene_column="gene", min_area=10, shapes_key="baysor_boundaries"
)

I get

AssertionError: No element with the attribute cell_segmentation_image. Provide an element key.

It seems like it's looking for an image that does not exist. Removing the line image_key, _ = get_spatial_image(sdata, return_key=True) and instead passing the image_key explicitly to the method resolves this bug.

System

• OS: Ubuntu
• Python version: 3.11
• sopa version: 1.1.4

[quentinblampey]

Hi @Marius1311,

Thanks for reporting this. In your case, I imagine you have multiple images (one per z-stack), so the get_spatial_image can't find which image is the default image to use for segmentation. It should not give you this error if you had only one z-stack though, as it would use the only image available.

Indeed, explicitly passing the image_key works, but it's not a very convenient solution for the user. This is why I'm slowly updating Sopa to store some metadata when reading the data. This way, sopa will be able to find the right image without the need to precise the image_key. Still, I'll keep the image_key arguments for more flexibility.
For instance, if you had one H&E image + one DAPI slide, it would know that it could use the H&E image for tissue segmentation and the DAPI slide for cell segmentation.

Let me know what you think of this approach!

[Marius1311]

thanks for your reply! would that mean I have to know at loading time which z-slide to use for segmentation? In my case, that's something that I'm only finding out once I loaded and played around with the data a bit. I think it's more convenient to be able to decide later on, at segmentation time, which z-slide (or, in general, spatial element) should be used.

[quentinblampey]

Not necessarily: it would mean that, if you don't choose any z-stack, then it will use the middle one. But you would still be able to load all z-stacks, play around, and then choose the one with the best quality. In that case, you'll need to provide it as an argument while using the API.

The idea is that, by default, the API could run with minimal effort from the user, even for technologies with multiple images. And, if desired, the user could still provide additional arguments.
Actually, the utility of such a feature may be clearer for other technologies, such as Xenium, for which we have different images with different purposes (e.g., H&E image for tissue segmentation, which is aligned with the DAPI image for cell segmentation, etc...).

[lardenoije]

I had the same issue, but because I had multiple Points elements (I have one with transcripts and one with control probes). I agree that it would be nice to have more build-in flexibility for specifying keys. Now I modified the resolve function to accept **kwargs, which are passed on to get_spatial_element at line 50 where the points are extracted. This allows for the specification of a key for the desired points slot. However, this would not work for specifying both image and points keys, since both get_spatial_element and get_spatial_image would use the same key argument.

[quentinblampey]

Thanks @lardenoije for your feedback! I'm working on a new version of the API (sopa==2.0.0) which should ease its usage but also make it more flexible, so I'll try to incorporate this!