I often bang on about how useful twitter is for crowd-sourcing a research community. Today I was reminded of quite brilliant the people on twitter can be at helping to overcome an ‘I don’t know where to start’-type information problem.

I’m currently helping to design an fMRI study which could benefit considerably from the application of multivoxel pattern analysis (MVPA). Having no practical experience with MVPA means I’m trying to figure out what I need to do to make the MVPA bit of the study a success. After a few hours of searching, I have come across and read a number of broad theoretical methods papers, but nothing that gives me the confidence that anything I come up with will be viableOf course, there’s no right way of designing a study, but there are a tonne of wrong ways, and I definitely want to avoid those.

So, I turned to twitter:

Relays and Retweets from @hugospiers, @zarinahagnew and @neuroconscience led to the following tweets coming my way (stripped of @s for ease of reading… kind of).

Sure, I could have come up with as many articles to read by typing “MVPA” into Google Scholar (as I have done in the past), but the best thing about my twitter-sourced reading list is that I’m confident it’s pitched at the right level.

I’m humbled by how generous people are with their time, and glad so many friendly academics are on twitter. I hope collegiality and friendliness like this encourages many more to join our ranks.

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.


It’s been a while.

Settling in to a new job has been terrifying and tiring in equal measure.  The seemingly boundless spending of the early weeks has been replaced by an awfully adult awareness that the only thing you can’t buy is time: more time in my day to prepare for contact with students, to write grant applications, to read journal articles, to blog (yes, this is something I feel I ‘should’ be doing)  but most of all, to think.

Whilst I find it very easy to develop my thoughts on how the Comprehensive Spending Review affected me (not much, yet), whether I support the student protest movement against tuition fees (I do, wholeheartedly), and why QPR saw fit to lose on national television in the only fixture I’ve seen them play this season (regression to the mean), I’m struggling to come up with original ideas for experiments that will be an instant imaging hit.  I’m in the profession of thinking, so it’s certainly no good thing that I’m running dry, but it’s also rather inevitable.

For the past three years I’ve been thinking about work that isn’t actually my own. I have deferred my own ideas about projects to those of my PI and we have primarily pursued paths that he has wanted to pursue.  This was great for showing me the ropes, and showing me how to think about fMRI within Psychology, something I have been employed to further here in St. Andrews, but it has also lead to this rather awkward moment of transition.  I now have to build up my own head of steam, run my own behavioural pilots and read other people’s’ articles with my own research agenda in mind.  Of course, I was doing this when in St Louis, but my livelihood didn’t depend on it.  Now it does.

So, I’m ploughing on with behavioural projects and hoping that forcing myself to think will lead to better thinking (after all, your brain is a muscle isn’t it? gah!).  I’m also considering a couple of more contrived mind-hacks to nudge the process along:

1) Read journal articles at a minimum rate of 1/weekday.

2) Design an experiment I could run at a minimum rate of 1/week.

3) Blog at a minimum rate of 1/week.

I’m not sure if I’ll follow through on these, or whether they’ll be any help if I do, but I’m going to try.  I can’t afford to stay barren for too long.

Whilst Windows easily copies lots of data, it struggles when you ask it to copy lots and lots and lots of data.  Teracopy is a neat file copying utility that provides peace of mind as you transition from copying gigabytes of data to terabytes of data.

In order to get my fMRI data from St. Louis to St. Andrews, I have embarked upon the somewhat arduous task of copying everything to a portable hard-drive.   After a few attempts that ended in the failure to copy a file or two, seemingly at random, I lost faith in using the standard drag-and-drop copy in Windows, and searched for alternatives.  The command line option seemed fastest, but I didn’t want to bring the server down for everyone else for a few hours whilst I did my copying.  Then I found Teracopy.

A picture of TeraCopy
Teracopy in action (Image via Wikipedia)

Teracopy (freeware) is a straightforward utility that improves upon the Windows interface in a number of ways.  Copying is (apparently) faster and it certainly seems more reliable than the standard Windows approach.  One very nice feature is that it allows you to pause and resume your copying for when you need to free up system resources temporarily.

download Teracopy

So far I have copied close to a terabyte of data onto my portable hard-drive with no problems.  Now all that remains is to check it all with another utility (Windiff) to make sure all my files really did get copied successfully, and to actually transport my hard-drive without banging or dropping it.

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!