I’m sorry if this doubt is too basic, but I still can’t understand this error.
Basically, I am transforming one image to the space of another images like this:
flirt -dof 6 -cost normmi -in $path_S2/data_mnb0.nii -ref $path_S1/data_mnb0.nii -omat $path_S1/T_fsl.txt
transformconvert $path_S1/T_fsl.txt $path_S2/data_mnb0.nii $path_S1/data_mnb0.nii flirt_import $path_S1/S2_2_S1_transformation.txt -force
mrtransform -linear $path_S1/S2_2_S1_transformation.txt $path_S2/data_mnb0.nii $path_S1/data_mnb0_S2_2_S1.nii -template $path_S1/data_mnb0.nii -interp cubic -force
It works ok for almost all cases, but then for some subjects, with the last line I get this error message:
“contains non-rigid transform - qform will not be stored.”
I don’t understand why it should have a non-rigid transform if I am asking it to be made with only 6 degrees of freedom…
I saw this topic, so maybe it just has to do with the way the data is stored and not the transformation itself?
Thank you in advance!
This is not an error but a warning that is triggered if the header transformation deviates from a rotation matrix by more than 1e-6. Assuming flirt’s transformation is rigid, this might simply be a floating-point precision issue. The alternative is a discrepancy between
flirt's interpretation of the nifti transformations. For those transformations for which you get the warning, what is the output of
transformcalc $path_S1/S2_2_S1_transformation.txt decompose $path_S1/S2_2_S1_transformation.dec
The last output should give you an idea of how non-rigid the transformation is. Any non-zero shear or scaling beyond 1 indicates affine components to the transformation.
If it’s anything other than a negligible non-rigidity, could you retry with the latest version of the software (3.0)? If it’s still an issue, I think we’d need some example data (images can be zeroed out) to replicate the
Ok, I understand.
In my case, the ouput of first line is:
0.999989728611746 -0.00314991563292948 -0.00325360076135197 0.304376949653589
0.00309969818451047 0.999877756832684 -0.0153258445027937 0.298921114446511
0.00330148061580787 0.0153156413065776 0.999877282211843 0.435523373628789
0 0 0 1
and the ouput of the last line is:
transformcalc S2_2_S1_transformation.txt decompose S2_2_S1_transformation.dec (version=3.0.0)
scaling: 0.999999982616043 1.00000000972294 1.00000002345549
shear: 1.40777838483221e-10 1.31533614815965e-09 1.96749155960407e-08
angles: 0.0153265449745808 -0.00325360767881097 0.00314993756058407
angle_axis: 0.0159766568359039 0.958986264029142 -0.20515431475643 0.195594101496563
translation: 0.304376949653589 0.298921114446511 0.435523373628789
R: 0.999989746000249 -0.00314991567906516 -0.00325360193838563
R: 0.00309969811779327 0.999877747412028 -0.0153258638199072
R: 0.00330147935586982 0.0153156214846972 0.999877258453556
S: 0.999999982616043 1.40777838483221e-10 1.31533614815965e-09
S: 1.4077800324807e-10 1.00000000972294 1.96749155960407e-08
S: 1.31533600634601e-09 1.96749158545145e-08 1.00000002345549
So, this confirms that there are no affine components in the transformation and is just a matter of a loating-point precision? If that is the case, can I just copy the q-form of the template to this image or is not recommended?
Yes, that looks like a precision issue, presumably related to the voxel scaling. You can make the linear transformation truly rigid with
transformcalc $path_S1/S2_2_S1_transformation.txt rigid $path_S1/S2_2_S1_transformation.rigid and used that for the
mrtransform call. The difference in the resulting transformed image should be very small (you can test this with
mrmetric) but it should silence the warning.
In any case, there is no need to manually change the q-form. We default to using the sform if sform and qform differ but use either if the other is absent.
I tried making the transformation truly rigid, but strangely the same warning appeared when I input that transformation into mrtransform.
But ok, in any case, I understood that is just a warning and the s-form can be used instead of the q-form, so it should not be a problem.
Thank you for your reply!
I got the same error when using mrconvert to convert from mif to nii. How can I assess why? I am using the latest version of mrtrix. Why does this happen using mrconvert?
I spent quite a bit of time trying to get to the bottom of these issues, and eventually came to the conclusion that this is fundamentally a limitation of the way the
qform is stored in the NIfTI format – see this GitHub thread for the full discussion. As @maxpietsch says, it’s just a warning and you can ignore it, but it’s not something that can be fixed as such, and it’s not because MRtrix3 (or
mrconvert) does anything wrong. We just happen to report the (subtle) mismatch, which I guess isn’t the case with other packages.