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] Experiment with multiscale grid #80

Draft
wants to merge 10 commits into
base: main
Choose a base branch
from
Draft

[wip] Experiment with multiscale grid #80

wants to merge 10 commits into from

Conversation

manzt
Copy link
Member

@manzt manzt commented Mar 3, 2021

This PR replaces the sublayers in gridLayer.ts with MultiscaleImageLayer and uses a projection matrix to translate each grid item. For large grids, my computer chokes, but for smaller grids (like "wells") it seems to work quite well.

The Added benefit is that grid items load can load independently.

Screen.Recording.2021-03-02.at.10.17.48.PM.mov
Screen.Recording.2021-03-02.at.10.22.42.PM.mov

@will-moore This uses implements the metadata reuse i mentioned in #75. I think finding a heuristic for when a grid is "too big" is probably the right path forward.

@manzt
Copy link
Member Author

manzt commented Mar 3, 2021

@manzt manzt marked this pull request as draft March 3, 2021 03:36
@will-moore
Copy link
Collaborator

Hi, the asyn loading of Wells is nice.
Certainly for the whole plate demo, the zooming is a bit painful compared to the current viewer. Which is a shame as the functionality of loading higher resolution tiles as you zoom in is exactly what is wanted. It works fine on the smaller grids of images (single Well).

NB: I don't know if you're following ome/ngff#31 ? Discussion about changing the way the OME-Zarr spec for collections of images (e.g. a Plate), but that will affect vizarr. E.g. If all images are in a single Plate container, could something like source=/path/to/plate.zarr#A1 work for opening a Well?

@manzt
Copy link
Member Author

manzt commented Mar 4, 2021

Certainly for the whole plate demo, the zooming is a bit painful compared to the current viewer. Which is a shame as the functionality of loading higher resolution tiles as you zoom in is exactly what is wanted. It works fine on the smaller grids of images (single Well).

I might try the non-multiscale image layer from Viv for large plates, and then default to multiscale for plates that are small enough (question is what hueristic to use for "small enough"). Benefit here is that loading would be async regardless.

NB: I don't know if you're following ome/ngff#31 ? Discussion about changing the way the OME-Zarr spec for collections of images (e.g. a Plate), but that will affect vizarr. E.g. If all images are in a single Plate container, could something like source=/path/to/plate.zarr#A1 work for opening a Well?

Haven't been following this, thanks for pointing me to it. I don't think this would work currently in vizarr, but if there ends up being a change, I would probably just update vizarr to handle whatever that is. I have cut two released of vizarr v0.1 and v0.2, which will handle the old specification, and we can migrate a new version to mirror the current spec. Since OME-Zarr is still being developed, I'd like the current version of vizarr to be free of backward compatibility constraints.

@manzt manzt force-pushed the multiscale-grid branch from 4fabd92 to db54860 Compare March 8, 2021 23:44
@manzt manzt changed the title [WIP] Experiment with multiscale grid [wip] Experiment with multiscale grid Jul 22, 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.

2 participants