[Insight-developers] behavior of imagetoimagefilters

[Luis Ibanez]

Damion,

About the desing of the application:

The global SmartPointer shouldn't be the cause of the problem.  

However you can easily get rid of globals  by createing an "App"
class that takes all the current globals as ivars.   your main() will
be reduced to something      like:

     main()   {
        App  * myApp = new App;
        try {
           myApp->Show();  // show up FLTK windows
           Fl::run();
            }
        catch ( ... ) {  // some messages here }
        delete myApp;
        return 0;
        }
       
The FLTK event loop quits when you close all the windows.

So you can expect that the lines after Fl::run() will be executed
just after all FLTK windows are closed.

----

About the Pipeline:

You may also use the TimeProbesCollector class to profile the
time consumed by different parts of the code.  That could help
to see if eventually some filter is taking more than it should or
maybe it is running too fast.

You can use them like:

#include <itkTimeProbesCollector.h>

itk::TimeProbesCollector   collector;

collector.Start("ExecuteFilter1");
.....
collector.Stop("ExecuteFilter1");

// and at the end:
collector.Report();


The string parameter is used to match a Start() with the
corresponding Stop(). you can think about them as a set
of stopwatches that cumulate times for every particular
string that you provide.



It looks like what is happening is that the second run
is getting lost doing some extra processing that may
not be necessary. Given that the DebugOn() is showing
that the first Update() is calling all the filters that should
be called...

Do you have a way of visualizing the results ?

Is the first run really providing all the expected results ?

Could it be that in the first run, some of the GenerateData()
methods are being invoked but then rapidly skipping what
they should do internally ?


Luis


=========================================

Damion Shelton wrote:

> 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-
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>