xarray.DataArray imagej metadata and improved axis/scale logic
#247
Conversation
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #247 +/- ##
==========================================
- Coverage 76.95% 76.82% -0.14%
==========================================
Files 16 18 +2
Lines 1870 1963 +93
==========================================
+ Hits 1439 1508 +69
- Misses 431 455 +24
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
hinerm
force-pushed
the
axis-scale-logic
branch
from
7930a24
to
969f7ab
Compare
|
@elevans Is this ready for review now? Or are you still working on it? |
|
I'm still working on this actually. There are a few changes I want to add that I was planning to complete on my flight back home from Japan! |
|
I'm converting this PR back to a draft as it needs some re-working again before its ready for review again. |
This function creates a metadata dictionary meant to be stored in a newly created xarray.DataArray's global attributes. The initial metadata created stores scale type of the axis (linear, enumerated or none).
This commit changes how the linear and enumerated axes are assigned. We now look for the "imagej" key in the xarray's global attributes. If the key is present we look for dim + "_axis_scale" to assign linear or enumerated axes.
Although the only calibrated axes used by nearly everyone are DefaultLinearAxis and EnumeratedAxis, I added metadata support for all CalibratedAxis types (e.g. PolynomialAxis etc...) just to be thorough. This metadata will be used for matching the Calibrated Axis type when going back to ImageJ/Java land.
This commit refactors dims._assign_axes() to use imagej specific metadata attached to a given xarray.DataArray. If the "imagej" attribute is present in the xarray's global attributes then information like scale, origin and the type of CalibratedAxis (e.g. DefaultLinearAxis, EnumeratedAxis, etc...) can be used to assign the correct calibrated axis per given dimension during the net.imagej.Dataset conversion process. If the desired calibrated axis is not available or the axis is unknown then we fall back to a DefaultLinearAxis and attempt to get scale/origin data from the coordinates.
The new "imagej" metadata attribute may not always be present (depending on the origin of the xarray). Checking for all attributes makes this kind of hard, so lets just check for the key we put in!
If a singleton dimension is detected, assign a scale/slope of 1.
This commit adds a new metadata submodule to handle all image related metadata functions (e.g. creating/updating the xarray.DataArray metadata attribute). All metadata related functions should exist in this submodule.
Gabe suggested using a nice one-liner to get the CalibratedAxis from the dict instead of the if/else statement.
The axis submodule has also been streamlined to drop the CalibratedAxis dict and instead uses a list of Strings. This avoids Java import errors if a user imports the axis submodule before initializing ImageJ.
elevans
force-pushed
the
axis-scale-logic
branch
from
adbc6c5
to
56ca272
Compare
The docstring wasn't clear about what kind of string to send to and from the calibrated axis helper functions.
The axis data are stored in the scifio.metadata.image map under the "axes" key. Converting this to a string is unecessary.
This commit uses the metadata module to create the metadata for both xarray and java images. Images can now be transferred back and forth between Java and Python without loosing the metadata.
I missed this one :(.
|
I have unfortunately been busy putting out other fires and I haven't had a chance to really get this PR off the ground to where it should be in my opinion. But my time away has allowed me to think more about how to tackle this problem. So far the work I've done creates a fancy dictionary that gets attached to the Having said all that I think moving forward the best approach is to subclass the EDIT: After doing some reading the xarray team discourages subclassing |
This module contains the xarray accessors that extend the xarray.DataArrays with additional methods. This module must be imported before the accessors are found. No other code is needed to attach these accessors.
Once the metadata has been set call the tree() method to print a dict tree.
This preserves the metadata dict between slices.
The _update() method runs any time the MetadataAccerssor is accessed. This allows us to update the metadata base by checking the state of the backing xarray.DataArray. So for example if dimensions change order or are dropped the "scifio.metadata.image" (if present) metadata should reflect these changes where appropriate.
The axes were still in ImageJ order. They now match and check against the dimension order of the parent xarray.DataArray. Note that the metadata must be updated manually after creation to update the order from Java to Python.
Use the MetadataAccessor class of the xarray to assign the correct axes. Fallback to a DefaultLinearAxis if the metadata is not available.
This is no longer in needed.
This PR improves how we assign the imagej
CalibratedAxissubclass of a given axis when converting anxarray.DataArrayto anet.imagej.Dataset. Currently onlyDefaultLinearAxisandEnumeratedAxisare supported, withEnumeratedAxisbeing preferred if available. This behavior can be problematic as some projects expect to see aDefaultLinearAxisinstead of anEnumeratedAxis. This PR changes this behavior, by assigningDefaultLinearAxisas the default axis unless the associatedimagejmetadata indicates otherwise. For more specific details check out this change log:imagejmetadata attribute toxarray.DataArrays that are made via PyImageJ (i.e. results fromij.py.to_xarray()andij.py.from_java()). Theimagejmetadata attribute is a dictionary that contains per axis information such asscale,originand theCalibratedAxissubclass type.CalibratedAxissubclasses such asPolynomialAxis. Even though these are not used (as far as we know) by any plugins/projects the I thought it was best to be thorough and include all the subclasses. The refactoring I did forimagej.dims._assign_axes()made this addition easy.imagej.dims._assign_axes()(now uses theimagejmetadata attribute if present to get axes information).