Skip to content

Conversation

@obriencshl
Copy link

Description

The current assumption in the spatial scatter plotting code is that any alternate spatial bases (i.e. non-default spatial_keys) will use the images stored in the default spatial basis (adata.uns["spatial"]). My workflow involves creating an alternate spatial basis (adata.obsm["spatial_rot"]) with transformed images (to align the spatial orientations of different libraries) stored in its own spatial uns key (adata.uns["spatial_rot"]), and this assumption means I have to explicitly retrieve and pass in images to the spatial_scatter function, which is inelegant.

I am unsure if this way of using alternate spatial bases is standard or desired by others, but from my perspective, if you're using an modified spatial basis, then the images should also be modified, because the spatial basis and the background images should be expected to line up. Additionally, alternate spatial bases are required (by the Key.uns.library_mapping function, called just above my change) to have an images dict, so it seems unreasonable to have images and then not use them, regardless of the workflow.

I am not sure if scale factors etc. are properly retrieved for alternate spatial bases; my workflow does not touch the scale factors.

How has this been tested?

I have run this against my own dataset, testing against the default basis adata.obsm["spatial"] and my custom alternate basis adata.obsm["spatial_rot"] with modified images. Specifically, adata.uns["spatial_rot"] is a deep copy of adata.uns["spatial"], with the images replaced with my transformed images.

Retrieve the image from adata.uns[spatial_key] rather than always adata.uns["spatial"].
@codecov
Copy link

codecov bot commented Sep 8, 2025

Codecov Report

❌ Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 24.05%. Comparing base (761a3c8) to head (8cdca3c).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
src/squidpy/pl/_spatial_utils.py 0.00% 2 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1032   +/-   ##
=======================================
  Coverage   24.05%   24.05%           
=======================================
  Files          43       43           
  Lines        6380     6380           
  Branches     1063     1063           
=======================================
  Hits         1535     1535           
  Misses       4828     4828           
  Partials       17       17           
Files with missing lines Coverage Δ
src/squidpy/pl/_spatial_utils.py 22.31% <0.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@obriencshl
Copy link
Author

Having just done some further testing, the scale factor retrieval is also incorrectly defaulting to "spatial". I'll add another commit.

@obriencshl
Copy link
Author

Segment retrieval may also be broken in scenarios like this, but I have no way of testing that at the moment, and the signatures of the functions involved don't permit an easy change.

@selmanozleyen
Copy link
Member

Thanks @obriencshl!

@timtreis given that our tests didn't fail for this bug (which I think is very critical because it might change the result of some studies without even noticing), do you think we should add tests here?

@timtreis
Copy link
Member

timtreis commented Nov 3, 2025

do you think we should add tests here?

Yeah, that's a good idea, but don't overinvest. Given that the entire spatial plotting module in Squidpy will be deprecated in favor of spatialdata-plot soon, I don't think we should invest too much effort here.

I guess this is also an FYI for your mentioned work @obriencshl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants