?That seems to have been the problem: Running the data through Slicer as suggested elsewhere fixed the slice time code, but then saved only a single frame of the 4D data. I had been poking around the file header looking for a corresponding field, not suspecting that it was a calculated value and that my data had been truncated, nor noticing that my image dimensionality field had changed value.

I wrote a MATLAB script to modify the slice time value (in addition to the TR value, which was also incorrectly set in my data) and was going to publicize the script, only to discover the FSL program fsledithd already exists and is clearly preferable to the Slicer solution for fixing strange NifTI header information. The data now run through preproc-sess without error.

So to summarize for search engines: slice_code errors and other strange header information can be repaired with fsledithd, and the DOF=0 error was the result of an unexpected deletion of all but one time point by Slicer.

Incidentally, the data were converted from DICOM to NifTI using MRI Convert (Windows), so it is possible that this program populates some header fields with strange default values -- I mention this because 5 is not a valid slice code according to the NifTI header specification, and others have posted problems related to this header field. Thanks, Chris

Douglas N Grevehttp://www.mail-archive.com/search?l=freesurfer@nmr.mgh.harvard.edu&q=from:%22Douglas+N+Greve%22 Thu, 28 Apr 2016 10:05:59 -0700http://www.mail-archive.com/search?l=freesurfer@nmr.mgh.harvard.edu&q=date:20160428

Does that run only have 1 time point?