Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sprm-to-anndata and sprm-to-json shouldn't depend on cell polygons from SPRM #104

Open
2 tasks
mruffalo opened this issue Jul 8, 2022 · 3 comments
Open
2 tasks

Comments

@mruffalo
Copy link
Contributor

mruffalo commented Jul 8, 2022

Both of these workflows check for cell polygons from SPRM, for two purposes:

  • Computing cell centroids via shapely.geometry.Polygon.centroid
  • (more importantly) identifying which images to convert/process, via globbing for *.ome.tiff-cell_polygons_spatial.csv

This is suboptimal, since this output file can be disabled via an option in SPRM, and this will not be available at all for 3D SPRM results.

This should be addressed in two ways:

@mruffalo
Copy link
Contributor Author

mruffalo commented Jul 8, 2022

I pushed a few commits to https://github.com/hubmapconsortium/portal-containers/tree/mruffalo/sprm-to-anndata-centroid-fix, but blocked on updating sprm-to-json since this does write cell polygons in JSON format.

As far as I know, this hasn't been used by Vitessce in some time, but I'm not sure of that. Can someone who's more familiar with that code advise and/or take over? I'd hope that the additional test data and code changes in sprm-to-anndata can be ported easily to the sprm-to-json workflow.

@mccalluc
Copy link
Contributor

mccalluc commented Jul 8, 2022

(Pinged @ilan-gold on slack -- I can pick it up if he doesn't.)

@ilan-gold
Copy link
Member

@mruffalo Just to be clear here - you're saying that you want to remove the dependency on outputting polygons? I think, as I remember, removing things like this has been a no-go for already existing assays. Whether or not 3D counts as an existing assay is a different story. So for me, I think it would make sense to

  1. Continue outputting polygons in 2D
  2. Remove the dependency here on outputting polygons so that the 3D workflow works.

Does this work for you?

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

No branches or pull requests

3 participants