MRI pre-processing

MRI pre-processing

Why? What is the problem to be solved?

  • We might be able to increase the quality of the data.
  • We may be able to extract more useful information (e.g. signal) out of the data (which has both signal and noise). Another way to think about it is that we don't want to treat artifacts as something we think is real.
  • To obtain more informative/useful visualizations of the data.
  • Conceptually, sometimes it doesn't even make sense to analyze raw data and pre-processing is absolutely necessary (e.g. without correcting head displacement, the meaning of a voxel doesn't even make sense).

High-level issues

  • Blurry line between pre-processing and analysis. But, one practical definition of pre-processing is "stuff you always do" and "stuff you do across ANY experiment" and "boring stuff that many people don't want to think about".
  • Murphy's Law. Anything that can go wrong, will. MRI data is often noisy, messy, badly collected, subject to artifacts, and this may very well "confuse" pre-processing.
  • Visual inspection is the remedy. This guards against Murphy's Law. Automated pre-processing is nice, but you should check that it "worked".
  • Rabbit holes. Pre-processing is a very hard interesting methodological challenge; however, the overall benefit of a "better" pre-processing operation might be tiny compared to what you care about in the end. So, be careful of rabbit holes.
  • Bad pre-processing can bite you in the ass. You are staring at some downstream result and you are completely baffled. It could be that you failed early on. (And, realizing this down the road may have cost you many hours of human/computer time.)
  • Fix it up front. It's better to acquire good data to start with than try to "fix" it.
  • Less is more. Every little thing you do has the potential to fail. And every little thing you do costs human and computer time. So, maybe doing less is better!
  • Play with fire. Don't play with low-level header stuff, or basic operations, etc., unless you know what you are doing.
  • If it ain't broke, don't fix it. If your current approach is stable and reasonable, consider doing nothing.
  • Theory vs. practice. Whether something "makes sense" is arguably less important than how it fares in practice on real data and most hopefully your data.
  • Think carefully about the interpretation of upsampling. Sometimes one interpolates to surface vertices, or interpolates to the original voxel grid, or interpolates according to a denser grid (i.e. upsampling). Alternatively, sometimes one combines data that reflect different spatial resolutions. Make sure to interpret the situation correctly. For example, upsampling data isn't the same as actually acquiring data at the higher resolution. Upsampling data does not increase the number of actual samples (from a statistical perspective).

What can (often) go wrong?

  • If NIFTI headers are misaligned or wrong, then you might get brain flips (left right, or up down).
  • If the functional data are misaligned to the anatomy (e.g. T1), then results will look very weird (and wrong).
  • If the acquisition missed a bunch of brain, the alignment might be completely confused.
  • Segmentation quality can be poor and put cortical surfaces not even close to the gray matter.
  • You might pre-process the data in a way that removes your signal of interest.
  • If you perform operations on your data, it is possible to introduce new variability that isn't in the data.

Common pre-processing operations

  • co-registration
  • individual to a group template (e.g. an MNI template, Talairach, etc.). sometimes referred to as "spatial normalization"
  • individual's fMRI data to individual's T1 (or T2) anatomy
  • individual's fMRI volumes to some reference fMRI volume (motion correction)
  • Relevance of MRI physics to this topic?
  • the better the data quality (spatial resolution, SNR, coverage), the easier a time you are going to have
  • registration of two volumes that have different contrasts is, in general, harder
  • the higher your spatial resolution, the more that the accuracy of co-registration matters
  • fMRI data is notorious for spatial distortion, so that complicates getting good co-registration
  • combining data across scanners can lead to additional headaches (e.g. different scanners have different gradient nonlinearities and may have different spatial accuracies...)
  • EPI undistortion
  • Relevance of MRI physics to this topic?
  • You can correct (to some extent) fMRI images that have distortion
  • One strategy, however, is to try to minimize distortion in the first place
  • Head motion (head drift) interacts with field inhomogeneties; hence, correcting for spatial distortion perfectly is actually really hard

  • slice time correction (fMRI-specific)
  • some people ignore this wholly (especially if the TR is very fast)
  • other people attempt to correct the data (i.e., resample the time series to get all the slices at the same time). note that this applies to 2D acquisitions.
  • Relevance of MRI physics to this topic?
  • The shorter your TRs, the less that this is an issue
  • Multiband acquisition causes multiple slices to be acquired simultaneous, so you have to deal with this accurately if you want to correct slice times.
  • spatial filtering
  • spatial smoothing (low pass filtering)
  • bias correction (intensity inhomogeneity correction, which is just a form of high-pass filtering). Note that amplifying low intensity regions will be enhancing the noise in the data in these regions.
  • Relevance of MRI physics to this topic?
  • Why acquire spatial resolution if you are going to smooth it? Perhaps just acquire at lower resolution to start with?
  • temporal filtering
  • This covers a large set of techniques including noise reduction / detrending / nuisance signal regression
  • Relevance of MRI physics to this topic?
  • If you push spatial/temporal resolution, thermal noise is going to be a larger proportion of your data, and so you should design your analysis strategy accordingly
  • We hope scanner hardware is temporally stable, but sometimes they aren't quite so. For example, some low-frequency drift in fMRI time-series may be due to hardware instabilities.
  • With vanilla fMRI acquisitions, each volume is, from a hardware perspective, more or less independent of all other volumes. However, real noise in fMRI data includes non-thermal noise (e.g. physiological noise) and this noise is not independent across time. Also, note that as soon as you perform any analysis that involves multiple volumes, all bets are off and your analysis results likely have complex dependences across time.
  • "denoising"

What makes some types of MRI/fMRI data special such that pre-processing presents new issues to think about?

  • 7T could exacerbate some issues: reduced tissue contrast, B0 inhomogeneities (distortion), B1 transmit homogeneity, etc.
  • High spatial resolution could lead to some challenges: If there is poorer SNR, could have downstream consequences (like harder to coregister, etc.). Could be associated with higher levels of EPI distortion. The data could grow big and maybe your computer blows up (or slows you down in your analysis completion). The data are so high resolution that standard FreeSurfer does not actually create high enough resolution surfaces. With high spatial resolution, inaccuracies in spatial handling matter more and more.
  • High temporal resolution: Various physiological signals now show up in the data (as opposed to being aliased). You can also start seeing subtle B0-related (breathing-related) apparent head motion.

Major variations out there

  • There are a number of packages out there: SPM, AFNI, FSL, FreeSurfer, BrainVoyager, fmriprep, etc. You may find differences in how different packages handle various things, such as:
  • choice of what space to normalize to
  • whether it's volume-based vs. surface-based
  • Different types/formats of surfaces
  • The 'accuracy/fidelity' of cortical surface reconstruction may vary
  • Whether certain knobs are turned on by "default"... for example, linear detrending might be a "default", or the order of polynomials for detrending, or the cost metric for registration.
  • Approaches to registration may vary (e.g., simple intensity-based vs. BBR (boundary-based registration))
  • cvnlab vs. other approaches (fmriprep). cvnlab pre-processing comes in different flavors, but may include some of the following unusual steps: multiple fieldmaps (and some crazy regularization strategies), upsampling (both in time and space), manually defining ellipses to focus registration on parts that you care about, direct to surface interpolation, upsampling FreeSurfer surfaces.