feat: Support Zarr v3 (Replace zarr.js with zarrita.js)

[manzt]

Experiment to replace zarr.js with zarrita.js. Should support v3 data (including sharding, although I don't have any NGFF datasets to test).

Need to figure out how to handle loading v3 vs v2. Right now it will try v3 first and fallback to v2. Maybe another query parameter to indicate which?

• demo: https://deploy-preview-172--vizarr.netlify.app/?source=https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.1/6001253.zarr

cc: @normanrz

[normanrz]

Hi @manzt, great to see zarrita in vizarr!
I was just trying with one of our sharded datasets: https://static.webknossos.org/data/zarr_v3/l4_sample/color/1 (data starts at 3072, 3072, 512). They don't have OME metadata yet but each zoom level should be accessible individually. I get an error Error: Store does not support range requests. Looks like the FetchStore is wrapped somehow.

[manzt]

Ah you are right. Fixed that, but now I'm seeing a CORs error can cant seem to request the zarr.json for the resource. I should note that Viv/Vizarr doesn't current support multiscale 3D or I'm actually not sure what the behavior of 3D chunking is for non multiscale.

[normanrz]

Thanks! CORS shouldn't be an issue for https://static.webknossos.org/data/zarr_v3/l4_sample/color/1/zarr.json. It has Access-Control-Allow-Origin: *.

I should note that Viv/Vizarr doesn't current support multiscale 3D or I'm actually not sure what the behavior of 3D chunking is for non multiscale.

An individual zoom level should work, no?

I am now running into an infinite loop when calling this URL: https://deploy-preview-172--vizarr.netlify.app/?source=https://static.webknossos.org/data/zarr_v3/l4_sample/color/1&viewState={%22zoom%22:null,%22target%22:[512,3200]}

Fyi, I already changed the endian codec to bytes in that demo dataset.

[manzt]

An individual zoom level should work, no?

I believe so! Just wanted to clarify the multiscale 3d.

[manzt]

I am now running into an infinite loop when calling this URL: https://deploy-preview-172--vizarr.netlify.app/?source=https://static.webknossos.org/data/zarr_v3/l4_sample/color/1&viewState={%22zoom%22:null,%22target%22:[512,3200]}

Hmm sorry about that. Not sure what is going on. Still running into a CORs issue. Not sure what is going on:

Fyi, I already changed the endian codec to bytes in that demo dataset.

Ah, need to make the changes in zarrita.

[normanrz]

Hmm sorry about that. Not sure what is going on. Still running into a CORs issue. Not sure what is going on:

That might be related to running on localhost and/or with http. On netlify there is no CORS error.

[manzt]

Sorry, haven't had the chance to look into this more closely! I'm getting a CORS issue, even with netlify (maybe it's my browsers?).

[normanrz]

I think I found the loop. I can now load some data!
I am now seeing this. Don't know where the 3 columns come from. Also, every other pixel row is black 🤔

link: http://localhost:5173/?source=https://static.webknossos.org/data/zarr_v3/l4_sample/color/4-4-1&viewState={%22zoom%22:-1.3672083119408038,%22target%22:[1025.0874317577027,647.57615049587]} (1: 925)

[manzt]

I think I found the loop. I can now load some data!

Awesome. Thanks for finding the bug!

I am now seeing this. Don't know where the 3 columns come from. Also, every other pixel row is black 🤔

Ah, I'm fairly certain this is coming from us using zarr chunk API directly (and some assumption about non x/y chunks being 1). #60 (comment). I probably won't be able to dig in for a couple of weeks, but a first thought would be that we could try to "rechunk" within the store to play nicer with Viv.

[joshmoore]

although I don't have any NGFF datasets to test

https://deploy-preview-36--ome-ngff-validator.netlify.app/?source=https://minio-dev.openmicroscopy.org/idr/v0.5-dev2/6001240.zarr ? (from ome/ome-ngff-validator#36)

[will-moore]

I also tried creating a sharded example at https://deploy-preview-36--ome-ngff-validator.netlify.app/?source=https://minio-dev.openmicroscopy.org/idr/v0.5-dev2/6001240_sharded.zarr but that isn't yet being loaded successfully by zarrita.js in that validator branch (whereas the non-sharded v3 data that Josh linked to is loading fine).
Need to look into that a bit more...

[joshmoore]

@manzt: is there anything that would help in the way of test data, etc.?

[manzt]

I'm sorry I've been quiet on this... my talk at SciPy is today and then I'll be relaxed and excited to zarr after :)

[joshmoore]

np. Knock 'em dead! 👊🏽

[manzt]

Did the multiscales metadata move under ome key in v0.5?

EDIT: Ahh, it looks like all the ome metadata is under ome now... sorry i've been away !

[manzt]

I think I got this to a working state. I've been trying out with some sample images here, but I don't have many for v3. Would any of you be able to have a look?

[manzt]

@normanrz I removed the zarrita -> zarr.js adapter stuff and now we have a pure zarrita pixel source for viv. This should allow better composition with the rest of zarrita and better footing ofr the future of vizarr.

[joshmoore]

https://deploy-preview-172--vizarr.netlify.app/?source=https://minio-dev.openmicroscopy.org/idr/v0.5-dev2/6001240.zarr&viewState={%22zoom%22:2.0591035203448826,%22target%22:[135.5,137.5]} 🎉

[manzt]

I'm running into some issue with the plates but once I get that resolved I'll merged and make a release (v0.4).

[joshmoore]

I'm running into some issue with the plates but once I get that resolved I'll merged and make a release (v0.4).

I'll need to double check what got released, @manzt, but the much of the "0.5" data that is flying around right now is all -dev, i.e. we're in a pre-release state.

[manzt]

Ok,then similarly i'll keep vizarr in a prerelease state.

[joshmoore]

What URL should we use for that period? cf. ome/ome-ngff-validator@3a1ecfb

[manzt]

So currently https://hms-dbmi.github.io/vizarr points to whatever is on main (so that should be fine). We then cut versions under https://hms-dbmi.github.io/vizarr/v0.1, etc. I'm very open to other ideas for versioning / deployment.

[joshmoore]

I'm very open to other ideas for versioning / deployment.

Guess there's a 2 version number issue here. If main only ever gets support for released specs, then this works. Otherwise, we might need a dev/ in there somewhere.