Skip to content

OME-Zarr visualization with varying levels of Z stacks #52

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

Closed
jluethi opened this issue May 16, 2022 · 3 comments
Closed

OME-Zarr visualization with varying levels of Z stacks #52

jluethi opened this issue May 16, 2022 · 3 comments
Assignees
Labels
Backlog Backlog issues we may eventually fix, but aren't a priority bug Something isn't working

Comments

@jluethi
Copy link
Collaborator

jluethi commented May 16, 2022

When parsing a multi-well dataset that contains different amounts of Z-stacks per well, napari only shows a subset of z stacks. In my test case /data/active/fractal/3D/PelkmansLab/CardiacMultiplexing/Cycle17/, there are 2 wells, B03 and B05. B03 has 19 Z levels, B05 has 42. The napari viewer only display 19 z levels though.

I haven't tested whether that's a metadata issue or a napari-ome-zarr plugin issue. Also, will be interesting to see if it's different depending on what amount of z stacks the first well has.

@tcompa
Copy link
Collaborator

tcompa commented Jul 25, 2022

I forgot details about this discussion (if we already had it), and I don't know what is the expected behavior on fractal side.
We can for instance fill a lot of levels with zeros (which for compressed files shouldn't matter much), or name folders in special ways (provided the reader actually reads them, because I think that for instance dask.array.from_zarr doesn't). Other options?

Question: How do we know the alignment between two stacks with different Z depths?
That is, is the bottom Z plane the same for all wells in a plate? Or is it the top one? Or is there some metadata to parse?

@jluethi
Copy link
Collaborator Author

jluethi commented Jul 25, 2022

Hey @tcompa
We haven't really discussed this much. This is more an edge-case issue I'd say (doesn't come up that often and is not mission critical). We provide a correct OME-Zarr file. But the current OME-Zarr-py library has a limited plate reading approach where it uses information of the first well to generate the framework for all wells with regard to size in x, y & z.
Once we have the parsing working for sparse FOVs (#8) (requires ROIs to be fully supported across our pipeline), we will have to deal with that assumption in the OME-Zarr-py library (because also our x & y dimensions could vary between wells). But I don't think Fractal should change how it handles Z layers (your workarounds should work, but ome-zarr-py should also become able to handle the data as is). This issue is here so that when we raise issues or create contributions to ome-zarr-py for more diverse setups, we don't forget about the varying Z levels.

Question: How do we know the alignment between two stacks with different Z depths?

In our setup, the bottom Z layer is set using an autofocus in the microscope. We thus assume that bottom layers align. This is approximately true, but there may of course be small shifts between autofocus for different FOVs.

Tl:dr: Nothing for us to do right now, but let's keep it in mind for later.

@jluethi jluethi added the Backlog Backlog issues we may eventually fix, but aren't a priority label Aug 4, 2022
@jacopo-exact jacopo-exact transferred this issue from fractal-analytics-platform/fractal-client Sep 6, 2022
@jluethi
Copy link
Collaborator Author

jluethi commented Jan 20, 2023

This is solved with this PR for ome-zarr-py: ome/ome-zarr-py#241

The PR has not been merged into the main ome-zarr repo and that may take a while, because it comes with performance impacts. But if someone needs to visualize varying Z levels (or varying xy sizes), this version ome-zarr-py works :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backlog Backlog issues we may eventually fix, but aren't a priority bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants