What Do you Expect From Neuroimaging Software

1
What Do you Expect From Neuroimaging Software ?

• Karl Young
• University of California, San Francisco
• Center for Imaging of Neurodegenerative Diseases,
  SFVAMC

2
Basic Premise

• Analysis Software is Such a Critical Component of
  Scientific Research That Care Should Be Taken In
  Defining Its Requirements And Use Particularly
  In Light Of New Technology
• How Does This Specifically Apply To Analysis of
  Neuroimaging Data ?

3
Analysis Challenges

• hard to validate
• Integration
• Format complexities
• Sharing data
• Batch processing
• OS neutral
• Performance
• Flexibity
• Version compatibility

4
Analysis Questionnaire

• Which imaging modalities do you study ?
• Where does your data come from ?
• Which/How Many packages do you use for analysis ?
• Can package(s) use data in various formats ?
• Who supports the package you use ?
• Is there documentation for the package ?
• How much does the package cost ?
• How easy is installation and maintenance of
  that/those package(s) ?
• What package(s) do groups performing similar
  analyses use ?
• Is it easy to share data (ignoring
  privacy/security)/analysis tools with other
  groups ?
• How reproducible are the results ?
• Are results easy to compare/pool with those of
  other groups ?
• Can you (or someone in your lab) easily extend a
  package (e.g. from performing tractography to
  performing probabilistic tractographt) ?

5
So What Are the Issues That Make Neuroimage
Processing Difficult ?(My List)

• Multiple/Incompatible Data Formats
• Some contain more information than others
• Different, sometimes unspecified coordinate
  systems
• Multiple/Incompatible Processing Algorithms
• Many commercial (sometimes expensive !) or freely
  available packages with different code for given
  task
• Difficulty of installation can be a show stopper
• Closed/Open source package and/or language
• Incompatible versions of supporting packages
• Often no support or adequate documentation
  available (e.g. maintained by unresponsive
  company or lab)
• Often hard to extend (e.g. language) or combine
  with other packages
• No Easy Means for Comparison of Results

6
E.g. from ISMRM

• Two groups found different results for regional
  glutamate changes, using different spectral
  fitting software who (if either) was right ?
• Either one method should be thoroughly tested and
  used thereafter (if affordable !), or groups
  should quote results from multiple methods

7
An Ideal To Shoot For (From the Sweave, Literate
Programming in R, Web Page)

• Reproducible Research
• Research should be reproducible. Anything in a
  scientific paper should be reproducible by the
  reader.
• Whatever may have been the case in low tech days,
  this ideal has long gone. Much scientific
  research in recent years is too complicated and
  the published details to scanty for anyone to
  reproduce it.
• The lack of detail is not entirely the author's
  fault. Journals have severe page pressure and no
  room for full explanations.

8
An Ideal To Shoot For (From the Sweave, Literate
Programming in R, Web Page)

• Reproducible Research
• For many years, the only hope of reproducibility
  is old-fashioned person-to-person contact. Write
  the authors, ask for data, code, whatever. Some
  authors help, some don't. If the authors are not
  cooperative, tough.
• Even cooperative authors may be unable to help.
  If too much time has gone by and their archiving
  was not systematic enough and if their software
  was unportable, there may be no way to recreate
  the analysis.

9
An Ideal To Shoot For (From the Sweave, Literate
Programming in R, Web Page)

• Reproducible Research
• Fortunately, the internet comes to the rescue. No
  page pressure there!
• Nowadays, many scientific papers also point to
  supplementary materials on the internet, either
  at the journal's or the author's web site. It
  doesn't matter so long as the material is
  permanently available. Data, computer programs,
  whatever should be there.

10
An Ideal To Shoot For (From the Sweave, Literate
Programming in R, Web Page)

• Literate Programming (Knuth)
• Programs are useless without descriptions.
• Descriptions should be literate, not comments in
  code or typical reference manuals.
• The code in the descriptions should work. Thus it
  is necessary to extract the real working code
  from the literary description.

11
References

• Statistical Analyses and Reproducible Research -
  Robert Gentleman, Duncan Temple Lang
  http//www.bepress.com/bioconductor/paper2/
• WaveLab and Reproducible Research - Jonathan B.
  Buckheit and David L. Donoho
• Reproducible electronic documents -
  http//sepwww.stanford.edu/research/redoc/

12
Some Attempts to (At Least In Part) Make
Neuroimge Processing Easier And More Reproducible

• Human Brain Project (HBP - NIH)
• BioInformatics Research Netwrok (BIRN - NIH)
• Statistical Parametric Mapping (SPM) Package
• FMRIB Software Library (FSL)
• AFNI
• VoxBo
• BrainVoyager
• MEDx
• iBrain
• fmristat
• BrainTools
• Stimulate

13
Human Brain Project

• From the PA
• The purpose of this initiative is to encourage
  and support investigator- initiated research on
  neuroscience informatics (neuroinformatics). This
  research will lead to the development of new web
  based databases, analytical tools, and knowledge
  management systems to foster sharing of data for
  all domains of neuroscience researchIn order for
  these advanced information technologies to be put
  to wide use by the neuroscience community, they
  should be generalizable, scalable, extensible,
  and interoperable, and be developed in concert
  with significant neuroscience research.
• worked pretty well
• didnt work so well (why ?)

14
BIRN

