[Insight-developers] Streaming and minipipelines

[Cory Quammen]

Brad and Jim,

Thanks for your guidance!

Cory

On Thu, Jul 14, 2011 at 11:36 AM, Jim Miller <millerjv at ge.com> wrote:
> Cory,
> As Brad points out your outer filter is responsible for establishing the
> proper requested regions for the internal filters. You can either hand code
> what the complete requested region should be for the mini-pipeline, or you
> can instantiate a mini-pipeline in the GenerateInputRequestedRegion and ask
> it for the requested region it needs.  What you don't want to do is wait for
> the GenerateData() method for the mini-pipeline to put in a "different"
> request. That may cause the filters above it to executed a second time. This
> is one of Brad's points.
> The localinput pattern that Brad provides is a good way to insulate the
> mini-pipeline from the outer pipeline. This was needed in the
> DiscreteGaussian filter as it internally streams a mini-pipeline. Here, the
> filter asks for the output requested region padded by the kernel size. But
> internally to GenerateData, we use the streaming mechanism to divide the
> processing through the mini-pipeline.  This is to limit the amount of memory
> used to blur a volume while allowing the intermediate voumes to be floating
> point precision.  Without the localinput pattern, the streaming of the
> mini-pipeline internally to the GenerateData method would cause the input to
> the DiscreteGaussian to be Modified whenever a RequestedRegion was
> established. This would cause future re-rexecutions of the DiscreteGaussian
> that were unnecessary.
> Jim
> On Jul 14, 2011, at 10:33 AM, Bradley Lowekamp wrote:
>
> Hello Cory,
>
> Currently best documentation on streaming is section 13.3 of the Software
> Guide and your text editor with the core pipeline objects open, and a good
> streaming filter.
>
> Streaming a mini-pipeline is a little clunky. With this filter currently
> there are a couple subtle issues that can cause excess pipeline execution.
> Streaming correctly is not only compute the correct output, but also no
> causing the upstream filters to execute extra-times that aren't needed, or
> other extra computation. In generally when you are streaming you have very
> large images, this extra computation is not productive. As your filter
> currently is, this may occur.
>
> The following is what I think is the preferred way for mini-pipelines.
>
> In GenerateInputRequestedRegion() compute exactly what the RR's for the
> mini-pipeline will be and set the input images to that.
>
> In the generate data method, insulate the mini-pipline from being connected
> to the exterior pipeline with a graft:
>
>  // Create an internal image to protect the input image's metdata
>  // (e.g. RequestedRegion). The StreamingImageFilter changes the
>  // requested region as part of its normal processing.
>  typename TInputImage::Pointer localInput = TInputImage::New();
>  localInput->Graft( this->GetInput() );
>
> by doing this you will minimize chatter in the pipeline and subtle bugs will
> be readily apparent.
>
>
> For your case, for input1 you want to mimic
> itk::DiscreteGaussianImage::GenerateInputRequestedRegion. then add setting
> the kernel input to the largest possible region (
> DataObject::SetRequestedRegionToLargestPossibleRegion ).
>
>
>
> On Jul 14, 2011, at 9:36 AM, Cory Quammen wrote:
>
> Dear streaming experts,
>
> I am working on a filter with a minipipeline (ConvolutionImageFilter),
>
> and I want to make sure it supports streaming. For a given output
>
> request region, this filter needs to request a slightly larger input
>
> region from the image input and the largest possible region from the
>
> kernel image input.
>
> Now, assuming all the filters in the minipipeline support streaming,
>
> what should ConvolutionImageFilter::GenerateInputRequestedRegion() do?
>
> It seems to me that the minipipeline filters will handle generating
>
> the proper regions in the input for a given requested output region.
>
> If I do not override GenerateInputRequestedRegion(), my tests fail.
>
> However, if I do override GenerateInputRequestedRegion() and set the
>
> input requested regions for both inputs (image and kernel image) to
>
> have zero size, everything seems to work.
>
> If there is a presentation or wiki page on the particulars of
>
> streaming involving filters with minipipelines, I'm happy to be told
>
> to go read that. A few minutes of Googling didn't reveal anything.
>
> Thanks much!
>
> Cory
>
> --
>
> Cory Quammen
>
> Research Associate
>
> Department of Computer Science
>
> University of North Carolina at Chapel Hill
>
> http://www.cs.unc.edu/~cquammen
>
>
> Jim Miller
> Senior Scientist
> GE Research
> Interventional and Therapy
> GE imagination at work
>



-- 
Cory Quammen
Research Associate
Department of Computer Science
University of North Carolina at Chapel Hill
http://www.cs.unc.edu/~cquammen