I was curious if anybody else has already encountered this issue. But in my case, SPM’s SliceTiming algorithm sets the TR value in the NIfTI header to zero. I’ve created a quick notebook to illustrate this issue.
I don’t think that this is due to my particular issue but would nonetheless be curious if other’s can recreate this.
So, why should you care? Well, first, there might be a bug out there, so we should all be worried! Second, and more serious, if you first perform SliceTiming correction and afterward have code that relies on the TR in the header information, this will then obviously create false results or not work.
Yes, spm_create_vol.m will strip the TR from any file it writes. I you want to change this behavior you can uncomment the line %try, N.timing = V.private.timing; end
to read try, N.timing = V.private.timing; end
For my own Matlab scripts, I use the following code to halt if this modification has not been made:
%make sure user uncomments timing line in spm
fnm = which('spm_create_vol');
txt = fileread(fnm);
badStr = '%try, N.timing = V.private.timing; end';
if ~isempty(strfind(txt,badStr))
error('Please uncomment "%s" from "%s"', badStr, fnm);
end
This change is a bit of a double-edged sword but I’ll uncomment the said line in the next version of SPM12 to alleviate your pain. In the meantime, if you need to edit the TR in the header of a 4D NIfTI file from SPM, you can use the following.
N = nifti('filename.nii');
N.timing.toffset = 0;
N.timing.tspace = TR;
create(N);
SPM does not use timing information from the header of a NIfTI file. One of the issues with the change is in relation with existing code that might copy the header from one image when creating a new one, thereby propagating timing information when it might not be relevant. An example of this would be to compute the average in time of a 4D file and save it based on a modified header of the input image without sanitising it properly. Hopefully we will see and less of this pattern.