help > Qform matrix in MRIcron and MRIcroGL
Showing 1-2 of 2 posts
Results per page:
Jan 6, 2021  11:01 AM | loutions
Qform matrix in MRIcron and MRIcroGL
Dear MRIcron experts,

I have a set of 3D coordinates in 'lab-space' (obtained using a neuronavigation system) which I want to convert to voxel indices of the respective nifti.
I tried opening the nifti file in MRIcron and check if the coordinates the neuronavigation system gave me made sense, which they do.
To do the conversion, I just thought I'd load the nifti header into MATLAB, extract the qform, and get the voxel indices doing
V = round(inv(Q)*C');
where V are the voxel indices, Q is the qform matrix (which I got from the MRIcron), and C are the coordinates.
(This didn't work, i.e. the returned indices do not match those in MRIcron, and I'm convinced the problem lies in the algebra - if a kind soul could help me, I'd be highly appreciative!)

However, I opened the same image on MRIcroGL to check the header and the qform is different to that displayed in MRIcron (screenshots are in attachment). 
The difference is not just the orientation of the axes (trivial rotations and permutations from the different conventions), but also in the qoffset, which is what puzzles me.
I then displayed the qform matrix of the same nifti using different softwares (FSL's fslhd and Freesurfer's mri_info - the results of which are also attached), and these are congruent with the matrix displayed in MRIcroGL.
I thought it might have something to do with the center of the referential being poorly defined, but subtracting the c_ras from the mri_info output does not correct for the different qoffsets seen between MRIcron and everything else I tested.

I was wondering if someone could explain to me this difference, or re-direct me to a place where I can read about it.
The versions I'm using are:
MRIcron v1.0.20190902
MRIcroGL v1.2.20201102

Thank you very much in advance!
Attachment: screenshots.png
Jan 6, 2021  12:01 PM | Chris Rorden
RE: Qform matrix in MRIcron and MRIcroGL
Your data is anisotropi and not aligned with canonical space, hence the 'resliced' seen in the MRIcroGL status bar. Note that MRIcron will also manipulate the header depending on your Preferences (e.g. you can choose if MRIcron loads the raw data as stored on disk, orthogonally losslessly rotates the data to match the canonical NIfTI space, or resamples the data).

Be aware that NIfTI stores two spatial transforms: the quaternion-based QForm (9 DoF) and matrix based SForm (12 DoF). When both are set, both MRIcron and MRIcroGL give precedence to the latter as described here:
For consistency across tools you might want to make sure the SForm and QForm is identical, unless a shear is required to represent your transform.

In future, you may want to consider converting images from DICOM to NIfTI using dcm2niix, which will losslessly reorient 3D acquisitions to match canonical space (e.g. reslice your sagittal data to axial). Likewise, choosing an isotropic image resolution during acquisition may make life easier (in your case increasing the scan time by 20%).

When using different systems that have different conventions for how they store data internally, I would suggest always thinking about the coordinates in world space mm, rather than voxel order as stored on disk.