[Insight-developers] NeighborhoodOperatorImageFilter
Miller, James V (Research)
millerjv at crd . ge . com
Wed, 17 Dec 2003 09:49:53 -0500
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_001_01C3C4AD.07F4C7E6
Content-Type: text/plain;
charset="iso-8859-1"
John,
I checked in a few fixes to ITK that may resolve your problem. When you are
brave enough to update ITK, you will get the fixes. ITK just updated the
version of vnl used, which requires using CMake 1.8 and pretty much requires
building the entire system.
Here is what I changed to address the NeighborhoodOperator issue:
* itkDerivativeImageFilter now requires the output pixel type be a signed
datatype. I put a new concept into itkConceptChecking to support this
(thanks Brad).
* itkNeighborhoodOperatorImageFilter now uses an operator based on the
output pixel type (the Set method and the ivar are now consistent).
* itkNeighborhoodInnerProduct has a few casts to ensure datatypes.
Note that you may still have problems using an integral datatype as the
output of the DerivativeImageFilter if your image spacing is non-unity and
UseImageSpacing is on for the DerivativeImageFilter.
Jim
-----Original Message-----
From: John Galeotti [ mailto:jgaleotti at cmu . edu <mailto:jgaleotti at cmu . edu> ]
Sent: Sunday, December 14, 2003 7:18 PM
To: insight-developers at itk . org
Subject: [Insight-developers] NeighborhoodOperatorImageFilter
I believe that NeighborhoodOperatorImageFilter is currently broken in the
case where the input and output images are of different pixel types. I
believe this is due to the fact that
NeighborhoodOperatorImageFilter::m_Operator is of type
InputNeighborhoodType, while NeighborhoodOperatorImageFilter::SetOperator()
takes an argument of type OutputNeighborhoodType.
I believe that SetOperator() should take an argument of type
InputNeighborhoodType, and that in
NeighborhoodOperatorImageFilter::ThreadedGenerateData(), smartInnerProduct
should be declared to output values of type TOutputImage::PixelType. Other
filters (DerivativeImageFilter, for example) would then have to be modifed
to use the new SetOperator() format. This is code I am not familiar with,
however, so I would appreciate it if someone who knows a little bit more
about the architecture would review this and make changes as necessary.
My reason for needing this fixed is that I want to use DerivativeImageFilter
with byte input pixel values and short output pixel values, which currently
causes a compiler error.
John Galeotti
_______________________________________________
Insight-developers mailing list
Insight-developers at itk . org
http://www . itk . org/mailman/listinfo/insight-developers
<http://www . itk . org/mailman/listinfo/insight-developers>
------_=_NextPart_001_01C3C4AD.07F4C7E6
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">
<TITLE></TITLE>
<META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2>John,<BR><BR>I checked in a few fixes to ITK that may resolve
your problem. When you are brave enough to update ITK, you will get the
fixes. ITK just updated the version of vnl used, which requires using
CMake 1.8 and pretty much requires building the entire system.<BR><BR>Here is
what I changed to address the NeighborhoodOperator issue:<BR><BR>*
itkDerivativeImageFilter now requires the output pixel type be a signed
datatype. I put a new concept into itkConceptChecking to support this (thanks
Brad).</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2><FONT color=#0000ff>* itkNeighborhoodOperatorImageFilter now
uses an operator based on the output pixel type (the Set method and the ivar are
now consistent).</FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff></FONT></FONT> </DIV>
<DIV><FONT size=2><FONT color=#0000ff>* itkNeighborhoodInnerProduct has a few
casts to ensure datatypes.</FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff></FONT></FONT> </DIV>
<DIV><FONT size=2><FONT color=#0000ff>Note that you may still have problems
using an integral datatype as the output of the DerivativeImageFilter if your
image spacing is non-unity and UseImageSpacing is on for the
DerivativeImageFilter.</FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff></FONT></FONT> </DIV>
<DIV><FONT size=2><FONT color=#0000ff>Jim</FONT></DIV>
<DIV><BR></DIV></FONT><FONT size=2>
<P><BR>-----Original Message-----<BR>From: John Galeotti [<A
href="mailto:jgaleotti at cmu . edu">mailto:jgaleotti at cmu . edu</A>]<BR>Sent: Sunday,
December 14, 2003 7:18 PM<BR>To: insight-developers at itk . org<BR>Subject:
[Insight-developers] NeighborhoodOperatorImageFilter<BR><BR><BR>I believe that
NeighborhoodOperatorImageFilter is currently broken in the<BR>case where the
input and output images are of different pixel types. I<BR>believe this is
due to the fact that<BR>NeighborhoodOperatorImageFilter::m_Operator is of
type<BR>InputNeighborhoodType, while
NeighborhoodOperatorImageFilter::SetOperator()<BR>takes an argument of type
OutputNeighborhoodType.<BR><BR>I believe that SetOperator() should take an
argument of type<BR>InputNeighborhoodType, and that
in<BR>NeighborhoodOperatorImageFilter::ThreadedGenerateData(),
smartInnerProduct<BR>should be declared to output values of type
TOutputImage::PixelType. Other<BR>filters (DerivativeImageFilter, for
example) would then have to be modifed<BR>to use the new SetOperator()
format. This is code I am not familiar with,<BR>however, so I would
appreciate it if someone who knows a little bit more<BR>about the architecture
would review this and make changes as necessary.<BR><BR>My reason for needing
this fixed is that I want to use DerivativeImageFilter<BR>with byte input pixel
values and short output pixel values, which currently<BR>causes a compiler
error.<BR><BR>John
Galeotti<BR><BR>_______________________________________________<BR>Insight-developers
mailing list<BR>Insight-developers at itk . org<BR><A
href="http://www . itk . org/mailman/listinfo/insight-developers"
target=_blank>http://www . itk . org/mailman/listinfo/insight-developers</A><BR></P></FONT></BODY></HTML>
------_=_NextPart_001_01C3C4AD.07F4C7E6--