Skip to content
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

[WIP] Fix offset of images at lower resolutions due to non-unit scale #31

Closed
wants to merge 3 commits into from

Conversation

andy-sweet
Copy link
Collaborator

Since the highest/raw resolution tomograms now have a non-unit scale, this caused a bug when visualizing the non-highest/raw resolution tomograms with points annotations due to the way in which we manually offset the tomograms for appropriate display in napari.

This fixes the offset so that it properly takes into account the scale of the tomograms.

Still a WIP, because I need to work out what to do about napari/napari#6914 here.

@andy-sweet andy-sweet changed the title [WIP] Fix offset of images due to lower resolutions [WIP] Fix offset of images at lower resolutions due to non-unit scale May 14, 2024
andy-sweet added a commit that referenced this pull request May 21, 2024
This adds support for segmentation-mask and oriented-points annotations
types.

![Screenshot 2024-05-15 at 16 42
33](https://github.com/chanzuckerberg/napari-cryoet-data-portal/assets/2608297/dfeee38d-5d58-41c3-ba78-9f87afd589a0)

Segmentation masks are supported by loading the corresponding OME-Zarrs
in a similar way to the tomogram (i.e. according to resolution).

Oriented points are currently read and displayed as regular points. We
can follow up with another PR to augment that with the orientation
information (e.g. with a vectors layer).

As some datasets contain tomograms with lots of different annotations
(e.g. 10000), performance can suffer both while waiting for data to
arrive and when interacting with napari once it has.

This also fixes an alignment issue caused by the highest resolution
tomogram volume having a non-unit volume. I originally separated that
into #31, but there was some overlap with the changes here, so I brought
it into this PR.

Closes #22 and #23
@andy-sweet
Copy link
Collaborator Author

Closing in favor of #21

@andy-sweet andy-sweet closed this May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant