Description
We are looking to save multiplexing data (⇒ multiple cycles of acquisitions for the same plate) to HCS OME-Zarr files. Reading in the OME-NGFF spec, plates have the acquisitions key. This appears like a good way to save multiple acquisitions to the same plate.
I tested this with a small test dataset containing 2 acquisitions for a tiny plate (single well, single large image per well & acquisition): https://www.dropbox.com/s/tj8jj5iu5yxinz9/2_acquisitions.ome.zarr.zip?dl=0
This example has 2 images per well (/FOVs, see ome/ngff#137), 1 per acquisition (2 times the exact same images for both acquisitions for testing purposes). When loading the images individually into napari with the napari-ome-zarr plugin, I get the desired behavior of all 3 channels of both acquisitions being loaded ⇒ 6 channels & 2 label channels.
When loading the whole well or the plate, I get behaviors that don’t match this. Loading as a wel
56EE
l, I get the two acquisitions as the same channel, just tiled next to each other (probably a limitation of our well loading PR that just tiles all the images and doesn’t check for acquisitions).
When I load the plate, I just get the first acquisition, the second acquisition is ignored.
Now my big question: Is the current spec version of having multiple acquisitions what should be implemented to the ome-zarr-py? Is loading multiple acquisition as in the first image a behavior that ome-zarr-py would want to support for wells & plates?
Or has the thinking changed in how to handle multiple acquisitions? I saw that there originally was acquisition loading support for plates, but it was removed in #111
No, acquisitions was just something we tried out and decided wasn't what we wanted in the spec. I only left it in temporarily so we could view a couple of the plates that I'd created in the meantime.
@will-moore : Was this just for the original implementation of acquisitions (as an additional level), or also for the new spec?
If the current acquisition logic in the spec is what should be supported, we’d start using this for our multiplexing data and happy to have a go at trying to implement this for napari-ome-zarr plate & well reading. But if the thinking on this topic has changed, I’d be curious to join discussions on how to save multiple acquisitions to a Zarr file.