hms-dbmi / vizarr

A minimal Zarr image viewer based on Viv.
https://hms-dbmi.github.io/vizarr/?source=https://minio-dev.openmicroscopy.org/idr/v0.3/idr0062-blin-nuclearsegmentation/6001240.zarr
MIT License
114 stars 16 forks source link

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

Closed manzt closed 1 month ago

manzt commented 1 year ago

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?

cc: @normanrz

normanrz commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

An individual zoom level should work, no?

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

manzt commented 1 year ago

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:

image

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

Ah, need to make the changes in zarrita.

normanrz commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 🤔

Screenshot 2023-09-11 at 21 37 22

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 commented 1 year ago

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). https://github.com/hms-dbmi/vizarr/issues/60#issuecomment-738050060. 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 commented 2 months ago

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 https://github.com/ome/ome-ngff-validator/pull/36)

will-moore commented 2 months ago

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 commented 2 months ago

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

manzt commented 2 months ago

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 commented 2 months ago

np. Knock 'em dead! 👊🏽

manzt commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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]} :tada:

image

manzt commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

joshmoore commented 1 month ago

What URL should we use for that period? cf. https://github.com/ome/ome-ngff-validator/pull/36/commits/3a1ecfb288f20fc38dcda4319db4090860787b90

manzt commented 1 month ago

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 commented 1 month ago

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.