Each napari Layer has a metadata dictionary attribute, which I believe is intended to be a a somewhat arbitrary key/value store for users/plugins. We can use this to store the metadata attributes that we're interested in, which has a few benefits.
We can store the original metadata values, which allows us to implement the revert to original values.
We can store layer-specific metadata attributes that in napari are currently viewer-wide (e.g. axis names). Though we still have to work out what to do with mixed names.
We can implement reader/writer contributions that rely on these data being present.
Part of this work requires us to define an internal schema to store these metadata. We should probably rely on an existing schema (like the one used for OME-NGFF metadata), but may need to add to it to accommodate other attributes that are unique to this project.
The schema does not need to be complete as part of this work, but should contain the essential attributes we care about.
One danger of this approach is that Layer.metadata might already contain data or may be modified. Therefore, part of this work is to put the data in a relatively safe namespace and also to observe to Layer.metadata being reassigned.
Another part of this work is to do something sensible when this plugin's metadata attribute widget values change. At a minimum the values in the dictionary should be updated from the widgets. We may also want to handle the other direction (i.e. values changing in the dictionary causing widgets to update), even if it's just using a refresh method to repopulate them all.
Finally, given this feature allows us to make all metadata attributes layer-specific, we may want to define some logic that handles what happens to the current corresponding viewer-wide state (e.g. axis names, units). If that's turns out to be complex, we can handle that in a separate task.
Description
Each napari
Layerhas ametadatadictionary attribute, which I believe is intended to be a a somewhat arbitrary key/value store for users/plugins. We can use this to store the metadata attributes that we're interested in, which has a few benefits.Part of this work requires us to define an internal schema to store these metadata. We should probably rely on an existing schema (like the one used for OME-NGFF metadata), but may need to add to it to accommodate other attributes that are unique to this project.
The schema does not need to be complete as part of this work, but should contain the essential attributes we care about.
One danger of this approach is that
Layer.metadatamight already contain data or may be modified. Therefore, part of this work is to put the data in a relatively safe namespace and also to observe toLayer.metadatabeing reassigned.Another part of this work is to do something sensible when this plugin's metadata attribute widget values change. At a minimum the values in the dictionary should be updated from the widgets. We may also want to handle the other direction (i.e. values changing in the dictionary causing widgets to update), even if it's just using a
refreshmethod to repopulate them all.Finally, given this feature allows us to make all metadata attributes layer-specific, we may want to define some logic that handles what happens to the current corresponding viewer-wide state (e.g. axis names, units). If that's turns out to be complex, we can handle that in a separate task.