Physics for understanding fMRI artifacts: Part F(f)our

(Wondering why the title has F(four) in it? It's so that Blogger can't trash this post for a third time! I'm giving it a new, unique name. Ha!)

It's finally time to get back to the series of posts on the essential physics concepts that will allow you to interpret and differentiate between acquisition artifacts. There are another five or six posts in this background series, so bear with me. After that we will shift gears and look at "good data," taking some time to assess the normal variations that you can expect to see in time series EPI, and then I promise we'll look at artifacts themselves.


When reality meets imagination

Before we go any further there are a few mathematical properties we need to review. These are actually quite simple relationships that, for the most part, can be explained via a handful of pictures. Like this one....

Maths dude, chillin'.

Complex numbers

The name notwithstanding, complex numbers are quite straightforward to understand from a physical perspective, with a tiny bit of explanation. By the time you've finished reading this post you should have a basic idea of what complex numbers mean and where they come from (they arise quite naturally, as it happens), but for now I am simply going to define some relationships. Hang in there.

We start by defining a so-called imaginary number as any number for which the square is negative. The squares of real numbers - the ones you're used to in everyday life, such as 2, 8.73, -7, pi, and so on - are always positive, whether the number being squared is positive or negative. Thus 2x2 = 4, 8.73x8.73 = 76.2129, -7x-7 = 49 and so on. Squaring a negative number results in a positive number. So how could we possibly get an answer of -4 or -25 out of any square?

Open letter to Blogger

Blogger, you suck. You utterly suck. You have some major bugs in your software which have caused me to waste inordinate amounts of time recreating posts that oscillate between draft and published status. And when I submit a technical help request I hear nothing. For weeks.

Just now I hit SAVE AS DRAFT on a published post. No big deal you would think, right? I simply went back and hit PUBLISH POST again. And voila! The post showed up on the blog still marked as having been published on Sunday 5th June.... Ah, except that now the post's *content* has reverted to a draft from before 15th May! This, even though I have the archive frequency set to "Daily" after tuifu (Google it) on Friday 13th May. WTF?????

Lucky for you, rather than get in my car and drive down to Mountain View to find out who is in charge of this fiasco, I have a backup of my own. So "all" I have to do is re-type the content and re-upload those images that your bug sought to send back into the ether. Doubly lucky for you, I have an extra few hours of time this morning, having canceled a meeting earlier on. So this isn't nearly the crisis that it could have been, and it is only mildly increasing my blood pressure.

Now that I know what a piece of crap your software really is, I shall be taking other remedial steps to avoid similar snafus in the future; such as never, ever actually publishing a draft with the same name as a real post. Instead, I shall create drafts with names like, oh "Draft," and then when I am ready to actually publish the post I shall create a brand new one, with the intended title, and push that puppy out there. I want to see you bite me in the ass then, Blogger. Come on, give it your best shot!

Love,

practiCalfMRI

Memorial to an old post

This used to be the post entitled "Physics for understanding fMRI artifacts: Part Four." I had so many problems getting the draft published that I decided I wouldn't risk deleting this actual post, even though I have changed the title and the content. Wherever this thing points inside the "cloud" at Blogger, I want to seal it off like a leaky nuclear reactor and leave it for eternity, hopeful that it will be unable to infect any subsequent posts once it's buried in metaphorical concrete.

The replacement post, "Physics for understanding fMRI artifacts: Part F(f)our" is here.

I hadn't realized til recently just how flaky cloud computing can be. Clearly xkcd is way ahead of me, as usual:

 The Cloud.

(Stolen with his blanket permission from xkcd.com)

Resting state fMRI: just what can we allow subjects to do?

I'm still waiting to see if Google/Blogger might recover the draft of that fourth post in the series on background physics for fMRI artifact recognition, so in the mean time I thought I'd take a closer look at the only part of the resting-state experiment that I didn't address in detail over the past few months: what we allow the subjects to do during the acquisition.

Potayto, potahto

I'd like to begin with a definition change to assist in understanding the limits of "resting state" fMRI. I'll continue to refer to rs-fMRI as the act of acquiring a block of fMRI data - let's say six minutes' worth - in the absence of any specific externally presented task during the acquisition, with one small exception: we'll assume that the subject is presented with a simple fixation cross and is asked to keep his eyes open. (More on visual and auditory effects on rs-fMRI below.)

Now, though, I'd like to rename the mental activity that is happening during the rs-fMRI acquisition period. The definition of "rest" is tricky because it depends on so many state-dependent factors. What if I'm worried about an upcoming exam? What if I'm hungry and distracted by the need for food? Just because I'm awake during both doesn't make them equivalent periods of "rest," even if I am lying in the scanner staring at a fixation cross in both cases. And, because I want to distinguish between such periods without an explicit task in the discussion to follow, I'm going to term what we do today as "free-thinking state" fMRI, a term used by Cindy Lustig from WashU in a  2003 interview about some of her work.

Okay, so now we have a new definition to work with. How might this state of free thinking be manipulated without fundamentally changing the goal, which is (I assume) to map the largest networks that arise intrinsically, in the absence of explicit, externally driven, goal-directed behavior (in the form of some sort of task presentation)?


Caveats: every fMRI experiment should have some!

Before we look at intentional manipulation of a subject's brain state, let's first review the confounds and limitations that have already been unearthed when it comes to conducting free-thinking state fMRI experiments. These are effects that have been shown to change the networks detected in standard rs-fMRI experiments. (See Note 1.)

Blogger bites

So it transpires that Blogger had a Friday the 13th moment and as they are attempting to restore users' accounts and comments they have managed to trash a lot of other drafts in the process. The fourth installment of background physics for fMRI artifact recognition is presently resembling the first few notes I made back in March. Sunday's near-finished version is in the ether somewhere, perhaps. Wish I'd known there was an ongoing problem, I'd have found something else to do that day.

I guess we get what we pay for. Still, this is a powerful lesson for cloud users generally. Don't rely on the cloud!!! Make your own backups!!!!!  I have pdf "backups" of all completed posts, I guess it's time to start copy-pasting my own backups as I go, too. Sigh. Opening beer.... :-|

Using GRAPPA for fMRI in the presence of subject motion

I've received a few queries about my opinions on the use of GRAPPA for EPI time series, opinions which have been mentioned in passing in earlier posts. In my user training guide/FAQ are some sections that deal with GRAPPA features and performance, but I didn't include an in-depth illustration of the artifacts or the motion sensitivity. So, to help you make a decision on whether GRAPPA is something you should be using in your fMRI experiments, I'm going to post here a few more images and some movies to highlight the problems that can arise in the presence of significant head motion. I'll focus on R=2 accelerated EPI, but the principles hold for higher acceleration factors as well.

Whether or not you ultimately select GRAPPA for your experiment, it is important to make your determination objectively, taking into account your experimental needs, the benefits of the method, its failure modes and prior studies you can rely on for validation. (See "Beware of physicists bearing gifts!")

** Please note that the following information pertains to the GRAPPA implementation available as product on the Siemens Trio/TIM platform with VB15 software. If you have a different Siemens platform or a different vendor's scanner there may be significant differences in the implementation. **

A brief review of the GRAPPA method

If you don't have even a rudimentary understanding of parallel imaging (PI) generally or the GRAPPA method specifically, I would encourage you to stop reading this post now and go read at least one of these articles: Larkman & Nunes (2007) or Blaimer et al. (2004). Then come back when you're ready to proceed with a speedy review.

Tactical approaches to (re)shimming

In an earlier post I looked at the effects of heating on the temporal stability of EPI data. Particular attention was given to the translations in the phase encoding dimension that arise whenever the scanner drifts off resonance during imaging, through the heating and subsequent cooling of the gradient coil (rapid time constants) as well as of the passive iron shims between the gradient coil and the magnet cryostat (slow time constants). These frequency shifts are most apparent between blocks of EPI as discontinuities, or steps, in a concatenated time series, because of the on-resonance adjustment that precedes the start of each EPI block.

Fortunately, for a typical modern scanner there is little detrimental effect on the temporal SNR (and statistical power) of the total time series once it has been corrected for motion using a standard rigid-body realignment algorithm. But the outstanding question is this: must we rely so heavily on the realignment algorithm to fix what is really a hardware limitation? Surely, fixing it in software is a hack? (Save the jokes, I've almost certainly heard them! See Note 1, below.) And, as pointed out by El-Sharkawy et al., if the magnetic field is being perturbed sufficiently by heating to cause components with a Z spatial dependence to change, what about all the other spatial dependencies? If the shim is being compromised, why not do something about it?

The standard fMRI protocol

Let's start by reviewing what happens in a standard protocol. On Siemens scanners, at least, the usual approach to an fMRI experiment is to shim at the start of the session and then not re-shim unless there is a substantial change in the prescribed imaging volume (the stack of EPI slices). Shimming is initiated by the first scan that's not a localizer. (See Note 2.) So, if a 3D anatomical, such as an MP-RAGE, is acquired after the localizer and before the first EPI, say, there will be no further shimming during the session (unless requested by the operator).

Assessing the problem

Now, we could continue to investigate shimming as a means to mitigate the effects of heating using experiments on phantoms. That would be a full study in and of itself. To keep this post shorter and more relevant to you, I'm going to jump straight to brain data. That's because when we are talking about shimming (or re-shimming), we are going to mix the effects of scanner heating with our old chum, subject movement. We're going to lump everything together and look at the resultant. Put another way, there's no point in coming up with a putative solution to the heating issue if it could exacerbate the movement issue.

Experimental verification

Very briefly, as part of a vision experiment, shimming was performed (or not) between blocks of 150 volumes of EPI, TR=2 seconds. (Siemens users: See Note 3.) During the first session, shimming was performed between blocks for the first five blocks, then shimming was omitted between blocks for the next five. The time gaps between blocks weren't controlled rigorously; it was whatever was required to set up a new stimulus script plus, when appropriate, the 30-odd seconds to re-shim. A typical inter-block gap was between one and two minutes. In a second session on the same subject the ordering was reversed: shimming was omitted for the first five blocks, then performed between blocks for the final five blocks.