In the previous post I covered sources of persistent ghosts that arise as a result of some property of the subject, such as the orientation of the subject's head in the magnet. These are what I'm categorizing as subject-dependent effects. In this post I will review the most common sources of persistent ghosts attributable to the scanner, either from an intrinsic property that you might encounter inadvertently, or from mis-setting a parameter in your protocol. As I mentioned last time, I am restricting the discussion to factors that you have some control over as the scanner operator. Ghosts that arise because of a scanner installation error, such as poor gradient eddy current compensation or inaccurate gradient calibration, are issues for your facility physicist and/or your service engineer.
Scanner-dependent conditions:
Rotated read/phase encode axes
GLOBAL - affects all slices to some extent.
This is an insidious problem that we could categorize as pilot error, except that it's very easily encountered without realizing it. When you set up your slice prescription you are primarily concerned with capturing all those brain regions you need for your experiment. Or you might be concerned with setting a particular slice angle relative to the brain anatomy, e.g. parallel to AC-PC. Now, if the subject's head is precisely aligned such that the read and phase encode axes of your imaging plane are matched perfectly with the gradient set axes (i.e. with the magnet's frame of reference), then for axial slices the readout dimension will be attained using pure X gradient (subject's left-right) while the phase encode dimension uses pure Y gradient (subject's anterior-posterior). (See Note 4 in the post on "Good" coronal and sagittal data for an explanation of why the gradients are established this way, for subject safety/comfort reasons.) But, if the head is twisted slightly, or you're a little sloppy with your slice positioning, then it is quite easy to have a readout gradient that is mostly X with a little bit of Y, and a phase encoding gradient that is mostly Y with a little bit of X. This in-plane rotation ought not be a problem if the X and Y gradients performed equivalently, but they're only similar and not identical. There tend to be small differences in the response time of the gradients, which means that when the scanner tries to drive the read gradient to its desired k-space trajectory, one component (say the X component) can respond faster than the other. This produces a slight mismatch between the target (ideal) k-space trajectory and the trajectory that's actually achieved by the gradients, thereby leading to a source of zigzags that will produce N/2 ghosting.
Now the good news. You've got to rotate the image plane by quite a lot before the ghosting starts to become apparent. It's common to have rotations of 1-2 degrees and these will generate almost no additional ghosting. Once the rotation gets much larger than 5 degrees (depending on the specifics of your scanner) then you might start to see additional ghosting. Below on the left is an ideal prescription, while on the right I've intentionally rotated the image plane by 8 degrees, leading to a small but noticeable increase in ghost level:
(Click to enlarge.) |
Note that the subject's head is properly aligned in the magnet in both conditions; I didn't change the head position at all. The ghosting on the right arises purely as a result of rotating the image plane. Thus, were the subject's head rotated in the magnet, you might decide to "straighten things out" by rotating the image plane in the opposite direction to yield images that appear like those on the left, but that are actually a result of offsetting rotations - a rotation of the subject's head one way and an equal but opposite rotation of the image plane the other. Both the rotation of the subject's head (see last post) and the rotation of the image plane are likely to lead (through separate mechanisms) to increased ghosting.
As a general rule I would advocate setting the in-plane rotation to zero, even if the subject's head is significantly rotated (about the subject's longitudinal axis). This will at least avoid one source of ghosts although, since the shim will already be degraded by such a rotation (relative to the magnet/gradient axes), you're usually better off repositioning the subject and negating any need to rotate the image plane whatsoever. (Siemens users: see Note 1 on how to set the in-plane rotation to zero by hand.) But if you must be sloppy and you decide you're not going to reposition the subject's head, don't compound one problem with another.
No fat suppression
GLOBAL - all slices containing scalp fat will be affected.
GLOBAL - all slices containing scalp fat will be affected.
I covered the need for fat suppression in my user training guide/FAQ, which is available via this post. See the section entitled "On the Contrast tab I notice that fat suppression is enabled for EPI. What does it do?" (Note: I will be uploading an updated version of the guide/FAQ soon. The current one dates from July, 2010.)
What I didn't show in that document was what happens if you decide to disable the fat suppression. Below, on the right, is an example of what happens if you disable the fat suppression compared to leaving it enabled (left):
What I didn't show in that document was what happens if you decide to disable the fat suppression. Below, on the right, is an example of what happens if you disable the fat suppression compared to leaving it enabled (left):
(Click to enlarge.) |
Disabling fat suppression (aka "fat sat") leads to intense ghosts from the subcutaneous lipid. These ghosts overlap the brain in just about every slice. The variance in the overlapped regions can be expected to be significantly higher than other regions, leading to serious complications of interpretation in fMRI.
What, you don't think these ghosts look so bad, and you're tempted to run without fat sat? Hmmm, maybe I should have mentioned that this subject was a fairly serious cyclist with body fat in the single digits. He also happens to have just about the most spherical brain I've ever scanned. It's darn hard to get ghosts of any type on this guy! Your subjects will show much higher ghosting, I guarantee it.
What, you don't think these ghosts look so bad, and you're tempted to run without fat sat? Hmmm, maybe I should have mentioned that this subject was a fairly serious cyclist with body fat in the single digits. He also happens to have just about the most spherical brain I've ever scanned. It's darn hard to get ghosts of any type on this guy! Your subjects will show much higher ghosting, I guarantee it.
On some scanners there is an alternative to using fat suppression. Instead, the RF excitation pulse is designed to be what's called a spatial-spectral pulse. It aims to excite water in a slice while simultaneously avoiding excitation of fat resonances. GE scanners use the this approach by default, I'm told. (Siemens users, see Note 2.)
There are naturally pros and cons to the avoidance (spatial-spectral excitation RF pulses) or presaturation (fat sat) strategies. Presaturation works fairly well and permits the slice excitation to be implemented separately, and possibly optimally, but at the temporal cost of some 15 ms per slice. Let's do the arithmetic. That's an overhead of nearly half a second for thirty slices. Ouch! One might be tempted to disable the fat suppression in order to acquire more slices per TR, but if you do then ghosts of the type shown here will be the result. The principal disadvantage of the spatial-spectral approach is that the slice profile tends to be broader - less rectangular, more trapezoidal - and the minimum attainable slice thickness may be higher than for the corresponding fat suppression option. My advice is to use what's optimized on your scanner platform, which appears to be fat suppression for Siemens and spatial-spectral excitation for GE. I don't know what Philips offers.
There are naturally pros and cons to the avoidance (spatial-spectral excitation RF pulses) or presaturation (fat sat) strategies. Presaturation works fairly well and permits the slice excitation to be implemented separately, and possibly optimally, but at the temporal cost of some 15 ms per slice. Let's do the arithmetic. That's an overhead of nearly half a second for thirty slices. Ouch! One might be tempted to disable the fat suppression in order to acquire more slices per TR, but if you do then ghosts of the type shown here will be the result. The principal disadvantage of the spatial-spectral approach is that the slice profile tends to be broader - less rectangular, more trapezoidal - and the minimum attainable slice thickness may be higher than for the corresponding fat suppression option. My advice is to use what's optimized on your scanner platform, which appears to be fat suppression for Siemens and spatial-spectral excitation for GE. I don't know what Philips offers.
Mechanical resonances
GLOBAL - affects all slices equally.
GLOBAL - affects all slices equally.
I covered the basics of this problem in the user training guide/FAQ, too. See the section, "I’ve been told not to use echo spacing between 0.6 and 0.8 ms for EPI. How come?" (Note: I will be uploading an updated version of the guide/FAQ soon. The current one dates from July, 2010.)
In the last version of the guide/FAQ document I didn't given examples of mechanical resonances, so here is a video showing the temporal stability of ghosts arising from mechanical resonance in the X gradient (the default readout gradient for axial slices):
In the last version of the guide/FAQ document I didn't given examples of mechanical resonances, so here is a video showing the temporal stability of ghosts arising from mechanical resonance in the X gradient (the default readout gradient for axial slices):
It's quite remarkable how temporally stable the ghosts are. Vibration of the gradient coil is in a steady state - mechanical resonance - and there is a constant mismatch between the desired and actual k-space trajectories, leading to sufficiently large offsets between odd and even lines of phase-encoded k-space that the ghost correction scheme, using three navigator echoes, isn't well matched to it.
On Siemens Trio scanners the mechanical resonances are really only a problem for axial or axial oblique slices - prescriptions that use the X gradient for readout - and they primarily affect echo spacings in a range of about 0.6-0.8 ms. Most facilities are aware of the problem and have characterized specific "no go" zones for that particular scanner, setting up "default" protocols that avoid the issue entirely. If you do decide to go "off piste," e.g. to try to push a few extra slices in your TR, you would want to talk to your facility techs/physicists to run some quick empirical tests and check that you haven't stumbled inadvertently into a higher ghost level than is possible by using a different echo spacing. I'll leave the issue here for today because it's bordering on an issue that's one for your physicist.
On Siemens Trio scanners the mechanical resonances are really only a problem for axial or axial oblique slices - prescriptions that use the X gradient for readout - and they primarily affect echo spacings in a range of about 0.6-0.8 ms. Most facilities are aware of the problem and have characterized specific "no go" zones for that particular scanner, setting up "default" protocols that avoid the issue entirely. If you do decide to go "off piste," e.g. to try to push a few extra slices in your TR, you would want to talk to your facility techs/physicists to run some quick empirical tests and check that you haven't stumbled inadvertently into a higher ghost level than is possible by using a different echo spacing. I'll leave the issue here for today because it's bordering on an issue that's one for your physicist.
Excessive ramp sampling
GLOBAL - affects all slices equally.
Disclaimer: Let me begin by stating that I haven't fully investigated this phenomenon, I'm simply going to report what I see on my scanner and do my best to explain how it looks in data. Therefore, please don't take this at anything but face value. My diagnosis may be incorrect in any number of ways. For example, it is entirely possible (even probable) that the effect I've termed "excessive ramp sampling" is actually another manifestation of the aforementioned mechanical resonances, i.e. a k-space instability generated by a mechanical resonance that is modulated in some fashion by ramp sampling, when the extent of ramp sampling fraction becomes large. (See Note 3.) I've not had the time (or, to be honest, the imperative) to investigate further than what you'll see here. I just want to be complete and make sure you can avoid any similar problems that might arise on your scanner.
This issue is another one that will likely require your physicist's input to avoid properly on your scanner; it's in the gray area between being under your control and being a system/scanner feature. But for the sake of your education I'm going to give you an example and describe one way the problem can be encountered somewhat inadvertently, if you are setting up a new EPI protocol.
Let's look at an example of the ghosting that arises when I set the echo spacing time to be the shortest possible (along with the highest readout gradient bandwidth), commensurate with a fixed TE of 28 ms and a 64x64 matrix. On the left is the echo spacing set at 0.5 ms using a readout gradient bandwidth of 2298 Hz/pixel, on the right is the echo spacing set at the minimum attainable echo spacing 0.43 ms, with readout gradient bandwidth at 2790 Hz/pixel:
GLOBAL - affects all slices equally.
Disclaimer: Let me begin by stating that I haven't fully investigated this phenomenon, I'm simply going to report what I see on my scanner and do my best to explain how it looks in data. Therefore, please don't take this at anything but face value. My diagnosis may be incorrect in any number of ways. For example, it is entirely possible (even probable) that the effect I've termed "excessive ramp sampling" is actually another manifestation of the aforementioned mechanical resonances, i.e. a k-space instability generated by a mechanical resonance that is modulated in some fashion by ramp sampling, when the extent of ramp sampling fraction becomes large. (See Note 3.) I've not had the time (or, to be honest, the imperative) to investigate further than what you'll see here. I just want to be complete and make sure you can avoid any similar problems that might arise on your scanner.
This issue is another one that will likely require your physicist's input to avoid properly on your scanner; it's in the gray area between being under your control and being a system/scanner feature. But for the sake of your education I'm going to give you an example and describe one way the problem can be encountered somewhat inadvertently, if you are setting up a new EPI protocol.
Let's look at an example of the ghosting that arises when I set the echo spacing time to be the shortest possible (along with the highest readout gradient bandwidth), commensurate with a fixed TE of 28 ms and a 64x64 matrix. On the left is the echo spacing set at 0.5 ms using a readout gradient bandwidth of 2298 Hz/pixel, on the right is the echo spacing set at the minimum attainable echo spacing 0.43 ms, with readout gradient bandwidth at 2790 Hz/pixel:
(Click to enlarge.) |
I don't think I need to point out the ghosts on the right, eh? And at first glance - assessing a single TR - the ghosts appear consistent with the mechanical resonance ghosts in the previous section. Except that, unlike the ghosts arising purely from a mechanical resonance, these ghosts are temporally unstable:
The ghosts appear to swirl in a periodic fashion. Any small perturbation in the power supply - or any other slight variation in the scanner's stability - causes a sizable effect in the ghost; the correction algorithm (using the three navigator echoes) produces a slightly different result for each TR.
Of course, in this instance the temporal properties are arguably moot. You don't want to be running with such large ghosts at all, whether the bulk of the ghost is temporally stable or not! Still, let's consider the temporal stability independent of the large magnitude of the ghosts, because there might be instances when the ghosts are much less evident - lower magnitude - but still have a temporal instability arising from "excessive ramp sampling."
Why use quotation marks? Because of my initial disclaimer. I think the effect arises because the degree of ramp sampling is high; in this case roughly half of the readout data points are being acquired on the readout gradient ramps. Thus, small instabilities in either the readout gradient, or mismatches in timing between the digitizer and the readout gradient waveform, can lead to temporal changes in the ghosting level from TR to TR. On my scanner I think that the source is the relatively poor electrical power - I don't have a power conditioner for the scanner, so my electrical stability is whatever I get fed from campus - leading to a small but noticeable instability in the readout gradient amplitude whenever the readout gradient is driven extremely hard. The use of a high degree of ramp sampling seems to exacerbate the gradient instability in the ghost level. But, as I said at the outset, this is just a tentative, working hypothesis. It may be something else entirely.
On my scanner I can quite easily avoid the worst effects of what I'm calling "excessive ramp sampling" by applying a simple rule of thumb: I use an echo spacing that is not less than 0.02 ms longer than the minimum attainable echo spacing. This means I fix all other acquisition parameters except echo spacing and bandwidth, then search for the shortest echo spacing that can be achieved at all the allowable bandwidths. Once I determine the minimum echo spacing I then avoid using any echo spacing//bandwidth combination that sets the echo spacing at less than the minimum echo spacing plus 0.02 ms. (This sounds complicated, it's actually very simple sitting on the scanner console!) Thus, in the example shown above, I found that the minimum echo spacing was 0.43 ms, attainable at a bandwidth of 2790 Hz/pixel. By using an echo spacing of 0.45 ms or longer - at whatever bandwidths are now attainable - I reduce the percentage of data points acquired on the ramps and impart temporal stability to the ghosts. I have simultaneously to make sure that I also stay away from the mechanical resonances, of course! That said, I rarely drive the system even this hard, preferring instead to stay 0.04 ms or more above the minimum echo spacing (and away from the mechanical resonance "zone" of 0.6-0.8 ms).
The next video shows how using moderate ramp sampling, with an echo spacing of 0.5 ms and readout gradient bandwidth of 2298 Hz/pixel leads to small and temporally stable ghosts. All other parameters, including the TE and matrix size, were held constant from the previous example:
So, in conclusion, you should beware the effects of overly aggressive reductions in echo spacing, e.g. as might happen if you attempt to reduce the degree of distortion in the phase encoding dimension. (The shorter the echo train length the lower the inherent distortion in the phase encoding dimension, as discussed in PFUFA Part Twelve.) Be careful that you don't introduce a temporal instability and/or increased ghosting. Check not only for the magnitude of the ghosts at the echo spacing you select, but also their temporal stability. A quick phantom experiment will show you what you need to know.
I will try to update this post in a couple of weeks' time, after I've had a chance to test on my scanner the potential for similar instabilities with coronal and sagittal slice prescriptions, i.e. those using the Z gradient (head-to-foot) for readout rather than X (left-to-right), as for the axial and axial oblique slices considered here. (See Note 4 of the "Good" coronal and sagittal data post for an explanation of why sagittal and coronal prescriptions preferentially use the Z gradient for the readout axis.)
Next post: not sure yet, but possibly an addendum to the PFUFA series, which would be Part Thirteen, on ramp sampling. Either that or the next post in this series, which will be on either distortion or dropout and tactics to reduce them.
I will try to update this post in a couple of weeks' time, after I've had a chance to test on my scanner the potential for similar instabilities with coronal and sagittal slice prescriptions, i.e. those using the Z gradient (head-to-foot) for readout rather than X (left-to-right), as for the axial and axial oblique slices considered here. (See Note 4 of the "Good" coronal and sagittal data post for an explanation of why sagittal and coronal prescriptions preferentially use the Z gradient for the readout axis.)
Next post: not sure yet, but possibly an addendum to the PFUFA series, which would be Part Thirteen, on ramp sampling. Either that or the next post in this series, which will be on either distortion or dropout and tactics to reduce them.
____________________
Notes:
1. On the Routine tab, click the three dots to the right of the Phase enc. dir. field. This opens the Inplane Rotation window, shown below. Assure the Rotation angle is zero. Set it to zero if needed.
Pay particular attention to the in-plane rotation when using AutoAlign. It has a habit of introducing non-zero rotations.
2. I'm not going to get into it here but Siemens users should note that the "spatial-spectral" option in the Fat Suppr. field of the Contrast tab is implemented incorrectly. The actual slice thickness is some three times larger than the number reported in the Slice Thickness parameter field. I wouldn't recommend using the "Spatial-spectral" option unless you're a highly experienced MR person and you have some programming experience. You're gonna need to modify some source code for things to work properly... Note also that the fat suppression module resides outside of the particular EPI pulse sequence you're using, so there is no easy workaround by simply changing from, say, ep2d_bold to ep2d_pace. The problem resides in the fat suppression module itself.
3. I will do a separate post on ramp sampling soon. In brief, ramp sampling takes advantage of the fact that the k-space trajectory through the 2D plane can follow any direction and speed we like, provided we end up with a fully sampled 2D plane of (in this case) 64x64 equally spaced k-space points. Thus, our gradient shape isn't restricted. We can sample on the trapezoidal readout gradient, using the ramps up and down in addition to the flat top of the gradient. To do this we need to digitize much more quickly than the Nyquist frequency established by the field-of-view we've selected in the final image, then we simply discard the extra data points on the flat portion, and ensure that delta-k is the same area under the ramps as for the flat portion. And if this is all sorts of confusing, don't worry about it now, wait for the new post! I'll write it next, before I move on to the next post on common persistent EPI artifacts.
No comments:
Post a Comment