For context, I have been collecting functional runs from a Phillips scanner using a self-paced task, and terminating the run prior to the 256-volume finishing time. The MRI center has been providing us with reconstructed .NII files, rather than DICOM files, but the .NII file headers incorrectly report the files as containing 256 frames, rather than the actual number of full frames collected.

When opening the .nii file headers using fsledithd, the mismatch between observed and expected data size is detected, and the data are zero-padded until the 4D files have 256 frames worth of data. The problem we had was during motion correction, when motion correction for some runs (but not others) failed to generate a mcprextreg file, though all other indications suggested that motion-correction had been successfully applied to the data.

When I used fslplit on the padded files to inspect individual frames, there were some instances of partial volumes in the last non-zero data frame, as though a partially-acquired data frame would be included in the reconstructed data. In many cases, only a few slices were missing, but in a few others (likely the ones that were problematic), most slices were missing, which is surely catastrophic for realignment.

In the end, I went back to the original data, used fslsplit to split the volumes into individual frames which also generated a series of dummy volumes, and then inspected the series to identify where the padded volumes start. After deleting the padded and/or partial volumes, I merged the individual 3D volumes into a 4D series, and preproc-sess went off without a problem.