For historical reasons (before NIfTI) SPM used to encode the origin of images using an integer value in a bit of unused space in the ANALYZE headers. This meant that the voxel indices of the origin had to be an integer, which leads to a slightly different
digitisation. For slightly more backward compatibility, we've retained this scheme.
vx = 3.3;
bbMNI = [-90 -126 -72; 90 90 108];
i0 =
bbMNI(1,3):vx:bbMNI(2,3);
% Exact at first voxel
i1 =
fliplr(bbMNI(2,3):-vx:bbMNI(1,3)); % Exact at last voxel
i2 = [fliplr(-vx:-vx:bbMNI(1,3)),
0:vx:bbMNI(2,3)]; % SPM's approach
disp([length(i0) length(i1) length(i2)])
plot(1:length(i0),i0,'+',1:length(i1),i1,'+',1:length(i2),i2,'+')
Best regards,
-John
I looked into this a bit further: using
>> bbMNI=[-90 -126 -72; 90 90 108]; % MNI bounding box
>> size(bbMNI(1,1):2:bbMNI(2,1)) % 1 91
>> size(bbMNI(1,3):2:bbMNI(2,3)) % 1 91
>> size(bbMNI(1,1):3.3:bbMNI(2,1)) % 1 55
>> size(bbMNI(1,3):3.3:bbMNI(2,3)) % 1 55
I found that the correct number of voxels should be 55 -- in other words the 56 that I got in the Z direction below is not correct.
Looking at the vectors themselves I saw that the first two did contain the coordinate (0,0) and the last two didn't -- but that in itself is not a problem.
Or is it?
Because with a voxel size of 3.6 x 3.6 x 3.6 mm^3 the mapping of images to MNI space results in image sizes 51, 61 and 51 in X, Y and Z directions, respectively. And that contains a voxel at 0 mm in the X direction and one in the Y direction -- though not (0,0)
itself.
So the images produced by my standard space mapping script have one slice too many in the Z direction, and losing a slice at the top should leave all the header values at the MNI settings (S form and Q form offsets, etc).
Would that be the best way to do this?
Or are we confined to voxel sizes whose multiple is 18?
Another reason I'm asking is that when I do
$ flirt -in $FSLDIR/data/standard/MNI152_T1_1mm -ref $FSLDIR/data/standard/MNI152_T1_1mm -out MNI152_T1_testsize -applyisoxfm 3.3
$ fslinfo MNI152_T1_testsize|grep dim|grep -v pix
dim1 55
dim2 66
dim3 55
dim4 1
that produces the expected result, so combining FSL and SPM pipelines could lead to geometric problems?
> I'm using a script to map fMRI images to MNI space. The most popular images in MNI have 2x2x2
> mm^3 voxels and 19, 109 and 91 voxels in the X, Y and Z directions, respectively. So I expected
> to also get the same numbers of voxels in that direction if I resample with another isotropic voxel size.
>
> But when I choose voxel size 3.3 x 3.3 x 3.3 mm^3, my images are 55 x 66 x 56 voxels in the
> X, Y and Z directions. What I am now wondering is (i) why are the X and Z sizes of the images in
> voxels different, and (ii) is one of them wrong (i.e. does the Z direction have one slice too many or
> the X direction one too few)?
>
>The original images are 64 x 64 x 38 voxels of 3.3 x 3.3 x 3.3 mm^3. But I think that does not
> really matter; is there a way to correct this by slightly 'shrinking' or 'expanding' the bounding box?
> At the moment it's just set at repmat(nan,2,3).
>
> Many thanks!