[Insight-developers] Updated architecture assessment
Miller, James V (CRD)
millerjv@crd.ge.com
Tue, 25 Sep 2001 10:48:20 -0400
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C145D1.1EC28330
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C145D1.1EC28330"
------_=_NextPart_001_01C145D1.1EC28330
Content-Type: text/plain;
charset="iso-8859-1"
Will and I continued our march through the Insight code yesterday. We want to thank those in the
group who have modified their objects based on the first assessment (and told us that they made
modifications). The spreadsheet has been updated.
We also reviewed another 20 classes in Algorithsm yesterday. In general, these objects need more
work than those reviewed in BasicFilters. We found ivars with "_" in their name which is not in our
Style Guide. Most of the reviewed classes were missing PrintSelf() methods and most had sparse
documentation.
One of the things were are looking for in the documentation is a "how" or "why" someone would use
this object. In some cases this is simple as adding a line saying "this filter reduces the noise in
an image". In other cases, it requires saying "this object is part of this larger subsystem. it is
used as the decision criteria in such-and-such an algortihm".
There are also some design issues that we would like to discuss.
1. Registration - We are still looking to reduce the length of the names and perhaps the number
of algorithms explictly called out.
1. Registration algorithms should be process objects that produce transforms. So
transformations need to be DataObjects that fit into the pipeline architecture so changes to data
cause transformations to be recalculated. This would streamline the development of interventional
applications. It looks like GE/Kitware would have to be involved to adapt the architecture so support
this.
2. The ImageToImage prefix should be changed to an RegistrationImageFilter suffix. We can
assume that an RegistrationImageFilter class takes two images as input. Similar for Mesh
registration. Only the ImageToPointSet, ImageToMesh special cases need to be called out.
3. We suggest changing the architecture so we have a single RegistrationImageFilter that has
SetTransform(), SetMetric(), and SetOptimizer() methods. The default implementation would a rigid,
mean square, gradient descent registration. We could provide convenience methods like
SetMetricToMutualInformation() that would swap in a mutual information metric object. It looks like
the special code in each of the current "methods" is related to the selected "transform". So we need
to determine the impact of having a single registration filter on tying transforms to the optimizers.
2. ImageMapper
1. This seems to combine two operations "probing" and "resampling". Should this be a
ProcessObject that ties into the pipeline or is this a low level object used strictly for
interpolation?
3. Classifiers
1. There seem to be two operations going on here. First, a decision criteria object that
decides whether something belongs to a certain category. Second, a filter that applies a decision
criteria to each pixel.
2. Classifiers are not ProcessObjects. The application of a decision criteria to an image
should be a "filter". So it should subclass from ImageToImageFilter. Also the "training" of a
classifier should probably fit into the pipeline mechanism. I could see an application where I would
want to "swap" what training sets are provided to a ClassifyImageFilter to see how they affect
segmentations.
4. Moments Calculator
1. This should probably be a ProcessObject. It could strictly pass its input to its output and
cache the current calculated moments.
Again, we are only looking at each object for a few minutes. So these comments are our first set of
observations. If you would like to do a more detailed review of a collection of objects, let us
know.
Jim Miller
_____________________________________
Visualization & Computer Vision
GE Corporate Research & Development
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301
millerjv@crd.ge.com < mailto:millerjv@crd.ge.com <mailto:millerjv@crd.ge.com> >
(518) 387-4005, Dial Comm: 8*833-4005,
Cell: (518) 505-7065, Fax: (518) 387-6981
------_=_NextPart_001_01C145D1.1EC28330
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=914300414-25092001><FONT size=2>Will and I continued our march
through the Insight code yesterday. We want to thank those in the group
who have modified their objects based on the first assessment (and told us that
they made modifications). The spreadsheet has been
updated.</FONT></SPAN></DIV>
<DIV><SPAN class=914300414-25092001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=914300414-25092001><FONT size=2>We also reviewed another 20
classes in Algorithsm yesterday. In general, these objects need more work
than those reviewed in BasicFilters. We found ivars with "_" in their name
which is not in our Style Guide. Most of the reviewed classes were missing
PrintSelf() methods and most had sparse documentation.</FONT></SPAN></DIV>
<DIV><SPAN class=914300414-25092001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=914300414-25092001><FONT size=2>One of the things were are
looking for in the documentation is a "how" or "why" someone would use this
object. In some cases this is simple as adding a line saying "this filter
reduces the noise in an image". In other cases, it requires saying "this
object is part of this larger subsystem. it is used as the decision
criteria in such-and-such an algortihm".</FONT></SPAN></DIV>
<DIV><SPAN class=914300414-25092001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=914300414-25092001><FONT size=2>There are also some design
issues that we would like to discuss.</FONT></SPAN></DIV>
<DIV><SPAN class=914300414-25092001><FONT size=2></FONT></SPAN> </DIV>
<OL>
<LI><SPAN class=914300414-25092001><FONT size=2>Registration - We are still
looking to reduce the length of the names and perhaps the number of algorithms
explictly called out. </FONT></SPAN></LI>
<OL>
<LI><SPAN class=914300414-25092001><FONT size=2>Registration algorithms
should be process objects that produce transforms. So transformations
need to be DataObjects that fit into the pipeline architecture so changes to
data cause transformations to be recalculated. This would streamline
the development of interventional applications. It looks like GE/Kitware
would have to be involved to adapt the architecture so support
this.</FONT></SPAN></LI>
<LI><SPAN class=914300414-25092001><FONT size=2>The ImageToImage prefix
should be changed to an RegistrationImageFilter suffix. We can assume
that an RegistrationImageFilter class takes two images as input. Similar for
Mesh registration. Only the ImageToPointSet, ImageToMesh special cases
need to be called out.</FONT></SPAN></LI>
<LI><SPAN class=914300414-25092001><FONT size=2>We suggest changing the
architecture so we have a single RegistrationImageFilter that has
SetTransform(), SetMetric(), and SetOptimizer() methods. The default
implementation would a rigid, mean square, gradient descent
registration. We could provide convenience methods like
SetMetricToMutualInformation() that would swap in a mutual information
metric object. It looks like the special code in each of the current
"methods" is related to the selected "transform". So we need to
determine the impact of having a single registration filter on tying
transforms to the optimizers.</FONT></SPAN></LI></OL>
<LI><SPAN class=914300414-25092001></SPAN><SPAN class=914300414-25092001><FONT
size=2>ImageMapper</FONT></SPAN></LI>
<OL>
<LI><SPAN class=914300414-25092001><FONT size=2>This seems to combine two
operations "probing" and "resampling". Should this be a ProcessObject that
ties into the pipeline or is this a low level object used strictly for
interpolation?</FONT></SPAN></LI></OL>
<LI><SPAN class=914300414-25092001><FONT size=2>Classifiers</FONT></SPAN></LI>
<OL>
<LI><SPAN class=914300414-25092001><FONT size=2>There seem to be two
operations going on here. First, a decision criteria object that
decides whether something belongs to a certain category. Second, a
filter that applies a decision criteria to each pixel. </FONT></SPAN></LI>
<LI><SPAN class=914300414-25092001><FONT size=2>Classifiers are not
ProcessObjects. The application of a decision criteria to an image
should be a "filter". So it should subclass from ImageToImageFilter.
Also the "training" of a classifier should probably fit into the pipeline
mechanism. I could see an application where I would want to "swap"
what training sets are provided to a ClassifyImageFilter to see how they
affect segmentations.</FONT></SPAN></LI></OL>
<LI><SPAN class=914300414-25092001><FONT size=2>Moments
Calculator</FONT></SPAN></LI>
<OL>
<LI><SPAN class=914300414-25092001><FONT size=2>This should probably be a
ProcessObject. It could strictly pass its input to its output and
cache the current calculated moments.</FONT></SPAN></LI></OL></OL>
<DIV><SPAN class=914300414-25092001><FONT size=2>Again, we are only looking at
each object for a few minutes. So these comments are our first set of
observations. If you would like to do a more detailed review of a
collection of objects, let us know.</FONT></SPAN></DIV><BR>
<P><B><FONT face="Comic Sans MS" color=#000080>Jim Miller</FONT></B>
<BR><B><I><FONT face=Arial color=#ff0000
size=2>_____________________________________</FONT></I></B><I></I><BR><I></I><I><FONT
face=Arial color=#000000 size=1>Visualization & Computer Vision<BR>GE
Corporate Research & Development<BR>Bldg. KW, Room C218B<BR>P.O. Box 8,
Schenectady NY 12301<BR><BR></FONT><U><FONT face=Arial color=#0000ff
size=1>millerjv@crd.ge.com <<A
href="mailto:millerjv@crd.ge.com">mailto:millerjv@crd.ge.com</A>></FONT></U></I><BR><I><FONT
face=Arial color=#000000 size=1>(518) 387-4005, Dial Comm: 8*833-4005,
</FONT></I><BR><I><FONT face=Arial color=#000000 size=1>Cell: (518) 505-7065,
Fax: (518) 387-6981</FONT></I> </P><BR>
<DIV> </DIV></BODY></HTML>
------_=_NextPart_001_01C145D1.1EC28330--
------_=_NextPart_000_01C145D1.1EC28330
Content-Type: application/octet-stream;
name="Miller, James V (CRD).vcf"
Content-Disposition: attachment;
filename="Miller, James V (CRD).vcf"
BEGIN:VCARD
VERSION:2.1
N:Miller;James
FN:Miller, James V (CRD)
ORG:CRD;ESL
TITLE:Computer Scientist
TEL;WORK;VOICE:*833-4005
TEL;WORK;VOICE:1 518 387-4005
ADR;WORK:;KW-C218B;P.O. Box 8;Schenectady;New York;12301;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KW-C218B=0D=0AP.O. Box 8=0D=0ASchenectady, New York 12301=0D=0AUSA
EMAIL;PREF;INTERNET:millerjv@crd.ge.com
REV:20010420T140329Z
END:VCARD
------_=_NextPart_000_01C145D1.1EC28330--