Although the created geometry is a non-image geometry, it's origin is left in the (0, 0, 0) mm position, and the bounding box lower bounds are negative to compensate this. Moreover, the spacings are not permuted according to order of the input geometry axes, therefore the upper bounds are also incorrect if the input geometry is an image with anisotropic voxels.
- Mentioned In
- T22254: Render windows show *not* the corresponding orientation after reinit with permuted axes
rMITK040cec8b21e0: Merge branch 'T20218-rebased' into releases/2016-11-beta
rMITK131bb4f0f110: Merge branch 'T20218-DataStorageGeometryComputation'
rMITKf832926f360b: Merge remote-tracking branch 'NifTK/T20218-compute-geometry-3d-fixes' into…
T17812: SlicedGeometry3D initialisation fix for non-image geometries
As soon as we have an image spacing other than 1, we have indeed an error in our calculations. Everything else seems to be the difference between object space and global space, which is why the missing offset was "okay", though.
The calculation in your fix is correct.
We still have to check the permuted thingy, though.