The past few days have seen my fMRI analysis server taken over by a Linux virtual machine. I have installed FSL, and have been using MELODIC to plough my way through ICA analyses of fcMRI data, a first for me.

One of the annoyances I have had to deal with as part of this project has been the difference in input data required for SPM, for which my preprocessing stream is targeted, and FSL, for which it is not. Specifically, this difference has necessitated the conversion of data runs from 3D NIFTI files to a single 4d NIFTI file. FSL has a utility for this (fslmerge), but being the Linux novice that I am, I have struggled to script the merging within the virtual machine.

Thankfully, SPM has a semi-hidden utility for this conversion.

SPM's 3d to 4d NIFTI conversion tool
SPM's 3d to 4d NIFTI conversion tool

The GUI is located within the Batch Editor’s SPM>Util menu, and be default saves the specified 3D NIFTI images to a single 4D NIFTI image within the same directory. It doesn’t gzip the output image, like the fslmerge script, but, it’s scriptable using the ‘View>Show .m Code’ menu option, and it’s good enough for me.


Since setting up lab in St Andrews I’ve consistently run into a DICOM Import Error that causes the process to terminate about half-way through. I finally fixed the problem today after a quick search on the SPM mailing list.

The error I was receiving was as follows:

Running ‘DICOM Import’
Changing directory to: D:Akira Cue Framing 2011PP03
Failed ‘DICOM Import’
Error using ==> horzcat
CAT arguments dimensions are not consistent.
In file “C:spm8spm_dicom_convert.m” (v4213), function “spm_dicom_convert” at line 61.
In file “C:spm8configspm_run_dicom.m” (v2094), function “spm_run_dicom” at line 32.

The following modules did not run:
Failed: DICOM Import

??? Error using ==> cfg_util at 835
Job execution failed. The full log of this run can be found in MATLAB command window, starting with the lines (look for the line
showing the exact #job as displayed in this error message)
Running job #[X]

Error in ==> spm_jobman at 208

??? Error while evaluating uicontrol Callback

This was a little mysterious, as the appropriate number of nifti files appeared to be left after the process terminated unexpectedly.

The following link suggested an SPM code tweak that might fix it:

The proposed fix from John Ashburner simply requires changing line 61 of spm_dicom_convert.m from:

out.files = [fmos fstd fspe];


out.files = [fmos(:); fstd(:); fspe(:)];

Works like a charm!


Typical fMRI brain scans take a 3D images of the head every few seconds.  These images are composed of lots of 2D ‘slices’ (usually axially oriented) stacked on top of one another.  This is where the problem of slice acquisition time rears its head – the problem being that these slices are not all taken at the same time, in fact, their collection tends to be distributed uniformly over the duration it takes to gather a whole 3D image.  Therefore, if you are collecting a 3D image comprising 36 slices every 2 seconds, you will have a different slice collected every 1/18th of a second.

2D slices (left; presented as a mosaic), acquired at slightly different times within a 2s TR, that make up a typical 3D image in fMRI (right; shown with a cutout)

If you’re worried about the effect of this fuzziness in temporal resolution on your data (and there are those who don’t), then it can be corrected for in the preprocesisng stages of analysis.  Of course, you do need to know the order in which your slices were collected to correct for the ordering differences.

Finding out the order of slice correction is not as easy as it should be.  On the Siemens Trio scanner that I use, it’s straightforward if you have an ‘ascending’ (bottom to top, in order: 1, 2, 3, etc.) or a ‘descending’ (top to bottom, in order, 36, 35, 34 etc.) order of slice collection.  However, if you’re using the ‘interleaved’ order (odd slices collected first, followed by even slices), it’s not immediately clear whether you’re doing that in an ascending (1, 3 5… 2, 4 6… etc.) or descending (35, 33, 31… 36, 34, 32… etc.) interleaved order.

I found out that I was collecting my slices in an interleaved, ascending order by asking the MR technician at the facility.  But, if there was no technician to hand, or if I wanted to verify this order myself, I would be very tempted to try out a method I found out about on the SPM list today:

Head-turning research (links to poster at a readable resolution on the University of Ghent web-site)

The procedure, devised by Descamps and colleagues, simply involves getting an fMRI participant to turn their head from looking straight up, to looking to one side during a very short scan.  The turn should be caught in its various stages of completion by the various slices that comprise one 3D image, allowing the curious researcher to figure out the slice acquisition order crudely, but effectively.

I enjoyed how connected to the physical reality of our own bodies this procedure is.  It reminded that these tools we are using to make inference about cognition are tied to our bodies in a very tangible way.  That is something I often forget when pushing vast arrays of brain-signals values around in matrices, so it’s nice to be reminded of it now and again – I’d certainly rather be reminded like this, than by having to discard a participant’s data because they have moved so much during the a scan as to make their data useless!