Affine matrix in MONAI is somehow wrong

[wantinghuang]

Describe the bug
I compared the orientation of a NIfTI file using MONAI, Nibabel and Mango. I found that MONAI's affine matrix does not match Nibabel's as well as Mango's. Since Mango provides correct result, let's just focus on Mango. In this case, I am pretty sure that MONAI is wrong with the (plus-minus) sign of first orientation (first row of affine matrix).

To Reproduce
To attach a NIfTI file here, I would like to put this NIfTI file on google drive, which I assure that it is safe to download. To open this NIfTI file with MONAI, I wrote the following (pseudo) code
from monai.transforms import LoadNifti
loader = LoadNifti(dtype=np.float32)
img, metadata = loader(<the path of this image.nii>)
print('img affine\n', metadata['affine'])
Then open this NIfTI file with Mango and use hot key: ctrl+i to see the summary info of nifti file.

Expected behavior
I expected the (plus-minus) sign of first three values of the diagonal of affine matrix from MONAI to be the same as data orientation in mango.

Screenshots
Using the above code, it will print the following result

Opening this nifti file, we will see such info (please notice the Data orientation in summary column.)

Environment (please complete the following information):

• OS: Ubuntu 18.04.3 LTS
• Python version: Python 3.6.9
• MONAI version [e.g. git commit hash]: 0.1.0
• CUDA/cuDNN version: 10.2
• GPU models and configuration: did not use GPU in this case
• Nibabel version: 3.0.0

Additional context
This nifti file is transformed from a DICOM file using dcm2niix.

[Nic-Ma]

Hi @wantinghuang ,

May I know the difference between Nibabel and Mango results?
MONAI should be similar to Nibabel.
Thanks.

[wantinghuang]

Here is the info in Mango

and here is the affine matrix using Nibabel

in this case, the z-orientation is somehow broken. As a result, I am surprised that MONAI gets it right. But for x-orientation, MONAI seems to get it wrong. I have looked into the source code of affine matrix algorithm in Nibabel and MONAI, these two algorithms seem to be different.
FYI, my pseudo code of getting affine matrix using Nibabel is somewhat like this
img = nib.load(<the path of this image.nii>)
print('img affine in nibabel\n', img.affine)

Thanks for your reply :D

[Nic-Ma]

Hi @wantinghuang ,

Thanks for your detailed information.
I tried to download your image, can't open the google drive link. But I think:

1. If the header information of Nifti file doesn't match each other, MONAI will correct them:
   https://github.com/Project-MONAI/MONAI/blob/master/monai/transforms/io/array.py#L64
   This may be the reason for your problem, could you please help double-check your image?
   Or try to load another Nifti image from any other dataset?
2. Seems your test code for Nibabel uses wrong variable caimg instead of img:

img = nib.load(<the path of this image.nii>)
print('img affine in nibabel\n', caimg.affine)

Thanks.

[wantinghuang]

Hi @Nic-Ma ,

1. Here is another loading point via dropbox (nifti file); however, Google drive loading point still works with me. Also, I traced the source code and found that the affine matrix MONAI provided comes from img_nii.get_qform()(source code). The problem here is that the choice of qform affine seems to be wrong with respect to x-orientation but right with respect to z-orientation. Given the answer provided in Data Orientation in Mango, what is the secret here?
2. Oops, sorry my bad. I pasted the wrong snippet and now modified it to the right one.

Thanks

[wyli]

thanks @wantinghuang I can access the file and dig into the issue as well.

TL;DR: the header specification of MASK_image.nii is ambiguous/wrong.

this is verified by loading it with both FSLeyes and ITK-SNAP

since it's ambiguous, the best guess of the affine (here means the transformation between image and physical space) provided by nibabel is

array([[  -0.27734375,    0.        ,   -0.        ,   51.86132812],
       [  -0.        ,    0.27734375,   -0.        ,  101.63867188],
       [   0.        ,    0.        ,    0.        , -148.25      ],
       [   0.        ,    0.        ,    0.        ,    1.        ]])

this is from the sform, which partly provides the orientation information, but it doesn't match the voxel size (0.27734375, 0.27734375, 3.)

the best guess is still ambiguous and doesn't work for the preprocessors in MONAI. So the MONAI loader then falls back to the second-best guess which is from the qform, img_nii.get_qform() (even though the header's qform_code is 0, which indicates "qform not in
use")

Mango displays "Data orientation: slices (Z-)", it implies that Mango interpreted the third row of the affine [0., 0., 0., -148.25] as [0., 0., a_negative_value, -148.25]. this is arguably wrong as well

[wantinghuang]

Hi @wyli,
thanks for your thorough response.
I agree that the header of this file is ambiguous. Mango somehow guessed all orientation right.
I am closing this issue.