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

Thu May 5 14:54:45 EDT 2005

Zachary, 

I assume by bouncing you are referring to the levelset wiggling back
and forth about what "appears" to be a steady state position.

This is essentially a termination criterion problem.  At each iteration, 
each position in the levelset moves "independently" (this is not quite true since
the direction of levelset movement is influenced by neighborhoods).  One point 
may move left towards a minimum, while it neighbors may move to the right towards 
a minimum.  This changes the cost landscape (boundary match cost + levelset shape 
cost), and the points are now on the wrong side of the minimum.  The first point 
now moves to the right and its neighbors now move to the left. 

Most the termination criteria are looking at some global metric, say
average squared distance change in the zero levelset.

Intuitively what you want to do is check whether the level set is 
the same configuration as it was at some previous time-step. Or perhaps just
"sufficiently near" to where it was at a previous time step.

Turning this intuition into a termination criterion that does not require 
a lot of storage or a lot of time to compute is difficult.

But what we really want is some sort of naturally damped response to the levelset.

Jim

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

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
>