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

[Zachary Pincus]

Hello,

Thanks for your patient explanation of the AbortEvent mechanism  -- I 
guess I just needed to see it twice before getting the picture. Sorry 
to clog up the developer list with what just turned out to be a request 
for clarification.

I agree that using this general mechanism and including a try/catch 
statement around the code that calls the filter is a perfectly 
reasonable way to go about the task of terminating that filter. While I 
in general shy from using exceptions for "non-exceptional" flow 
control, this method seems generally reasonable, and not too GOTO-ish.

(I say "non-exceptional" because I have found that in my particular 
application, the level set solution is very prone to "bouncing", so 
essentially I will need to put a "bounce detector" into an observer and 
have that be the *main* method of terminating iteration. I was just 
leery of relying on exception handling as the default flow-control 
method, but that really shouldn't be too much of a problem. [A hard 
limit on iterations is not sufficient in this case because some input 
takes only tens of iterations before bouncing and others take 
hundreds!]. Out of curiosity, are there any good method for detecting 
bouncing, or pre-whitening the inputs so that bouncing is less likely?)

Thanks,

Zach



On May 5, 2005, at 6:31 AM, Miller, James V (Research) wrote:

> 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
>>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>