I was using spm_get_space to apply some transformations and noticing odd behavior with the last image in my 4D file ending up with an incorrect matrix.  This is with SPM8, but I confirmed that the particular bits of code are the same in the current SPM12 release. The problem is in checking the size of the matrices for timepoints after the first. The line is this:

 

if size(N.extras.mat,4)<size(N.dat,4)

N.extras.mat(:,:,size(N.dat,4)) = zeros(4);

end

 

The if clause appears to have a logic error. It’s checking the 4^th dimension of size for N.extras.mat, but my understanding is that N.extras.mat will always be a 4x4xFrames array, so won’t have a 4^th dimension, so the if statement always evaluates as true for a 4D file and then the last matrix is set to zeros, even if there was an existing transformation matrix present before.

 

Changing the size(N.extras.mat,4) to size(N.extras.mat,3) would seem to resolve this logic error and, I think, exhibit the intended behavior.

 

A quick look at uses of spm_get_space within SPM seems like it doesn’t matter much for canonical SPM use, since they typically call spm_vol or something to get all matrices first, then loop over spm_get_space calls to set them to something new. But I was using a quick snippet of code from an old post on the list that essentially does:

 

for i = 1:nFrames

                M1 = spm_get_space(i’th frame of file.nii);

                M2 = some operation on M1;

                spm_get_space(i’th frame of file.nii, M2);

end

 

The problem here being that on the first loop through, spm_get_space sets the last element of the Nifti extras.mat to 0s, so on my last loop through my calculation of M2 is based on an incorrect M1.

 

--

  Mike Angstadt

  Research Computer Specialist / PANLab Lab Manager

  Department of Psychiatry / University of Michigan

  (734) 936-8229