[Insight-developers] itkBinomialBlurImageFilter

Miller, James V (CRD) millerjv@crd.ge.com
Tue, 17 Jul 2001 07:47:37 -0400


Damion,

The problem with your original implementation is that you were changing the input size in the
GenerateData() method.  By the time GenerateData() is called, it is too late to make that change.
GenerateData() should not alter the input "regions" nor change the LargestPossibleRegion or
RequestedRegion of the output.

If a filter needs to generate a different amount of data than what was requested by the pipeline, the
filter should override EnlargeOutputRequestedRegion().

If a filter needs a different amount of data on input to produce the requested output, the filter
should override GenerateInputRequestedRegion().

If a filter is going to produce an image that has different spacing or a different origin or a
different LargestPossibleRegion() than the input, the filter should override
GenerateOutputInformation().

If a filter has multiple outputs but each output produces a different amount of data, the filter
needs to override GenerateOutputRequestedRegion().

These are part of negotiation through the pipeline to determine how much data each filter should
produce.  The problem with your initial implementation is that it ignored what the pipeline was
requesting and modified the input regions.

As for the implementation of GenerateInputRequestedRegion() I added to your filter, it does not
change the dimensionality of the image.  For an output image of dimension N, it still requests an
input image of dimension N (dimensions are all set at compile time).  However, if your pipeline
wanted to generate a single slice from a 3D volume of data, the input for this filter would have to
be 1 + 2*NumIterations slices and have a NumIterations pixel border around it.  The size of this
input image is clamped at the input's LargestPossibleRegion. If you do not request this amount of
input the calculation of the output image will be incorrect.

So the size of an image does change as it moves through the pipeline.  A size for the last output is
assigned by the last consumer.  This size is propagated back up the pipeline where the size of an
image will grow and shrink based on the types of operations being performed.

Jim


-----Original Message-----
From: Damion Shelton [mailto:dmsst59+@pitt.edu]
Sent: Monday, July 16, 2001 5:17 PM
To: Miller, James V (CRD); Insight-developers (E-mail)
Subject: Re: [Insight-developers] itkBinomialBlurImageFilter


Comments are below... in general I agree with the changes but I do have some
questions/comments.

> I checked in a version of your binomial blur image filter that should work
in the pipeline mechanism.

To my knowledge, it worked in the pipeline before. At least, it supported
chaining with SetInput/GetOutput. What was the problem?

> I added a GenerateInputRequestedRegion() method so that the filter can
request a bigger input than
> its output. Thus, the filter does not have to process the entire image.

This has caused some problems. For an image with dimension n, the output
image dimension is now n + numiterations*2. Although I understand why the
change was made, this causes some problems in assuming that a constant size
image passes through the pipeline (since it's not).

> I also reworked some of the loops and regions so you can avoid calling
GetIndex() and SetPixel() in
> favor of iterator access.

Sounds good.

> Unfortunately, there is no test for this filter.  So I couldn't check my
changes.

That will change soon; converting to itkPoint, combined with the
Scalar/ScalarVector changes have set me back a bit.

> This filter could be made multithreaded very easily.  If you agree with my
changes, then we should
> probably make this a multithreaded filter.

I'll let you know once it's working again.

-Damion-