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

[mruffalo]

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:

• [ ] Update the glob pattern in https://github.com/hubmapconsortium/portal-containers/blob/6d88b873da114b24e6a37bdedfb4082196cb2d38/containers/sprm-to-anndata/context/main.py#L131 to check for a different file which will always be present
• [ ] Read cell centers directly from *.ome.tiff-cell_centers.csv rather than computing these in this code

[mruffalo]

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]

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

[ilan-gold]

@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?