[Insight-developers] NeighborhoodOperatorImageFilter

Miller, James V (Research) millerjv at crd . ge . com
Mon, 15 Dec 2003 10:01:46 -0500


John, 

I am taking a looking at this now.  I am doing a build now after having
changed the NeighborhoodOperatorImageFilter and the NeighborhoodInnerProduct
files.  I'll see how the build/test goes.

Jim



-----Original Message-----
From: John Galeotti [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