<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.6944.0">
<TITLE>Re: [Insight-users] nested filters behaving like nested Image functions</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hi Jim,<BR>
<BR>
Thanks for your expert knowledge on pipeline behaviour...!<BR>
<BR>
Miller, James V (Research) wrote:<BR>
<BR>
> Jerome,<BR>
> <BR>
> With respect to C): Why is B not an image function? Is it only because the function you want does not exist and it exists as a filter? One option is to create an image function that does what you want.<BR>
<BR>
Yes exactly, the filter exisits but not its corresponding imageFunction. The filter can become complex, and rewrite an ImageFunction can be a little tedious...<BR>
<BR>
> <BR>
> To use a filter like this, you will need:<BR>
> <BR>
> 1) Make sure the outer filter's GenerateInputRequestedRegion() takes into account any padding needed by the inner filter.<BR>
> <BR>
> 2) Depending on the filter you are calling internally you may need to be a careful with managing the pipeline. At the 10,000 foot<BR>
> level, you should be able to specify a requested region on the output of the inner filter and call Update(). The output of the inner<BR>
> filter should not need to reallocate. The memory management within the pipeline will try to reuse a buffer if it is the same size or<BR>
> smaller than the current buffer. Calling Update() on the inner filter may affect the RequestedRegion of the outer filter's input.<BR>
> This may or may not cause a problem with the remainder of your processing. If you try to access the RequestedRegion<BR>
> of the outer filter's input after you do all the Update()'s on the inner filter, said RequestedRegion may be very small.<BR>
> <BR>
> A solution to this it to create a shallow copy of the outer filter's input image. Just create a new image of the same type<BR>
> as the input. Set the regions to match the outer filter's input regions. But instead of calling Allocate() just set the PixelContainer<BR>
> on the shallow image to be the same PixelContainer as the outer's filter's input. Then use this shallow copy as the input to<BR>
> your inner filters.<BR>
><BR>
Great, thanks. I will first try your last option hoping I can make it work.<BR>
<BR>
Regards,<BR>
<BR>
Jerome.<BR>
<BR>
> <BR>
> <BR>
> <BR>
><BR>
> -----Original Message-----<BR>
> From: insight-users-bounces+millerjv=crd.ge.com@itk.org [<A HREF="mailto:insight-users-bounces+millerjv=crd.ge.com@itk.org">mailto:insight-users-bounces+millerjv=crd.ge.com@itk.org</A>]On Behalf Of SCHMID, Jerome<BR>
> Sent: Tuesday, November 01, 2005 2:44 AM<BR>
> To: insight-users@itk.org<BR>
> Subject: [Insight-users] nested filters behaving like nested Image functions<BR>
><BR>
> Hi all,<BR>
><BR>
> Sorry for a subject title so complicated, I tried to find an "explicit" sentence...<BR>
><BR>
> In order to illustrate my questions, let's take a simple example:<BR>
><BR>
> filter A will perform this operation in its GenerateData() :<BR>
><BR>
> Given a set of pixels within the requested region of an input image I, do<BR>
> {<BR>
> // current Pixel in the input is named input_px. The corresponding pixel at the same position in the output is called ouput_px<BR>
> apply a filter B locally: "output_px = B( input_px)"<BR>
> }<BR>
><BR>
> Some remarks:<BR>
><BR>
> a) B should be created _before_ the traversal of the pixels set.<BR>
> b) B performs a _local_ treatment, that means it just needs a required region on the input (as usually performed in itk with the region enlargement techniques.)<BR>
> c) B is a filter, _not_ an imageFunction, that means that no current itk class allows to do:<BR>
><BR>
> B->SetInputImage(I);<BR>
> output_px = B->Evaluate( input_px_position );<BR>
><BR>
> The questions are then:<BR>
> 1) How to deal with remark c)? Should I:<BR>
> - create a requested region whose size is (1,1,1) in 3D and whose position is the current input pixel<BR>
> - set it to filter B<BR>
> - Update() on B<BR>
> - Retrieve the value of output_pixel with GetPixel()<BR>
><BR>
> 2) If my previous solution is correct, how the filter B will behave with successive SetRequestedRegion + Update() calls as we have to traverse a set of different pixels that are not continuous? As the size of the requestedRegion doesn't change, its internal buffered region will remains the same ( i.e requested region + elargement needed for processing)? Or due to call of GetPixel of different regions within the image, some allocation will be done?<BR>
><BR>
> I do not need to perform a kind of "GraftOutput() operation" as everytime I can copy the value of the output_pixel in another structure that is much leighter than the whole image as it is not very dense.<BR>
><BR>
> I hope I have been enough clear...!<BR>
><BR>
> Thank you!<BR>
><BR>
> Jerome<BR>
><BR>
><BR>
> -----------------------------------<BR>
> Jerome SCHMID<BR>
> Project Manager/ Engineer<BR>
> Augmented and Virtual Reality<BR>
> MIS Centre<BR>
> Prince of Wales Hospital<BR>
> Chinese University Of Hong-Kong<BR>
> -----------------------------------<BR>
><BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>