Algorithms:TCON 09 01 2006

From NAMIC Wiki
Revision as of 13:27, 18 December 2006 by Andy (talk | contribs) (Update from Wiki)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Home < Algorithms:TCON 09 01 2006

Conference Call Details:

Date: 9/1/06

Conference Telephone Number: (218) 936-1100

Conference ID: 51427#

Attending: Ross Whitaker, Guido Gerig, Martin Styner, Stephen Aylward, Allen Tannenbaum, Killian Pohl, Bruce Fischl, Polina Golland

Agenda: Next Core 1 meeting logistics, Core 1 visibility, nonrigid registration

Highlights:

  1. Next Core 1 meeting logistics: The 2007 Core 1 meeting will be mid to late May in Boston. Ross will handle logistics and consult with Bruce and Polina for advice on venue, etc.
  2. Core 1 Visibility: The following strategies for increasing core 1 visibility in the group were agreed upon:
    1. Document *submitted* papers (e.g. titles and abstracts) on the Wiki
    2. Encourage core 1 participants (students, researchers) to update wiki progress pages every two months.
    3. Better document Core 1 - Core 3 activities. This would entail more of these activities (plans for this are underway with the gen II DPBs) and planning and documenting them better.
    4. How about some code that has been delivered and is being used by core 3? (Ron)
  3. Nonrigid registration: There was significant discussion on this issue in the group. The following points arose and important and generally agreed upon:
    1. Registration can not be considered in isolation. Registration algorithms must be designed to work with specific processing pipelines where the type of data and purpose is well defined. For instance, if the registration is for the purpose of segmentation (via registration with an atlas) that would be different from building atlases, characterizing intersubject variability, etc. Also, the type of modality figures heavily. Thus, it probably only makes sense to integrate registration algorithms for specific pipelines. Killian's tissue classification pipeline is certainly an example. fMRI was listed as another.
    2. It's not clear of the degree of overlap that NAMIC should seek with other toolkits. Q: Should NAMIC registration algorithms be novel or merely implementations of known algorithms? Answer (from Ron, after the meeting): established algorithms should be in the kit as a bare minimum, and novel algorithms should be in there if they are needed to complete the task, and would be a big plus. Clearly the licensing issue is important, but doubts were raised about whether we should reimplement algorithms which are already available.
    3. Allen's student will be working on an implementation of their deformable registration algorithm that uses "earth movers" distance. Bruce will be doing some new work on nonrigid registration.
    4. ITK already has implementations of B-spline and finite element (FE) based registration algorithms. The B-spline code is an reimplementation (by Daniel R), but it does not appear to work as well as the original implementation. There appear to issues of efficiency and parameter setting. The group agreed that the FE implementation should be useful, but does not appear to be used or understood by people on this call. There was agreement that Core 2 should be asked to weigh in on this - to assess the nonrigid registration code that is already in ITK, investigate why it does not work, and advise on what it would take to fix it. Core 1 would be happy to have access to powerful ITK-based registration tools that reach efficiency, robustness and performance of the original code. Several Core 1 members have processing pipelines for brain segmentation and population-based DTI analysis which could be very useful to NAMIC Core 3 but which include non-ITK-based registration code.
    5. the wiki page http://wiki.na-mic.org/Wiki/index.php/Non_Rigid_Registration contains a discussion of non-rigid registration between various researchers in NA-MIC in which they compare their own experience and work with NAMIC needs - this discussion already reflects vivid interaction that is documented on the Wiki - and thus fulfills item 2.