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


From: SPM (Statistical Parametric Mapping) <[log in to unmask]> on behalf of Alle Meije Wink <[log in to unmask]>
Sent: 03 September 2019 10:21
To: [log in to unmask] <[log in to unmask]>
Subject: Re: [SPM] difference between X and Z dimensions in MNI?
 
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!