scverse / spatialdata

An open and interoperable data framework for spatial omics data
https://spatialdata.scverse.org/
BSD 3-Clause "New" or "Revised" License
236 stars 45 forks source link

Support images with dimensions t, c, z, y, x #247

Open joshua-gould opened 1 year ago

joshua-gould commented 1 year ago

Without this support, spatialdata is not usable for experiments containing a time dimension. One could combine t+c into the c dimension (ugly in my opinion), but we would still need 4-d images to support experiments with the dimensions c, z, y, x. Thanks.

LucaMarconato commented 1 year ago

Hi Joshua, thanks for reporting this. We decided to omit the t dimension from the data for two reasons:

  1. it was easier to work on transformations and coordinate systems just with czyx dimensions
  2. there is still no consensus on how one should represent points, circles, polygons and multipolygons when there is also a t component.

Now the transformation code is mature enough and could supports arbitrary dimensions, but the second point still holds and we would need more feedback from the community and discussion to see how to proceeed.

Anyway, I had a chat with @joshmoore today and we discussed that we could prioritize the support for the t dimensions for the images and possibly labels. For that, it would be convenient if you could point us to a few datasets and example pipelines/use cases, so that we get a feel of how the new dimension would influence the various APIs (transforam, query, aggregate, rasterize, etc.). Thanks again for bringing this up.

joshua-gould commented 1 year ago

Thanks for your response. One of our use cases that would benefit from spatialdata having a t dimension is representing optical pooled screens (code and data available from https://github.com/feldman4/OpticalPooledScreens). As an example, we align across sequencing rounds to t=0 and then align across channels within a round so we would need a separate transformation matrix for each t and c. Happy to discuss more.

LucaMarconato commented 1 year ago

Thanks for the reference. Right now we don't have different transformations for different c channels, I think this could be a good way to start the implementation and see the impact to the APIs. I put in the loop also @melonora since he had a similar use cases for the c channels.

melonora commented 1 year ago

@joshua-gould For me working with multiplexed imaging data, I have multiple rounds of dimension cyx where each round has a DAPI which is used for registration. The way that I do it is to save each round as a separate image within the zarr store.

Using set_transformation(sdata.images[<IMAGE_KEY>], transform, to_coordinate_system=coord_system) would allow you to set the transform for the specific image. The transforms for different images can be different even when the name of the coordinate system is the same. Hope this helps and provides a starting point, but if not please let us know.