[Insight-developers] Stopping a level set filter mid-iteration?

[Miller, James V (Research)]

Zachary, 

The intenstion was for the AbortEvent mechanism to handle these types 
of operations.

The AbortEvent is the mechanism that allows user code to signal
any filter that they would like the filter to stop execution.
Note, there is not a policy on whether the output to the filter
is necessarily valid after the abort event.  But in the case of the 
DenseFiniteDifferenceFilters, the output should be valid. (Since 
the output is valid at the IterationEvent() timepoint which is also 
when the Abort flag is checked.)

The basic mechanism is that you put logic in the IterationEvent
observer or the ProgressEvent observer to check whether the user
wants to stop the filter (usually by checking the state of some UI component).  
Then the observer sets the Abort flag on the filter.  The ProcessObject 
object will then throw a ProcessAborted exception which the UI can catch.

Can you not embed such logic in your UI? Or are you trying to write stop
a levelset by some evaluation in the observer code that is not related
to the user modifying a UI?

An alternative mechanisms using just observers is used in the SNAP
application (in the InsightApplications checkout).  A number of 
observers are used there to pause a level set, allow the user to 
change parameters, and continue the level set.

Jim




-----Original Message-----
From: Zachary Pincus [mailto:zpincus at stanford.edu]
Sent: Tuesday, May 03, 2005 1:56 PM
To: Miller, James V (Research)
Cc: insight-developers at itk.org
Subject: Re: [Insight-developers] Stopping a level set filter
mid-iteration?


I noticed the AbortEvent mechanism, but at least in the 
FiniteDifferenceImageFilter class, calling SetAbortGenerateData will 
cause a ProcessAborted exception to be thrown. This exception is then 
caught by the ProcessObject class, where it appears to be re-thrown 
again.

So unless I'm mistaken, it seems that user-level code would need to 
explicitly catch this exception to be able to deal gracefully an 
observer calling filter->SetAbortGenerateData(true). Is this the case?

If so, would it still be worthwhile to have a more graceful iteration 
termination mechanism for something like the 
FiniteDifferenceImageFilter, where the output should always be valid 
(if not optimal) even if terminated early? (It makes sense for an abort 
to cause an exception in the case of iterative filters which do not 
produce valid output until several iterations in, because then you 
would want the caller to know that something happened and the output is 
invalid.)

Thanks for any thoughts on the matter,

Zach


On May 3, 2005, at 9:37 AM, Miller, James V ((Research)) wrote:

> The AbortEvent mechanism for stopping any ImageToImageFilter should 
> work.
>
> filter->SetAbortGenerateData(true);
>
> This flag is checked by the progress report mechanism.
>
> (To re-run the filter, you may need to call ResetPipeline() on the 
> filter to clear some internal flags about the state of the filter).
>
> Jim
>
>
> -----Original Message-----
> From: insight-developers-bounces at itk.org
> [mailto:insight-developers-bounces at itk.org]On Behalf Of Zachary Pincus
> Sent: Tuesday, May 03, 2005 12:15 PM
> To: insight-developers at itk.org
> Subject: [Insight-developers] Stopping a level set filter 
> mid-iteration?
>
>
> Hello all,
>
> Is there a "proper" way to stop a level set filter (or, more generally,
> a subclass of itk::FiniteDifferenceImageFilter) midway through its
> iterations, via an observer object?
>
> Some optimizers have a StopOptimization() method for precisely this
> purpose, for example. Is there anything similar for
> FiniteDifferenceImageFilter subclasses? (I could just set MaxIterations
> to CurrentIterations from the observer object, I guess.)
>
> If there isn't any such mechanism, should there be? I'll happily add
> such a method to FiniteDifferenceImageFilter (after, of course, filing
> a bug in the bugtracker) if people agree.
>
> Zach Pincus
>
> Department of Biochemistry and Program in Biomedical Informatics
> Stanford University School of Medicine
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>