[Insight-developers] Neighborhoods and filter output types
Miller, James V (CRD)
millerjv@crd.ge.com
Wed, 17 Oct 2001 14:01:30 -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_01C15735.BFBAFB30
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C15735.BFBAFB30"
------_=_NextPart_001_01C15735.BFBAFB30
Content-Type: text/plain;
charset="iso-8859-1"
At the tcon on Friday, we discovered that we do have a GradientImageFilter that operates using
traditional directional derivatives. We have one gradient image filter that uses recursive
gaussians, and one that uses difference of gaussians. To fill out the suite, I decided to write a
GradientImageFilter using traditional directional derivatives. I started by taking a copy of the
GradientMagnitudeImageFilter and removed the magnitude calculation.
Here are the issues I hit upon the way:
Output type for a GradientFilter
The first problem was that the output type of a gradient image filter needs an image of Covariant
vectors. So I removed the TOutputImage template parameter of the filter and constructed the proper
output type when specifying its inheritance from ImageToImageFilter. Not all the gradient image
filters made the same decision.
* DifferenceOfGaussiansGradientImageFilter is templated over input image type and a value type
to use in the CovariantVector for the output image. This is close to what I have done. However, this
filter needs a little work to make sure the CovariantVector is the proper length. Damion, take a
look at the GradientImageFilter derivation line.
* RecursiveGaussianGradientImageFilter is templated over the input image type, the output image
type, and a computation value type (used for intermediate results). This filter requires the user to
instantiate the filter with the proper output type (namely a CovariantVector pixel type). Strictly
speaking, this filter allows the output type to be any pixel type that support operator[]. But if we
are going to use CovariantVectors for gradients, we should probably restrict this filter to produce
CovariantVector images.
Calculations with Neighborhood Operators
The NeighborhoodOperators and associated filters assume that the operator pixel type is the same data
type as the image pixel type over which you are going to apply the operator. This is limiting when
you need to take the derivative of a unsigned image. It requires the user to cast the image to a
signed image.
I modified the NeighborhoodInnerProduct code to that is templated over an image, an operator value
type, and computation value type. The computation value type is the data type to use for the output
of the inner product calculation. The operator value type can be different from the image value type.
So an operator can have floating point values and the image can be unsigned short and the output can
be a long. The operator type and output type default to the image pixel type.
These changes allowed me implement the GradientImageFilter in proper precision. The
GradientImageFilter is templated over an input image type, an operator value type, and output value
type. The appropriate derivative operators and output covariant vectors are constructed
automatically.
However, now we have an inconsistency for the template arguments for the various gradient image
filters. Can we decide on a consistent set of template parameters for these filters. Furthermore,
some of the filters are not templated over the output image type. Does the latter prevent
ImageAdaptors? Do we allow "output adaptors" anymore?
Having made these changes for the GradientImageFilter, I'd like to propagate them to the
DerivativeImageFilter and the GradientMagnitudeImageFilter. Specifically, the ability to set the
value type used for the operators. Then, what about the NeighborhoodOperatorImageFilter?
DerivativeOperator
Should the derivative operator take into account the spacing of the data? Or should the derivative
just be in parametric space and whomever uses the derivative operator (like the
DerivativeImageFilter) must decide to convert the values to physical space. I can go either way on
this one.
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_01C15735.BFBAFB30
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.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=064482117-17102001><FONT size=2>At the tcon on Friday, we
discovered that we do have a GradientImageFilter that operates using traditional
directional derivatives. We have one gradient image filter that uses
recursive gaussians, and one that uses difference of gaussians. To fill
out the suite, I decided to write a GradientImageFilter using traditional
directional derivatives. I started by taking a copy of the
GradientMagnitudeImageFilter and removed the magnitude
calculation.</FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2>Here are the issues I hit upon
the way:</FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2><STRONG><U>Output type for a
GradientFilter</U></STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2>The first problem was that the
output type of a gradient image filter needs an image of Covariant
vectors. So I removed the TOutputImage template parameter of the filter
and constructed the proper output type when specifying its inheritance from
ImageToImageFilter. Not all the gradient image filters made the same
decision.</FONT></SPAN></DIV>
<UL>
<LI><SPAN class=064482117-17102001><FONT
size=2>DifferenceOfGaussiansGradientImageFilter is templated over input image
type and a value type to use in the CovariantVector for the output image. This
is close to what I have done. However, this filter needs a little work to make
sure the CovariantVector is the proper length. Damion, take a look at
the GradientImageFilter derivation line.</FONT></SPAN></LI>
<LI><SPAN class=064482117-17102001><FONT
size=2>RecursiveGaussianGradientImageFilter is templated over the input image
type, the output image type, and a computation value type (used for
intermediate results). This filter requires the user to instantiate the
filter with the proper output type (namely a CovariantVector pixel type).
Strictly speaking, this filter allows the output type to be any pixel type
that support operator[]. But if we are going to use CovariantVectors for
gradients, we should probably restrict this filter to produce CovariantVector
images.</FONT></SPAN></LI></UL>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2><STRONG><U>Calculations with
Neighborhood Operators</U></STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><STRONG><U><FONT
size=2></FONT></U></STRONG></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2>The NeighborhoodOperators and
associated filters assume that the operator pixel type is the same data type as
the image pixel type over which you are going to apply the operator. This
is limiting when you need to take the derivative of a unsigned image. It
requires the user to cast the image to a signed image. </FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2>I modified the
NeighborhoodInnerProduct code to that is templated over an image, an operator
value type, and computation value type. The computation value type is the
data type to use for the output of the inner product calculation. The operator
value type can be different from the image value type. So an operator can
have floating point values and the image can be unsigned short and the output
can be a long. The operator type and output type default to the image
pixel type.</FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2>These changes allowed me
implement the GradientImageFilter in proper precision. The
GradientImageFilter is templated over an input image type, an operator value
type, and output value type. The appropriate derivative operators and
output covariant vectors are constructed automatically.</FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2>However, now we have an
inconsistency for the template arguments for the various gradient image
filters. Can we decide on a consistent set of template parameters for
these filters. Furthermore, some of the filters are not templated over the
output image type. Does the latter prevent ImageAdaptors? Do we allow
"output adaptors" anymore?</FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2>Having made these changes for
the GradientImageFilter, I'd like to propagate them to the DerivativeImageFilter
and the GradientMagnitudeImageFilter. Specifically, the ability to set the value
type used for the operators. Then, what about the
NeighborhoodOperatorImageFilter?</FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT
size=2><STRONG><U>DerivativeOperator</U></STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2>Should the derivative operator
take into account the spacing of the data? Or should the derivative just
be in parametric space and whomever uses the derivative operator (like the
DerivativeImageFilter) must decide to convert the values to physical
space. I can go either way on this one. </FONT></SPAN></DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=064482117-17102001><FONT size=2></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_01C15735.BFBAFB30--
------_=_NextPart_000_01C15735.BFBAFB30
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_01C15735.BFBAFB30--