Incorrect transformation matrix?

[MicaelAnderssonUmu]

Hello

I have coregistered, using SPM, FLAIR-image to a T1-image before using both in LST-AI. The coregistration result in a new sform-transformation matrix in the nifti-file. However, it seems that LST-AI is using the (old) qform-transformation matrix. Is that not a bit unusual?

Best
Micael

[jqmcginnis]

Hey Micael,

Could you please let us know exactly how you are using LST-AI, i.e., which flags?

Also, I am not sure I understand which output files you are referring to? LST-AI is also running some registration under the hood (i.e., no co-registration is actually needed), and some of the products it generates are in the MNI space, while others are in the native space. So I am not really sure where the transformation matrix comes into play.

Happy to clarify any questions and look into this further🙂

Best,
Julian

[MicaelAnderssonUmu]

Thankyou for quick response. I ran:
lst --t1 $f1 --flair $fl --output $fout --probability_map --temp $fout --device cpu

We looked at space-flair_desc-annotated_seg-lst.nii.gz and found that it did not be so good located on the FLAIR-image. After changing the qform to sform (private.mat0 to private.mat in SPM-nifti-header terms) it fitted good.

/Micael

[jqmcginnis]

Thanks! Which viewer did you you use, and have you tried it across different viewers (eg FSL, ITK-Snap etc.)? My first guess being that the viewer uses a different convention as our registartion tool (greedy)?

In such I would probably set sform-to-qform or vice versa before processing it? Does this help?

[MicaelAnderssonUmu]

I used mricron, spm checkreg and an inhouse-program for viewing, and the effect was the same in all of them.

Yes, I tried setting qform = sform for one subject that showed the dislocation and that worked well. Usually, there are not much subject movements between different image protocols, so in most subjects one wouldn't notice this.

/Micael