[Insight-developers] behavior of imagetoimagefilters

[Damion Shelton]

Thanks for the quick replies...

> I just tried your CoreAtomImageTest. I added another Update on the
> filter. It only executed once. You'll have to check the next element down
> in the pipeline.

Ok. The really confusing thing is that absolutely nothing happens between 
the repeated calls to Update(). I took Luis's suggested and set all filters 
in the pipeline to DebugOn() - as far as the Debug is concerned, I create 
the pipeline, run it, play around in VTK (with nothing happening in the ITK 
pipeline), and then trigger an update. DebugOn() did confirm that the 
entire pipeline is re-executing, back to the earliest filter - this is 
clearly visible in the debug output.

Luis's thoughts:

> Is the first run of 20 seconds really doing all that has
> to be done ?

Yes. The application initially followed the flow:

ITK pipeline -> VTK conversion -> VTK interaction --> end

It now permits modification of the pipeline and re-execution, but 
everything that "can ever happen" has occured once the initial interaction 
step is reached.

> or is the second (slow) run the one that really do the
> whole job, while probably the first execution of 20
> seconds was skipping something ?

Not as far as I can tell, since the second update might not even occur 
(should I choose not to push the update button, for example).

> 1) Some filters don't use the Set/Get macros for
> setting their parameters and forgot to call "Modified()"
> when parameters change...

I just checked that, everything uses Set/Get macros, except for a portion 
of  GradientImageToBloxBoundaryPointImageFilter, but the part that doesn't 
was closely modeled after ShrinkImageFilter and seems to work fine.

> 2) It is your processing time independent of the
> parameters ?  Is it possible that a fine tunning in
> one parameter make more core atoms to be
> detected and so increase the total computing time ?

Good idea, but I tried making a change which (when used during the initial 
run) results in a shorter time. I.e., I pick values that result in an 
initial long time, change to values that result in an initial short time, 
and end up with a very long time upon Update().

I'll play around with the observers tommorrow. A few random comments about 
the design of my application, which I'll throw out in case they might 
affect things:

The ITK objects are stored as global pointers. For example, the boundary 
point filter is:

TBPFilter::Pointer bpFilter;

It's later initialized in a function called:

void CreateITKPipeline();

along with the other members of the pipeline. The final member of the 
pipeline has it's Update() method called in main(), after the entire 
pipeline has been initialized

Could any of this cause problems? Any potential weirdness when the FLTK 
event loop enters the picture? My intent with having global filter objects 
was to not have them go out of scope until main() returns. From the 
reference count debug output, this seems ok...

Thanks,

-Damion-