[Insight-developers] NeighborhoodOperatorImageFilter

[Miller, James V (Research)]

John,

This is going to be a little tricky. The changes to the NeighborhoodOperator
and NeighborhoodInnerProduct compile cleanly.  There was definately an
inconsistency between the SetOperator type and the m_Operator variable.
Most of the time the input and output type of the neighborhood operator
filters are the same, so we haven't hit on this.

The problem is that the DerivativeImageFilter needs to define
an operator with signed elements. Since the output of the
DerivativeImageFilter 
has to be signed, it make sense for the operator to be based on the 
output type.

I'll either manage this using traits or define the operator type to be based
on the output pixel type. I'll let you know.

Jim




-----Original Message-----
From: Miller, James V (Research) [mailto:millerjv at crd . ge . com]
Sent: Monday, December 15, 2003 10:02 AM
To: 'John Galeotti'; insight-developers at itk . org
Subject: RE: [Insight-developers] NeighborhoodOperatorImageFilter


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
_______________________________________________
Insight-developers mailing list
Insight-developers at itk . org
http://www . itk . org/mailman/listinfo/insight-developers