Closed elevans closed 1 year ago
Base: 76.05% // Head: 77.40% // Increases project coverage by +1.35%
:tada:
Coverage data is based on head (
799113d
) compared to base (bffc2d7
). Patch coverage: 92.96% of modified lines in pull request are covered.
:mega: 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
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
I'm working on using xarray's global attribute's to store imagej/pyimagej specific metadata like the scale and CalibratedAxis
type. See the axis-scale-logic branch for more details. The way things are going it seems this will be our preferred way to assign CalibratedAxis
types. Thus I think we should scrap the scale work I've done here (i.e. _compute_scale()
etc...).
Me again! I have reverted the dims.py
module to a near original state. The difference from main
is:
_validate_dim_order()
function which allows users to pass dimension lists that are smaller than the size of the data. The unknown dimensions are then populated with dim_n
where n
is incrementing. This allows us to label unknown dimensions in the same way as xarray.numpy.ndarrays
or xarray.DataArrays
with a singleton dimension. If a singleton dimension is in the data we simply assign scale=1 for the axis. Without this hack you hit an index error when trying to do the scale math. See below for more details.I have a nice metadata solution and a rework on how we assign axes for xarrays <-> datasets. That work is still in progress (almost done) on this branch/PR: https://github.com/imagej/pyimagej/pull/247
The reason I originally added the work with axis scales was because I discovered a bug when creating more tests for the dim_order
kwargs. When converting a numpy.ndarray
or an xarray.DataArray
that has a singleton dimension (i.e. one or more axes is size 1) we run into an index error when trying to perform a subtraction between the first and second elements of the axis/scale array here: https://github.com/imagej/pyimagej/blob/a5544fa07a1b3652c2c0037afbbd07e0f5d32add/src/imagej/dims.py#L277-L289
From what I gather this rather serious bug has been here the entire time. Here is how you can reproduce it on main
:
import numpy as np
import imagej
ij = imagej.init()
nparr = np.random.rand(1, 2, 3, 4, 5)
# index error
ds = ij.py.to_dataset(nparr)
I think no one has ran into this yet (or very few people have) because when you slice an array to a singleton dimension its usually squashed. But anyone who is making an array with a singleton dimension will hit this bug when converting to a Dataset
.
This pull request enables
dim_order
kwargs for the direct image converter methods:to_dataset()
,to_img()
, andto_xarray()
. It also adds tests for this new feature intest_image_conversion.py
and some additional features. There are also a couple of bugs/enhancements I made (e.g. we now calculate the slope for linear axis using all points instead of the first two elements of the scale array).To get a good idea on the
dim_order
kwarg option and how it works with the direct image converters, check out the new section I wrote in the docs (06-Working-with-Images
, section 6.9). There is a nice table that outlines the image conversion behavior with or withoutdim_order
supplied.changes
dim_order
kwarg for direct image converions (to_dataset()
,to_img()
,to_xarray()
).dim_order
kwargsReplaced(see latest comment)imagej.dims._get_scale()
withimagej.dims._compute_slope()
.dim_order
lengths that are shorter than the length of the array. Unknown dims are assigneddim_n
like xarray.dim_order
.