Currently, ConfUSIus accepts 2D DataArrays, e.g. (y, x) in almost all modules. This is fine for most cases, but can be a problem for registration, where the computed transformed will be 2D, and can't be applied to 3D volumes. This means that registering a 2D DataArray to e.g. one of our 3D templates will be difficult, as we won't have the information of the slice width. This can also be confusing for users that could perform a temporal average + squeeze on a (1, y, x) array before registration, leading to a 2D transform that can't be applied to other (1, y, x) without squeezing too.
For simplification, I think we should enforce that fUSI DataArray must be at least (z, y, x). This will make thinking about registration and physical location in atlas spaces more straightforward, and will ensure that the voxel dimension along the z-axis (typical slice dimension) is preserved.
Currently, ConfUSIus accepts 2D DataArrays, e.g.
(y, x)in almost all modules. This is fine for most cases, but can be a problem for registration, where the computed transformed will be 2D, and can't be applied to 3D volumes. This means that registering a 2D DataArray to e.g. one of our 3D templates will be difficult, as we won't have the information of the slice width. This can also be confusing for users that could perform a temporal average + squeeze on a(1, y, x)array before registration, leading to a 2D transform that can't be applied to other(1, y, x)without squeezing too.For simplification, I think we should enforce that fUSI DataArray must be at least
(z, y, x). This will make thinking about registration and physical location in atlas spaces more straightforward, and will ensure that the voxel dimension along the z-axis (typical slice dimension) is preserved.