Closed berombau closed 8 months ago
Thanks for the report. Your right, not good logic. For a fix, we could add another URL parameter here, say &imageName
:
https://github.com/Kitware/itk-vtk-viewer/blob/master/src/index.js#L220-L232
And when imageName
ends in .zarr, this becomes true:
https://github.com/Kitware/itk-vtk-viewer/blob/master/src/IO/toMultiscaleSpatialImage.js#L68
Can you give an example for a correct imageName then? Would it matter what's before the .zarr? How about changing this regex line here. The comment appears to support my use case already, as the images I want to view are subgroups of a SpatialData .zarr store. The regex in the code does not appear to do so. It was changed in this commit to support DANDI urls.
It can be something like [./]zarr\b
regexr, which should work I think.
Ah, just changing the regex would be nice. If you want to open a PR, I'll test and deploy. Otherwise I plan on touching code within a couple weeks.
(Thanks for the regexr link, very usefull.)
:tada: This issue has been resolved in version 14.47.1 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
Reading an OME-NGFF zarr store without the usual
.zarr
suffix (probably not best practice but they exist) result in an error:Can the reader logic be updated to support this? Or can an additional URL parameter be added like &use2D to specify the reader?