[Insight-users] Progress event and DiscreteGaussianImageFilter

[Miller, James V (Research)]

As you noted, the StreamingImageFilter is now used internally to 
minimize memory usage with the DiscreteGaussianImageFilter.  Each filter
in the mini-pipeline now executes multiple times, each time on a different
section of the image.  The ProgressAccumulator simply adds the progress of 
each filter in the mini-pipeline.  As the mini-pipeline re-executes, the 
progress values go up, then down, then up, etc.

I noticed this issue when the changes were made to the DiscreteGaussian
filter.  At the time, I decided the issue was minor since the progress
mechanism is only meant to give an indication of the filter calculating and
to give an opportunity for an AbortEvent to be sent to the filter.  If this 
behavior is truly bothersome, I could change the filter to only report the 
progress of the StreamingImageFilter.  This would make the progress monotonic
but it would limit the opportunities to abort a filter and would results in
fewer progress events.

Jim

-----Original Message-----
From: insight-users-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org]On Behalf Of
Didier Rajon
Sent: Monday, September 12, 2005 12:40 PM
To: insight-users at itk.org
Subject: [Insight-users] Progress event and DiscreteGaussianImageFilter


Hi,
I'm using itkDiscreteGaussianImageFilter with an observer on the
progress event.
The progress value that I get each time the observer receives the event
has a strange behavior.  As the filter executes, the progress goes up to
about 10.7% , then drops to about 7.1%, then goes up again to about
10.7%, then drops again, etc.  The progress value keeps oscilating about
25 times during the execution.  The drop down is always the same (3.6%)
but the progress value seems to go up a little bit more after each
oscillation.  At the last oscillation, the maximum progress is 14.3%,
and then, the filter terminates.
I checked a little bit the code of the filter, and it seems that there
is something incoherent between the way the StreamingFilter works and
the way the ProgressAccumulator works.  The progress accumulator is
registered for only 4 sub-filters (3D smoothing in my case) and the
whole filtering process is divided into 28 stages (3D image dataset and
3D smoothing in my case).  This value of 28 coresponds to a stage
execution of 3.57% (1/28) per stage.  This value of 3.57% corresponds to
the size of my drop at each oscillation, besides that, 3 x 3.57 = 10.7
and  4 x 3.57 = 14.3, which are the values of my first and last maximum
progress.
Note that I just switched to ITK 2.2 and that the problem never happened
when I was using ITK 2.0.
I'm using ITK with Linux Redhat 9.0.
I attached a little program that reproduces the problem.

Thanks for considering this problem,

Didier.

-- 
Didier Rajon
Department of Neurological Surgery
University of Florida
MBI, L2100 PO Box 100265
Gainesville, FL, 32610-0265
Tel: (352) 294 0144
Fax: (352) 392 8413