Better support for visualising highly multiplexed images
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 394
- Forks
- 95
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 7
Description
This is a tracking issue for some of the current issues when having a SpatialImage of circa >10 channels in SpatialData:
- Vizarr, Avivator, Vitessce fail when loading SpatialImage
- Test: Non-ome test datasets fail, except when subsetted to 3 channels. Test datasets with ome work.
- Solution: add ome.channels in NGFF metadata (See #230, posthoc fix code here)
- Loading a SpatialData object from disk with ome.channels NGFF metadata fails
- Test: ome test datasets fails on SpatialData.read
- Solution: fix channel parsing in io_raster.py maybe? (Also see #230)
- Show scale bar when viewing image
- Not in Vitessce though it has support, is present in vtk.js
- Vitessce scalebar currently defaults to 1 pixel = 1 micron
- Solution: add physical units to metadata instead of ‘unit’ when writing SpatialData (See #357, #120, #30; NGFF spec on units)
- vtk.js viewer does not work for ImageElement if the name doesn’t end in .zarr
- Test: non vtk datasets fail, vtk dataset works
- Solution: create issue at vtk.js (See https://github.com/Kitware/itk-vtk-viewer/issues/719)
- bug in animated-cell viewer when data does not have Z and/or T channel
- All datasets without z or t channel fail
- Solution: create issue at animated-cell (See https://github.com/allen-cell-animated/website-3d-cell-viewer/issues/172)
Test datasets at https://dl01.irc.ugent.be/spatial/proteomics/macsima_liver/ome_test/
Combinations of 4 different options. Ideally, SpatialData outputs ome+transform NGFF images by default and this can be read in by all viewers of OME-NGFF.
3c: subset to only 3 channels instead of 10
ome: add ome channels metadata (can no longer be read in by SpatialData)
transform: add microns transformation (but still with unit: ‘unit’) (only option that passes NGFF validator)
vtk: added .zarr suffix to image
HumanLiverH35.zarr NGFF validator
HumanLiverH35_3c.zarr NGFF validator
HumanLiverH35_ome.zarr NGFF validator
HumanLiverH35_vtk.zarr NGFF validator
HumanLiverH35_microns.zarr NGFF validator
HumanLiverH35_3c_ome.zarr NGFF validator
HumanLiverH35_3c_vtk.zarr NGFF validator
HumanLiverH35_3c_microns.zarr NGFF validator
HumanLiverH35_ome_vtk.zarr NGFF validator
HumanLiverH35_ome_microns.zarr NGFF validator
HumanLiverH35_vtk_microns.zarr NGFF validator
HumanLiverH35_3c_ome_vtk.zarr NGFF validator
HumanLiverH35_3c_ome_microns.zarr NGFF validator
HumanLiverH35_3c_vtk_microns.zarr NGFF validator
HumanLiverH35_ome_vtk_microns.zarr NGFF validator
HumanLiverH35_3c_ome_vtk_microns.zarr NGFF validator
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the listed failures with the linked HumanLiverH35 test datasets and inspect spatialdata_io/readers/_utils/_utils.py and io_raster.py, especially the ome.channels and physical-unit metadata paths. Compare the results with the NGFF validator and the affected viewers; done means the unchecked loading, visualization, and scale-bar cases work without breaking SpatialData.read.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data-visualization
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100