[Insight-users] borders on BoxSigmaImageFilter

[Matthew McCormick (thewtex)]

Thank you very much for the pointer to the paper.

I just figured out the problem -- it was in my adaptation -- I missed
the edge section as you suggest.

Anyway, thanks for your work on those filters.  Getting the filter to
work properly on the borders was tricky -- I'm glad I did not have to
figure it out ;-)

On Tue, Apr 27, 2010 at 11:18 PM, Richard Beare <richard.beare at gmail.com> wrote:
> Hi,
> The article is "Efficient implementation of kernel filtering",
> http://hdl.handle.net/1926/555, but I doubt that it goes into that
> level of detail. Is the zero border visible in all versions - i.e.
> mean and sigma filters, or only the new version? it is possible that
> the edge details were overlooked, because we were really interested in
> speed and the performance of the separable versions of mean and
> standard deviation were faster provided you were interested in only
> one kernel size.
>
> If you increase the kernel size and see an increase in the zero border
> then it is caused by out laziness in not adapting the processing
> necessary for border pixels.
>
>
> On Wed, Apr 28, 2010 at 4:46 AM, Matthew McCormick (thewtex)
> <matt at mmmccormick.com> wrote:
>> Hi Dr. Beare, Dr. Lehmann, and list,
>>
>> I was happy to find the itk::BoxMeanImageFilter and
>> itk::BoxSigmaImageFilter, and the considerable effort that went into
>> calculating these quantities efficiently with a running sum via a
>> ShapedNeighborhoodIterator.  I am looking at using an adapted version
>> of the BoxSigmaImageFilter during calculation of the pixelwise
>> normalized correlation coefficient.
>>
>> However, I am running into a problem: a unity pixel border at the
>> output requested region has the value of zero.  See the attached
>> image.
>>
>> Is this expected?  Am I not using the filter properly?  A bug?  I
>> tried looking for an Insight Journal article, but did not have any
>> luck.
>>
>> Thank you,
>> Matt
>>
>