Implement xarray <-> dataset #56
Conversation
|
@thewtex the capitalized convention (X, Y, Z) is what ImageJ currently uses. I can fairly simply implement a check to auto-convert X <-> x for the xarray/python conventions, but I don't know if that would be confusing to have them different in ImageJ and in python. I'll take a shot at it and then we can reassess. @ctrueden, do you have an opinion on this? |
In general, I am a fan of the "when in Rome" rule of development, as long as it does not conflict with the principle of least astonishment. We should try to match conventions in cases where it is practical. We can certainly have a set mapping from all the |
|
I've implemented the requested change. Now |
Thanks! |
| :param xarr: xarray that holds the units | ||
| :return: A list of ImageJ Axis with the specified origin and scale | ||
| """ | ||
| axes = ['']*len(xarr.dims) |
There was a problem hiding this comment.
If you're bored, consider using a linter (flake8? black? I don't care, but it would catch things like this).
This new convention supports bi-directional conversion between xarrays and datasets, under the assumption that an xarray is an image. Currently, this does flip the axes order for C-style (default) indexed xarrays, as Java uses F-style indexing. This behavior conforms to the current status for regular numpy arrays. Right now the conversion also assumes that the axes are linear, such that the axes can be defined with just an origin and a scale (aX + b). Any non-numeric axes labels are currently lost (e.g., if you have coords of [R, G, B] they become [0, 1, 2] upon conversion)
The check fails for the case of float values of the coordinates, e.g. 0.05, 0.1, 0.15, due to inexact representation of floating point arithmatic. A diff on that access will yield results that are slightly different, e.g. 0.10000002 and 0.99999998. As such, I am removing this check for now to reconsider alternate implementations.
The get_axes_coords function used to use a hard coded equation to calculate coordinates on a linear scale. The Java CalibratedAxis already has this functionality with the calibratedValue() function, which is general to any scale rather than specific. This change.
The numpy convention places the channel axis at the third axis, despite operating on the c-style slow-axis first. Java also places channel as the third axis for 2d RGB images, where possible, so this location should not be flipped. This check makes sure that 2D RGB images (e.g., [y, x, c] or [X, Y, C] maintain c as the last channel.
This generalizes the 2D-RGB commit to nd images, wherever the channel is the last commit.
This allows us to have arbitrary values for axis coordinates. This is not quite as good as having the appropriate axis type, because the interpolation is linear, but allows us to preserve coordinates at discrete points when going between datasets and xarrays.
This change now uses separate assert functions for a couple of the tests so that they do not repeat lines. This will make it easier to redo tests in the future.
This commit adds synchronization functions for moving between IJ1 and IJ2 as well as attendant tests. The tests currently require hard setting a fiji dir and setting headless off, due to using a local version of imagej for testing. This will be fixed in a future commit.
This refactoring allows the use of fixtures and the the --ij and --headless flags.
The EnumeratedAxis is a new axis made for releases of imagej-common later than March 2020. This fix defaults to a LinearAxis if the Enumerated Axis is not available, thus making the interfaces work on older versions of imagej.
This will try headless testing on Travis, though it removes the osx tests because osx does not have gui support.
|
The Travis CI build did pass, even if GitHub still sees it as pending. So here goes with the merge! 🚀 |
|
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/installing-simpleelastix-in-python/71959/19 |
These changes address issue #17.
This new convention supports bi-directional conversion between xarrays and datasets, under the assumption that an xarray is an image.
Currently, this does flip the axes order for C-style (default) indexed xarrays, as Java uses F-style indexing. This behavior conforms to the current status for regular numpy arrays.
Right now the conversion also assumes that the axes are linear, such that the axes can be defined with just an origin and a scale (aX + b).
Any non-numeric axes labels are currently lost (e.g., if you have coords of [R, G, B] they become [0, 1, 2] upon conversion)