MINC/Future/Tconf20110223

From Wikibooks, open books for an open world
< MINC‎ | Future
Jump to navigation Jump to search

Notes for conference call on the Future of MINC, held Feb 23, 2011[edit | edit source]

Present[edit | edit source]

Patrick, Jim, Mallar, Marc, Samir (all the way from Singapore), John, Jason, Pierre, Alex, Mishkin, Anka, Dniel, Simon D, Simon E, Vlad & Louis

Topics[edit | edit source]

What is the goal of MINC? What is our goal?[edit | edit source]

  • MINC is a complex, powerful image file format that is self documenting, self describing, extensible, portable and specific for n-dimensional medical images. MINC has a standard API to ensure that files are read/written always conform to the MINC definition.
  • Our goal is to guarantee a future for MINC (and the MINC tools) in the face of competing file formats and software packages by simplifying the installation and use of the MINC libraries and tools.

From the users – the main request is simplicity:[edit | edit source]

  • Simple installation, single point of contact for progs/docs
  • Up-to-date documentation
  • Example software
  • Example analyses
  • A user interface

Software Distributions/ Computer systems supported[edit | edit source]

  • Linux ( Debian, ubuntu, redhat, )
  • Mac
  • Windows
This could open up a large user-base
but have issues with effort/resources. related to GUI
  • One package vs many small packages
  • License issues – what can be bundled and what can’t (MINC vs GPL license)
  • Testing
    • Comprehensive testing is required for each release
    • Dashboard-style testing/reporting?

I/O[edit | edit source]

  • Bindings for
  • MINC1 vs MINC2 API support and use
  • ITK & VTK – currently with limited support.
  • NIFTI support?
    • Lots of advantages from user’s perspective at first glance, but…
    • Disadvantages:
      • Viewer-centric definition of data ordering (radiological vs neurological) without this information in the file header
      • lack of robust coordinate system information
      • lack of intensity mapping info
      • will the users rise up and bite us?

What to link/association with[edit | edit source]

  • Neurodebian (Michael Hanke's neuro.debian.net)

Integration with other software tools[edit | edit source]

  • Osirix, ITK-snap, Elastix, ANTs

Software development tools[edit | edit source]

  • Needs:
    • include/integrate external developers (who can submit/ who do we trust?)
    • proper bug tracking
(Jim): real, live minc bugs can make sure that the bug has been noted by minc-dev and have some idea WRT fix status. Perhaps such a system could be integrated with a compensation model in which fixes or (approved) feature requests would be assigned a monetary value and then devs would be free to "sign-up" to work on a given request?
    • distributed version control systems yet? (git, hg, bzr, etc.)
    • Possibilities:
      • CVS repository @ MNI (or elsewhere)
      • NITRC (www.nitrc.org, they are keen to have us join + do they have git?).
      • Launchpad (launchpad.net)
      • Google code,
      • track

Documentation[edit | edit source]

MINC tools not in standard distribution[edit | edit source]

  • structure segmentation tools
    • Brain extraction mincBET
    • ANIMAL structure segmentation (Collins)
    • Hippocampus + MTL structures fusion labelling (Collins)
    • thalamus + basal ganglia (Mallar)
    • Lateral ventricle segmentation (V.Fonov)
  • surface segmentation
    • CLASP (Evans)
  • Analysis tools
    • fMRI stat
    • NIAK (Pierre B)
    • ITK Snap (Vlad's mods for minc; if minc properly supported in ITK, then this mod not needed)
    • ElastiX (Dante)
  • viewnup (Andrew)
  • PVE (Jossi)

Action items:[edit | edit source]

  • Who wants to participate
  • Who can be in charge of what
  • What is the next step
  • MINC Workshop / course