Comparison of Coregistration Software

The following comments pertain mostly to coregistration, a.k.a. "spatial normalization", although the effect on subsequent processing steps flavors some of my opinions. I should stress that each of the programs mentioned below works very well, and I mention the good and bad points so that you are aware of issues you are likely to encounter, rather than as a knock on any package.

• FSL has a few well-defined, easy to use programs with a small number of input parameters. It works quite well.
  • Pros:
    • Robust: usually works, default (unspecified) parameters usually good.
    • Call via automated script or GUI.
    • Succinct and useful set of programs and parameters.
    • Basic but helpful display to check coregistration results.
    • NIfTI, the native file format, makes it easy to integrate into processing pipelines.
      • However, FSL does not implement the standard NIfTI file orientation.
    • Active user group.
  • Cons:
    • Limited to, at best, a 12-parameter affine fit.
    • The interpolation used for reslice introduces slightly more smoothing than many competitors.
    • Non-standard NIfTI file orientation. Currently, the file orientation treatment does not seem to be consistent across the FSL suite of programs, but this will change soon.
      
      
• AFNI is fairly comparable with FSL. The majority of the analyses performed in our lab to date have used AFNI. Tom Johnstone has an excellent lab-specific guide to AFNI.
  • Pros:
    • Wide variety of constituent programs- you can usually find something for a particular task.
    • Large number of parameters for most programs, so you can tailor results for your data.
    • Robust.
    • Called via automated script or GUI.
    • The native BRIK file format is arguably one of the best.
    • Very good file format conversions.
    • Active user group.
  • Cons:
    • Wide variety of constituent programs- it can take a while to find the program you need.
    • Large number of parameters for most programs, many of which do not have default values, so it is important that you specify good values.
    • Likes to work within the Talairach coordinate system. This is not a requirement, but many of AFNI's programs work better if Talairach coordinates have been placed. This is particularly true for the display programs.
    • Limited to, at best, a 39-parameter (non-linear) fit. This is a recent (and welcome!) addition to AFNI and I haven't had a chance to play with it yet. Initial reports are that it works well, and that (for the one study I have heard of that used this approach) switching from Talairach to MNI via @auto_tlrc yielded noticeable improvements in activation magnitudes. I guess this is not really a "con" but there you have it.
      
      
• SPM works quite well, but, due to its file format conventions, it is best if SPM is not mixed into a pathway with other packages.You should only consider using SPM if you are prepared to do the rigorous validation of left/right orientation for your data. (Of course, you should do this anyway, regardless of your analysis path!) I recommend using SPM for most PET data.
  • Pros:
    • Robust.
    • High-parameter fits possible (up to hundreds of parameters).
    • Matlab-based.
    • Active user group.
  • Cons:
    • Matlab-based.
    • Scripting is tricky. Using an automated script to analyze multpile subjects is not only a time saver compared to entering repetitive parameters into a GUI, but it can also greatly minimize operator error. SPM is more GUI-oriented than FSL or AFNI, and writing a computer script to automatically call individual SPM routines is difficult. In the latest version, SPM5, it is easier than before, but it is still quite a bit of work.
    • Difficult to deduce file orientation. This has improved a lot in the most recent version (SPM5) and the addition of the NIfTI file format seems to have helped this aspect a lot. The following comments apply more to older versions of SPM but are still worth considering even for the latest version. Careful checking is needed to make sure your data are not inadvertantly flipped Left/Right. There are several points where one can specify the desired file orientation: (i) each file may or may not contain its own transform stored in the header; (ii) a global variable for each installation indicates a preference for radiological or neurological orientation; (iii) each user can override this convention, either explicitly via the GUI, or via a transparent user-specific defaults file. Also, the specific approach for indicating orientation changes with every new release so it is a bit dicey to switch versions. Bottom Line: find a data set with an obvious left/right difference, and run it through the proposed analysis pathway to make sure you can track left/right.
      
      
• AIR. is purely a coregistration software package. It can perform very well but is challenging to use. I should preface the following list of "Cons" by saying that AIR was the first widely available package for coregistration of medical images, it is capable of excellent results, and for at least 10 years it was the industry-wide gold standard.
  • Pros:
    • High-parameter fits possible (>1000 parameters).
    • Coregisters 2D (slicewise) data as well as 3D (volumetric) data.
    • When it works, it works well.
    • Helpful website- a good resource to learn about the technical aspects of coregistration.
  • Cons:
    • Lacks display capabilities, so difficult to check results.
    • Cannot handle 4D timeseries data. To use EPI or dynamic PET data, you must first convert the 4D data to a series of individual 3D files, then run AIR on each one, then afterwards convert the 3D files back to 4D.
    • Only reads ANALYZE-7.5 file format.
    • Data scaling is hard to impossible. If you need quantitative data (PET) or to preserve relative values across runs (ASL), find another program. AIR cannot use floating-point data, so you must first convert your data to 16-bit integer format and keep track of the scaling factor. After running AIR, you must reapply the scaling factor. However, you also have to guess how much smoothing was inroduced by interpolation, so you can properly readjust the output range.
    • Different versions of AIR are required depending on the precision (8-bit or 16-bit) and the range (-32k - + 32k, 0-64k, 0-32k) of your data. This is not autodetected by AIR (most desireable), nor is it set via a command-line flag (mid-desrable). You must actually call a whole different compiled version of AIR with a different path, depending on the data type.
    • Default parameters not very robust. This is especially true for the "threshold" parameters. Related to this is:
    • Lacks a true Mutual Information cost function.
    • Unsupported- development seems to have stopped in 2002.
      
      
• Python. For all you Python programmers, I have several Python libraries and standalone programs which implement various coregistration-related programs:
  /apps/dev/python_apps/coreg_wrappers.py
  /apps/dev/python_apps/image_manip.py
  /apps/dev/python_apps/coreg_MRI2template.py
  /apps/dev/python_apps/coreg_PETs_2_MRItemplate.py