Xenium: use physical units instead of pixel units as references

[wangjiawen2013]

Hi, I find the coordinate differs a lot between 10xXenium analyzer and spatialdata. This is figures from 10xXenium analyzer: And this is from spatialdata (the same dataset as above, generated by sdata.pl.render_images("morphology_focus").pl.render_shapes("cell_circles").pl.show():

It seems that spatialdata transform the physical coordinate for some reason, which can be seen from the following snapshot: We believe that the physical coordinate (μm, micron) is more biological relevant, because we can see the physical size of the sample and the physical location of genes/cells in the sample. It's especially useful when comparing samples among different datasets because the physical coordinate represents the true size of the sample. So why does spatialdata make the transformation and how to show physical coordinates ?

[LucaMarconato]

Thanks for reporting. I will transfer the issue to spatialdata-plot.

You can fix this by introducing a new coordinate system, for instance you could call it 'physical', or it could replace 'global', so that instead of aligning the points to the images and use the images as the reference, one aligns the images to the points. In other words one would use a Scale(1 / k, 1 / k) with k as in your screenshot, instead of the Identity used for images and labels (see for instance here how it is set for labels: https://github.com/scverse/spatialdata-io/blob/248c7f0a0f5e1895a34e23cfcb77f98410f06644/src/spatialdata_io/readers/xenium.py#L422).

• [ ] In the long term we should probably do this at the level of the xenium() reader.

But before that if we re-enable the storage of spatial units (like µm) in spatialdata (relevant issues: https://github.com/scverse/spatialdata/issues/30 https://github.com/scverse/spatialdata/issues/436). The feature was actually implemented in early versions but we removed that due to some other work that we want to address first https://github.com/scverse/spatialdata/issues/308.

When all the above is addressed, dealing with physical coordinates will be much cleaner. But since there are ways around this, like manually introducing the physical coordinate system, which are actually very quick to implement in practice (a few lines of code), the work above doesn't have high priority, and we are fixing other bugs/making other improvements instead at the moment.

Hope this help 😊

[LucaMarconato]

Back to the context of plotting. If you introduce the 'physical' coordinate system as mentioned above, and if you make the plot using pl.show(coordinate_systems='physical'), the plot will be correct (the xlabel and ylabel with with µm needs to be manually added until the issues mentioned above are addressed).

[wangjiawen2013]

Thanks, I'll introduce the pysical coordinate system using scale.inverse() for 2D shapes. While for 3D points element, such as transcripts, because it has z-axis, can I use scale.inverse() too ?

In spatialdata documentation, it seems that the z-axis was neglected. How to show z-axis ?

[LucaMarconato]

Great! Yes, it will work also for the points.

[wangjiawen2013]

In spatialdata documentation, it seems that the z-axis of transcripts was neglected. How to show z-axis ?

[LucaMarconato]

Yes, the points are shown independently of the z-axis. Options to consider it is to color the points by the z value, or manually pre-filter the data based on a cutoff on the z value. 3D visualization is currently not supported.