• Created in 2001 with NCRR support, BIRN is a
  national consortium of 28 research institutions
  and 37 research groups dedicated to creating a
  usable cyberinfrastructure that shares and
  integrates data, expertise, and unique
  technologies from multiple disciplines and
  research institutions thereby enabling
  collaborations that address complex
  health-related problems. Initial efforts focus on
  neuroimaging data, but the tools and technologies
  developed by BIRN will ultimately be applicable
  to other disciplines.
• whew !

15
SPM

• Statistical Parametric Mapping refers to the
  construction and assessment of spatially extended
  statistical processes used to test hypotheses
  about functional imaging data. These ideas have
  been instantiated in software that is called SPM.
  The SPM software package has been designed for
  the analysis of brain imaging data sequences. The
  sequences can be a series of images from
  different cohorts, or time-series from the same
  subject. The current release is designed for the
  analysis of fMRI, PET, SPECT and similar
  modalities. Future releases will incorporate the
  analysis of EEG and MEG.

16
FSL

• FSL is a comprehensive library of image analysis
  and statistical tools for FMRI, MRI and DTI brain
  imaging data. FSL is written mainly by members of
  the Analysis Group, FMRIB, Oxford, UK

17
AFNI

• AFNI is a set of C programs for processing,
  analyzing, and displaying functional MRI (FMRI)
  data - a technique for mapping human brain
  activity. It runs on UnixX11Motif systems,
  including SGI, Solaris, Linux, and Mac OS X. It
  is available free (in C source code format, and
  some precompiled binaries) for research
  purposes.

18
VoxBo

• VoxBo is a free software package for processing
  functional brain imaging data. It runs on Linux
  and OSX, and is made freely available, complete
  with source code, under the terms of the GNU
  General Public License.

19
Successes And Limitations So Far

• Successes
• New algorithms provided
• New research fostered
• Open source algorithms at least partially
  extensible
• Limitations
• No widely adopted standards established
• Failure to allow comparison of analysis and/or
  data sharing
• Many platform restrictions
• Most only partially open source
• All either hard to install, use, maintain, and/or
  extend

20
What Could A New Project Offer Other Than Being
Yet Another Package (YAP)

• To Avoid Being Just YAP Need
• Open Source top to bottom (future of science !)
• Freely available ( )
• Widely adopted
• Good support and documentation (e.g. via large
  user base and self documenting language)
• Decentralized administration and maintenance
• Provide easily extended basic neuroimaging tool
  kit
• Provide easy access to widely vetted and
  optimized libraries from the larger scientific
  community

21
Is There Any Such Thing ?

• The R statistical language is an example for
  statisticians
• Stable open source, multiplatform, freely
  available, widely used, well supported and
  documented, non-centrally maintained, base
  package
• Linked to state of the art numerical and
  graphical libraries
• Current research code available that is built on
  top of extensible, stable base package

22
How About For Neuroimaging ?

• Where do current projects/packages fall short
• For HBP packages no protocol for requiring open
  source, distribution mechanisms, support,
• BIRN has done better but differences between the
  players have prevented development of a uniform
  code base and little or no support exists for non
  BIRN members
• For SPM support is centralized in 1 lab and non
  open source nature of Matlab core creates
  problems (e.g. licensing scheme is impossible to
  reconcile with parallelization as with IDL)
• FSL, AFNI, VoxBo are not multiplatform, support
  is sketchy, and none were designed to be easily
  maintained or extended.

23
How About For Neuroimaging ?

• Help is on the way ! Neuroimaging in Python
  (NiPy) a small step for Neuroimaging
• Currently in design phase (some usable code
  already) - is an attempt to address the
  aforementioned issues

24
NiPy

• Based on Python particular language not
  important - but that its fully open source, easy
  for scientists to program in, well designed, has
  a large user base and excellent support, and
  provides easy access to a wide variety of
  optimized scientific libraries is important
  (python appears to be the only language currently
  satisfying all of the above)

25
NiPy

• Built on top of SciPy a robust scientific
  python library (letting SciPy wrap and maintain
  version control over sub packages in the base
  makes installation and maintenance much easier)
• Interfaced to Vtk and Itk for providing advanced
  graphical and numerical capabilities
• Easy to write (or have someone else write) C,
  C, Fortran code and interface it to NiPy via
  SWIG, Boost, Weave,
• The NiPy base is currently being designed
  carefully with an eye towards ease of
  installation, use, maintenance and extension

26
NiPy

• Strong team already on board (built from ground
  up) many in the neuroimaging software
  community have acknowledged the potential utility
  of NiPy.
• Current contributors
• Jonathan Taylor (Stanford, SPM)
• Mathew Brett (Oxford, SPM)
• Jean-Baptiste Poline (Orsay, SPM)
• Tom Nichols (U Mich, SPM)
• John Hunter (U Chicago, SciPy, MatPlotLib)
• Yann Cointepas (Orsay, BrainVisa)
• Fernando Perez (U Colorado, SciPy)
• Federico Turkheimer (Imperial College, SPM,
  PhiWave)
• Jarod Millman (Berkeley, Project Coordinator)
• many others

27
NiPy

• Large User Base ?
• Thats why Im boring you with this talk i.e.
  to convince you that NiPy is the future of
  neuroimage processing and that you ignore it at
  your peril !
• Should be useful by sometime this Fall (already a
  substantial code base) - need to add some basic
  functionality like nonlinear image registration
  and probabilistic tractagoraphy (ported from FSL)
  before first big release
• Future additions will include processing of
  spectroscopy data (Andrew Maudsley has made
  noises about agreeing to have large parts of
  MIDAS ported to python/NiPy)