Confusing representation of "space direction" #148
Comments
addisonElliott
added a commit
that referenced
this issue
Nov 5, 2024
…ption (#157) ## Changes * Add `int vector list` and `double vector list` datatypes that are lists of Numpy arrays or `None`. * These new types are similar to their `int matrix` and `double matrix` counterparts except they are **not** 2D Numpy matrices. * Add `nrrd.SPACE_DIRECTIONS_TYPE` to enable switching the datatype for the `space directions` field. * Valid options are `double matrix` or `double vector list`. The current default is `double matrix` for backwards compatibility but will be switched to `double vector list` in the next major release. * `double vector list` is superior over `double matrix` because it doesn't have the confusing row-of-NaN's representation and it doesn't imply an affine transform by being a matrix. * Support row-of-None in addition to row-of-NaN for `parse_optional_matrix` & `format_optional_matrix` in addition to new vector list parsing/formatting functions Fixes #148 Revises #149
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I've recently been working with MONAI that optionally uses pynrrd to read .nrrd and has an error when handling the space direction.
The way the variable space direction is read by pynrrd (in the 3d case as a 3x3 matrix) makes it easy to misinterpret as the upper left 3x3 part of the affine matrix (this is what is done in MONAI).
However, the matrix loaded by pynrrd is the transpose of the upper left 3x3 part of the affine matrix.
Loading the space direction variable to a matrix might cause this confusion, an alternative would be to instead load it as a list of vectors.
The text was updated successfully, but these errors were encountered: