Handle Z-downsample.

[will-moore]

This uses the fix suggested by @manzt at #60 to handle Pyramids where each level is downsampled in Z (as well as X and Y).

I have also overridden ZarrLoader.getRaster() as well as getTile().

In addition to the suggested fix, I also needed to set the selection[zIndex] to be within the bounds of shape[zIndex] for the current resolution level.

This doesn't change the vizarr UI. The Z-slider still has the full number of steps, even when you're viewing a resolution level that has a smaller number of Z-sections. E.g. if the downsample factor in Z is 2, then level 1 will have size-Z / 2 and the image will only change for every 2 steps of the Z-slider (although we load the data each time) which is not optimal but I don't know how to update the size-Z and Z-slider while you're zooming from one resolution to the next, and at least this works.

Tested with data generated as at ome/ome-zarr-py#71 (comment)
I'll try and get that data to be publicly available for testing ASAP.

[manzt]

Cool to see progress on this!

I'll try and get that data to be publicly available for testing ASAP.

Looking forward to it!

[will-moore]

Sample data is available at https://minio-dev.openmicroscopy.org/idr/idr0077-valuchova-flowerlightsheet/zscale_01/9836831.zarr/zscale

Same data without the Z-downsampling is at https://minio-dev.openmicroscopy.org/idr/idr0077-valuchova-flowerlightsheet/zscale_01/9836831.zarr

[ilan-gold]

@manzt @will-moore A question - will there be any way to distinguish between the downsampled-in-z version of a dataset and the non-downsampled version? The shape of the zarr array, I presume? But will there be any metadata about it? Just curious.........

[will-moore]

@ilan-gold Good question, thanks. But all still to be decided....
I created an issue at ome/ngff#25 to track the suggestions / discussion on this.

[will-moore]

Now that the build is passing, this is deployed at https://deploy-preview-71--vizarr.netlify.app/?source=https://minio-dev.openmicroscopy.org/idr/idr0077-valuchova-flowerlightsheet/zscale_01/9836831.zarr/zscale cc @joshmoore

[ilan-gold]

Seems like the background image to the mutliscale image is a problem here @will-moore @manzt. One option would be a parameter for allowing you to turn off the background image, but it feels like it should be resolvable from the loader itself as well.

[manzt]

One thing I'm noticing in the demo is that moving the z-slider while zoomed in seems to load data for a lower resolution. I'm not sure what's going on exactly.

Screen.Recording.2021-01-18.at.9.57.10.PM-1.mov

[will-moore]

@manzt I'm also seeing the loading of low-resolution data before these Z-downsample changes. E.g.
https://hms-dbmi.github.io/vizarr/?source=https://minio-dev.openmicroscopy.org/idr/idr0077-valuchova-flowerlightsheet/zscale_01/9836831.zarr
For every change in Z, I see the lowest resolution loaded (3 chunks) as well as the current resolution.
I think that it's getRaster() that is loading the lowest resolution for each new Z.
Sometimes in your video (and I see the same), some chunks never seem to load, so you are left viewing lower-than-expected resolution. But this is transient and tricky to pin down.
(NB: ebi.embassy server is giving net::ERR_CERT_REVOKED errors just now, so our standard demo data is not working).

[ilan-gold]

@will-moore @manzt If it's the background image that is giving you issues, we recently released the option to turn it off in MultiscaleImageLayer with the excludeBackground prop

[manzt]

@will-moore hmm. This is very odd. I'm wondering there is something going on with z in the loader selection (meaning z axis) and the z pyramidal level. Hopefully I'll have the time to look this over soon.

For every change in Z, I see the lowest resolution loaded (3 chunks) as well as the current resolution.
I think that it's getRaster() that is loading the lowest resolution for each new Z.

I'm guessing this is right. I'll have to look closer.

[manzt]

Our loaders have diverged a bit since this PR. We are not experimenting with this in Viv so I'm going to close: hms-dbmi/viv#478. Thank you for pushing this effort forward!