[wip] Experiment with multiscale grid

[manzt]

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]

demo: https://deploy-preview-80--vizarr.netlify.app/?source=https://s3.embassy.ebi.ac.uk/idr/zarr/v0.1/plates/2551.zarr

[will-moore]

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]

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.