-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add spec metadata #140
Add spec metadata #140
Conversation
Store both version and axes values
for more information, see https://pre-commit.ci
Codecov Report
@@ Coverage Diff @@
## master #140 +/- ##
==========================================
+ Coverage 71.04% 71.07% +0.02%
==========================================
Files 11 11
Lines 1126 1134 +8
==========================================
+ Hits 800 806 +6
- Misses 326 328 +2
Continue to review full report at Codecov.
|
"version", "0.1" | ||
) # should this be matched with Format.version? | ||
datasets = multiscales[0]["datasets"] | ||
# axes field was introduced in 0.3, before all data was 5d | ||
axes = tuple(multiscales[0].get("axes", ["t", "c", "z", "y", "x"])) | ||
if len(set(axes) - axes_values) > 0: | ||
raise RuntimeError(f"Invalid axes names: {set(axes) - axes_values}") | ||
self.metadata["axes"] = axes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding the same metadata to self
and node
feels a bit odd, like it may make other uses downstream less clear. It might point to the internals needing to be simplified/refactored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you're correct. Re-reading this I am unsure of what is supposed to be written there. I'll close and we can get back to this when we need it.
While trying to audit the existing NGFF samples, I tried to extend the
ome_zarr info
command to start displaying additional information such asversion
oraxes
.As it stands, the
ome_zarr.reader
module iterates through nodes, discovers specifications and register part of the metadata under theNode.metadata
dictionary. My understanding is that the specification of this metadata dictionary has been primarily driven by thenapari
use case (as the napari plugin used to be part of this repository). The metadata is appending , sometimes as key/value pairs(ome-zarr-py/ome_zarr/reader.py
Line 289 in 9a77877
ome-zarr-py/ome_zarr/reader.py
Line 523 in 9a77877
ome-zarr-py/ome_zarr/reader.py
Lines 254 to 259 in 9a77877
This dictionary cannot be used in its current form for a generic introspection of OME-Zarr dataset e.g. by
ome_zarr info
as the keys are not defined and the relationship to the specification is lost.857f4fb proposes one approach to solve this problem i.e. defining metadata at the
Spec
level rather than at theNode
level. Together with 857f4fb, a proof of concept can be run against the existing samples:An alternative approach would be to keep using the
Node.metadata
dictionary with a self-describing structure e.g.Independently of the chosen solution, I think we want to ensure some consistent metadata storage and migrate the logic of translating this metadata into the structure expected by
napari
into thenapari-ome-zarr
plugin.