I fully agree that conceptually we should use 4x4 homogenous matrix, which defines transformation from IJK to LPS coordinate system. This is what ITK does, too (it just stores the information in several variables).
I don’t mind if IJK to RAS matrix is stored as a single 4x4 matrix or separately (as origin vector, spacing vector, and axis directions 3x3 matrix). Adding just a direction matrix would be more similar to the current implementation, that’s why it seemed to be an obvious choice, but if we all agree that matrix format is used much more often (I would think so) then it would be a good opportunity to change it now.
image->GetMatrix() would be quite ambiguous, as it would not even tell the what is the from and what is the to coordinate system. I would choose a name that indicates the transformation direction, such as GetIJKToXYZMatrix, GetIndexToPositionMatrix(), GetVoxelToWorldMatrix(), or something similar.
It is up to us to decide, but we should make a clear decision now, so code review and update of all existing image filters are done accordingly.
Pro:
- It would be convenient to allow storage of some acquisition transformations could be accommodated there
- Certain simple pipelines (that all use filters that can handle non-orthogonal direction matrix) could run on sheared images, without the need to handle shearing transformation separately
Con:
- We cannot store all acquisition transformations there anyway (e.g., varying slice spacing cannot be handled)
in the acquisition (because then some transformations, such as tilted-gantry acquisitions - Each filter would need to declare if it can deal with non-orthogonal, non-right-handed, maybe even non-homogenous, etc. 4x4 transforms
- We would need to add consistency checks (more code, some extra computations, and potential source of errors)
Allowing non-orthogonal direction have advantages in the long term, it is just not clear if we can deal with the extra effort that requires for it in the short term. If I had to choose between having orientation matrix restricted to be right-handed orthogonal, or not having orientation matrix support at all; I would definitely go with the restricted option.