[Insight-developers] Insight Telcon Notes, 11 May 2001

[Paul Hughett]

Notes from the Insight Telcon on 11 May 2001

We should rotate the role of scribe rather than have one person do it
all the time.

The testing scripts now seem to be working properly.

Some developers on Windows VC++ have been having problems with dialog
boxes popping up in the middle of a supposedly automatic rebuild.  The
Insight FAQ discusses this issue; the key is to do "Build" rather than
the "Batch Build" that you would expect.

Some memory leaks have been showing up; Purify offers some tools for
detecting and diagnosing them.

There was some discussion of freeing memory used by objects in a
pipeline.  Smart pointers usually do the right thing by using
reference counts, but not always.  Weak pointers should be used within
cyclic references, which will otherwise escape garbage collection.
Explicitly freeing (a reference to) an object can be done by setting
the smart pointer to NULL (which decrements the reference count and
frees the object when it reaches zero).

There was more discussion on the registration methods and people
experimenting with them on real data.  There tend to be problems with
choosing the right normalization and registration parameters.  Some of
us have discovered that maximizing mutual information can give worse
results than other metrics (such as L2), judging the registration
results by eye; this problem does not seem to occur when registering a
image to a modified version of itself.  MI methods also seem to
require a pretty close match to begin with.  All in all, MI does not
seem to be the panacea that much of the literature claims.  Curiously,
there does not seem to be any publically available source code
implementation for MI registration.

There is a difference between programs/toolkits designed for algorithm
researchers and end users.  This shows up plainly in the registration
algorithms but no doubt affects other parts of ITK.

The ITK_DEBUG macro is the preferred way to generate debug output from
within ITK, but is not currently working on some platforms.  Pending a
solution of the problems, it's okay to use the more traditional fprintf
or cerr.

Getting the current size/shape of an Image or Mesh currently requires
a two-step process: call GetLargestPossibleRegion and cal GetSize on
that region.  Given the prevalence of this operation, implementing a
single-step method seems like a good idea.

Keeping track of who's doing what and preventing unintentional
duplication of effort is a continuing issue.  Somewhat related in the
problem of locating the class/methods needed to perform a particular
operation.  People should continue to announce their plans via the
mailing list, and solicit comments; an absence of negative comments
can be considered permission to go ahead.  Other options are to create
a thesaurus file in the repository (as part of the documentation) or
to use appropriate keywords in Doxygen to create an topical or keyword
index to ITK.

ImplicitFunctions and ImageFunctions seem to be different enough that
establishing a common base class to inherit from doesn't seem
worthwhile.  However, there do seem to be enough classes within the
general category of "multivariate functions" that looking for common
factors and nomenclature seems well advised.

The ImplicitFunction class name was objected to on the grounds that it
actually defines an explicit function (z = f(x,y)) rather than an
implicit one (f(x,y,z) = 0).  Following some discussion of
alternatives, everyone seemed reasonably happy with SpatialFunction.
SpatialFunctions should be provided as both image sources and image
filters, since they are useful in both modes.

Many of the ITK iterators do not follow the usual STL model, both
because they need side information to work and because of efficiency
concerns.  The style `for (it.Begin(); !it.IsAtEnd(); ++it)' seems to
work well for ITK iterators but might confuse new users accustomed to
the STL style.  Renaming our iterators as "circulators", "walkers", or
"runners" would help underline the distinction in users' minds.

Steve Aylward (I think it was his voice) has been working on a finite
difference solver for level sets and partial difference equations.


Paul Hughett, Scribe du jour