[Insight-users] Pipeline question

Miller, James V (Research) millerjv at crd . ge . com
Thu, 15 May 2003 17:04:50 -0400


Paul,

I took out the call to Modified() in SetRequestedRegion() in ImageBase.
This should address the issue you raised. The change is in version 1.45 of 
ImageBase.h and 1.26 of ImageBase.txx

Please give this a try and let me know if this works for you.

Thanks for pointing this out.

Jim



-----Original Message-----
From: Paul Yushkevich [mailto:pauly@cognitica.com]
Sent: Thursday, May 15, 2003 10:56 AM
To: Miller, James V (Research)
Cc: insight
Subject: Re: [Insight-users] Pipeline question


Miller, James V (Research) wrote:

I wrote my own filter to accomodate the needs of our application, and 
here is the code for it.  I've marked the place of interest with a large 
//**** comment.

Paul.



>Paul,
>
>What filter are you using to extract the slices?
>
>Jim
>
>
>-----Original Message-----
>From: Paul Yushkevich [mailto:pauly@cognitica.com]
>Sent: Thursday, May 15, 2003 9:35 AM
>To: Miller, James V (Research)
>Cc: insight
>Subject: Re: [Insight-users] Pipeline question
>
>
>James,
>
>Let me try to clarify the problem.
>
>Let's say I have a large 3D image that never changes.  I then have the 3 
>slicing filters, each of which is followed by an intensity remapping 
>filter, then followed by a padding filter that makes the slices 256x256 
>and then by another 'mapper' that stores the slices in texture memory 
>for display.  I update these mappers each time that my GUI needs to 
>redraw.  However, I would like the pipeline to cache the output of the 
>slicing and preprocessing and texturing filters as long as I don't 
>change their parameters (e.g. the slice number to display)
>
>What happens is that this display pipeline gets executed every time that 
>Update is called on the texturing mappers at the end of the pipeline.  I 
>think that that happens because the call to Update causes the 
>RequestedRegion to be propagated backwards through the pipeline.  For 
>each of the 3 slices, a different RequestedRegion is set in the 3D 
>image.  As a result, the 3D Image's MTime gets incremented for each of 
>these Updates(), and then the whole pipeline gets executed, and no 
>caching occurs.
>
>Now, I can get around this problem by having the slicing filters set 
>their input's requested region to be the LargestPossibleRegion.  That's 
>fine for a static 3D image that I have described, but imagine that the 
>3D image is an output of another pipeline, and I want to run that 
>pipeline only for the pixels in the slices.  In this situation, setting 
>RequestedRegion to the LargestPossibleRegion is not what I want
>
>Thank you!
>
>Paul.
>
>
>Miller, James V (Research) wrote:
>
>  
>
>>Paul,
>>
>>Let me see if I understand the problem correctly.
>>
>>You have a pipeline where near the end of the pipeline you have 3 separate
>>slice extraction filters.  When you call Update() on the slice extraction
>>filters in succession, the entire pipeline re-executes? Or just the slice
>>extraction filters re-execute?
>>
>>Is the input image to the three slice extraction filters "big enough" to
>>support all three requests? If every filter before the slice extraction
>>filter that you are executing properly handles streaming, then filter
>>    
>>
>before
>  
>
>>the slice extraction filters would probably have only produced just enough
>>output to support the first slice extraction request.  When the second
>>request arrives, the pipeline would re-execute to generate the new
>>    
>>
>requested
>  
>
>>region.
>>
>>One thing you might want to check is whether the BufferedRegion is
changing
>>on the input to the slice extraction filters after each successive call to
>>Update() on the slice extraction filters. If it is changing, then it means
>>that when the filter before the slice extraction gets each request, it
>>thinks it needs to re-execute.  One thing you can try is to call
>>UpdateLargestPossibleRegion() on the filter before the slice extraction
>>filters so that all the output (to that point) is available.  Then the
>>    
>>
>slice
>  
>
>>extraction filters should never cause the filter before the slice
>>    
>>
>extraction
>  
>
>>filter to re-execute.
>>
>>The last time I tested things like this explictly was a couple of months
>>    
>>
>ago
>  
>
>>when I added InPlace filters.  Here I exercised the pipeline quite a bit
to
>>make sure branches of a pipeline properly executed.  But your issue may be
>>particular to the slice extraction filter.
>>
>>But if the filter before the slice extraction filter is not re-executing
>>    
>>
>but
>  
>
>>the slice extraction filters are always re-executing, then that is a
>>different issue.  This could therefore be an MTime issue.
>>
>>If you could whittle this down to a small test program that would
certainly
>>help us out.
>>
>>
>>
>>-----Original Message-----
>>From: Paul Yushkevich [mailto:pauly@cognitica.com]
>>Sent: Wednesday, May 14, 2003 5:02 PM
>>To: insight
>>Subject: [Insight-users] Pipeline question
>>
>>
>>Hi,
>>
>>I have a small question about the pipeline.
>>
>>I have a large image that is the input to three slice extraction filters 
>>that operate on different regions of the image.  Now, every time I call 
>>Update() on the outputs of these filters, the entire pipeline gets 
>>rerun, even though neither the input image nor the parameters of the 
>>filters had changed.
>>
>>I traced this down to the fact that the input image is Modified() every 
>>time its requested region  changes.  As different RequestedRegions are 
>>propagated from the three different filters, the input image's MTime 
>>gets incremented, and the image appears as if it has changed, even 
>>though it really hadn't.
>>
>>Is there any way around this issue?  I want to be able to call Update() 
>>frequently on the outputs of the three slice filters, but only have the 
>>filters run if the image or the filter parameters have changed.
>>
>>Paul
>>
>> 
>>
>>    
>>
>
>
>  
>


-- 
--------------------------------
Paul A. Yushkevich, Ph.D.
President, Cognitica Corporation

17 Flemington Rd
Chapel Hill, NC 27517
Tel: 1-919-929-7652
--------------------------------