Zarr reading and writing support

[Rylern]

This PR adds the possibility to open Zarr images.

This can be done by clicking on File->Open URI..., and writing the path to the Zarr directory. Dragging the directory to QuPath or using File->Open doesn't work. Should I improve this?

[alanocallaghan]

Let me know when this is tested on different platforms so I can do a non-snapshot blosc release

[Rylern]

It works on Linux, Windows, and Mac with Apple Silicon. So the only remaining OS is Mac on Intel

[petebankhead]

This is huge! I should be able to try it on an Intel Mac - is there a link to any good test image?

[Rylern]

Yes, here: https://oc.embl.de/index.php/s/0TPPw4CUt0G6nng

[petebankhead]

Works for me on an Intel Mac!

This can be done by clicking on File->Open URI..., and writing the path to the Zarr directory. Dragging the directory to QuPath or using File->Open doesn't work. Should I improve this?

Yeah, we'll need to provide a nicer way to open the images or add to a project - ideally including a drag & drop option.

Will take a bit of thought to figure out how to do it. Maybe we need an 'Open image directory' option? But then people might assume that it opens all the images in a directory (which, I suppose, it something it could do...).

DICOM is also a more recently-relevant format that our current 'open / add' mechanism doesn't support well: #1397

So we should probably think about both together - probably as a separate PR.

[Rylern]

About commit a7b184f:

In Zarr files (or at least in the Zarr files I have), the z values are scaled with the resolution. This means that if there is an image of shape (t: 10, c: 20, z: 30, y:40, x: 50) at full resolution, it will have a shape of (t: 10, c: 20, z: 15, y:20, x: 25) with a downsample of 2 (and not (t: 10, c: 20, z: 30, y:20, x: 25)).

This means that in the BioFormats IFormatReader.getIndex(z, c, t) function, z can only take values between 0 and 15 (and not 30) when called for the image of downsample 2.

I'm not satisfied with this commit because it's ugly and assumes every Zarr files scale the z values with the resolution (which I was not able to find if it's the case in the OME-ZARR specs).

[petebankhead]

Ah, yes that does seem to be a significant complication... have you seen this? ome/bioformats#3794

If we were able to support 2D pyramidal Zarr in QuPath v0.6.0 that would already be a major step forward (especially if we can write as well) - and we could delay worrying about multiresolution z until we switch to ImgLib2 and (most likely) an entirely new viewer.

[alanocallaghan]

Great, shall I push out a proper release of the blosc jar, then?

Will take a bit of thought to figure out how to do it. Maybe we need an 'Open image directory' option? But then people might assume that it opens all the images in a directory (which, I suppose, it something it could do...).

Both useful, but should be distinguished semantically in some way

[Rylern]

If we were able to support 2D pyramidal Zarr in QuPath v0.6.0 that would already be a major step forward (especially if we can write as well) - and we could delay worrying about multiresolution z until we switch to ImgLib2 and (most likely) an entirely new viewer.

OK, so should I remove the last commit?

Both useful, but should be distinguished semantically in some way

I may be missing something obvious, but can't we just allow the File->Open window to open files AND directories?

[alanocallaghan]

I may be missing something obvious, but can't we just allow the File->Open window to open files AND directories?

My feeling is that mixing the two behaviours could lead to weird or unexpected behaviour if eg I open a directory that contains zarr(s)

[petebankhead]

I think in JavaFX we can only have a file or a directory chooser... and you need to select the right chooser since they can't be mixed (at least on macOS - it might be platform-dependent).

Haven't checked out the last commit yet...

[Rylern]

I improved the z-stack handling as we discussed yesterday @petebankhead

[petebankhead]

I don't know if ipReader.setResolution is expensive. In case it is, we should try to avoid calling it.

• Here, I think you can put this block before the initial ipReader.setResolution(level) and include that in an else (since this block set the resolution to the level at the end anyway).
• You can also use if (level > 0 && z > 0) since otherwise it shouldn't matter

[petebankhead]

Should this be round or floor? My intuition says round but my intuition isn't certain...

Also, it would be useful to look at the number of z slices for different levels in the sample images you have access to. It might be possible to compute the ratio between the z slices for a level and the zero level, to determine how much to rescale the z index (which might be more robust than using the downsample value, in case it's possible that the downsampling in z uses a different factor).

[Rylern]

I tried to use round but I got an error when z / tileRequest.getDownsample() was giving something like 133.5, which turned into 134 after applying round, when the max possible value was 133.

[Rylern]

I addressed the two issues