For historical reasons, SPM assumes that there is a single matrix in the
headers. This is the one generated by spm_get_space. It preferentially uses
the sform matrix (a 12-parameter affine). If this is undefined, then it uses
the qform (only a 9-parameter affine). Usually, it sets the qform and sform
to the same values (except for flow fields and imported data for DARTEL), and
the code to 2, to indicate that it is "aligned". Warnings appear whenever
the qform can not exactly represent the full 12-parameter affine transform. I
figured that doing it this way would keep the code as simple as possible for
the other developers, and could mean thet the spm_vol and spm_get_space
utilities could still be used in a sensible way. I had intended to
eventually have the nifti routines doing all the I/O of image data, but this
is a relatively low priority task. The nifti routines allow the additional
(qform) matrix to be encoded.
There is a discrepancy of one voxel because MATLAB indexes from 1..N, whereas
C indexes from 0..N-1. Historically, SPM was using its voxel-to-world
indexing based on the MATLAB convention. It was decided to do NIfTI indexing
based on the C convention, so SPM tweaks the matrices accordingly. It just
means that the representation used within SPM is slightly different, but the
actual contents of the headers should be compatible. Take a look in
@nifti/subsasgn.m and @nifti/subsref.m where you'll see lines such as:
val1 = val1 * [eye(4,3) [1 1 1 1]'];
obj.hdr.srow_x = val1(1,:);
obj.hdr.srow_y = val1(2,:);
obj.hdr.srow_z = val1(3,:);
and
t = double([h.srow_x ; h.srow_y ; h.srow_z ; 0 0 0 1]);
t = t * [eye(4,3) [-1 -1 -1 1]'];
Similarly, in @nifti/private/encode_qform0.m, you'll find:
M = M * [eye(4,3) [1 1 1 1]'];
and in @nifti/private/decode_qform0.m, you'll see:
M = M * [eye(4,3) [-1 -1 -1 1]'];
All the best,
-John
On Thursday 27 November 2008 18:07, Darren Gitelman wrote:
> Hi
>
> I want to inquire about header differences between SPM and FSL.
> My questions are
> 1) SPM and FSL seem to be translated 1 voxel in each axis relative to
> each other. Are these just 2 different but valid ways of treating the
> set of coordinates stored in the NIFTI header?
>
> 2) I'm not sure I understand (actually I'm sure I don't understand)
> the differences between the qform and sform information). In one
> volume made by SPM the sform info is translated by 1 voxel in each
> axis from the SPM matrix. But the qform is rotated relative to the
> sform and spm matrix (pi/2 radians along the y and z axes and then
> flipped along the x axis. In another volume (from the ADNI database)
> the fsl sform is all zeros while the qform is the same as the spm
> matrix but translated by 1 voxel. Why the differing relationships
> between sform and qform in different volumes and how should this be
> interpreted.
>
> The details on the matrices are below
>
> Volume made by converting dicom to NIFTI in SPM5
> SPM matrix
>
> 0.0601 -0.0199 0.9980 -95.4718
> -0.9248 0.3751 0.0632 50.4595
> 0.3756 0.9268 -0.0041 -168.5254
> 0 0 0 1.0000
>
> using fslhd it returns for the sform (fsl says this is a NIFTI-1+ file)
>
> 0.060079 -0.019902 0.997995 -94.433670
> -0.924828 0.375106 0.063155 49.972889
> 0.375611 0.926768 -0.004130 -167.227142
> 0.000000 0.000000 0.000000 1.000000
>
> Inverting the matrices into voxel space shows they are translated by 1
> voxel from eachother (fsl is +1 voxel in each axis)
>
> The qform matrix matrix is
> 0 0 1.0000 -91.8086
> -1.0000 0 0 150.2038
> 0 1.0000 0 -123.1709
> 0 0 0 1.0000
> ---------------------------------------------------------------------------
>--
>
> Volume from the ADNI database
> SPM5 returns
>
> 1.2000 0 0 147.2850
> 0 1.0000 0 156.5267
> 0 0 1.0000 383.0000
> 0 0 0 1.0000
>
>
> but fsl returns for the sform (again this is a NIFTI-1+ file)
>
> 0.000000 0.000000 0.000000 0.000000
> 0.000000 0.000000 0.000000 0.000000
> 0.000000 0.000000 0.000000 0.000000
> 0.000000 0.000000 0.000000 0.000000
>
> and for the qform
> 1.199997 0.000000 0.000000 148.484955
> 0.000000 1.000000 0.000000 157.526672
> 0.000000 0.000000 1.000000 384.000000
> 0.000000 0.000000 0.000000 1.000000
>
>
> thanks for any insight.
> -----
> Darren Gitelman
|