[Insight-developers] behavior of imagetoimagefilters

[Luis Ibanez]

Damion,

Your description of the pipeline mechanism sound fine.

Filters should be executed a first time and they should
only be executed again if their input change or any
of their parameters change.

So, as you said, the second Update() should always
be faster than the first one because not all the pipeline
will be executed.

A question:
Is the first run of 20 seconds really doing all that has
to be done ? so we can say that the second one that
takes more than a minute is probaly doing something
extra ?
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 ?

---

Here are a couple of possibilities I can think off:

1) Some filters don't use the Set/Get macros for
setting their parameters and forgot to call "Modified()"
when parameters change...  However if that was the
cause of your problem you should be finding that
some of the filters don't run when they should and so
the total execution time will be shorter.

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 ?
(this is just a guess).


Something that can be useful to try to identify responsibles
is to enable "DebugOn()" in all the implicated filters.  That
will make the filter print messages each time a Set/Get
method is called  That will generate a lot of text to track
but will also show you the execution order.

You can also take advantage of the Events that are produced
at critial times in the filter activity: (though not all filters take
care of sending them....) but.. it is worth to try: you can define
Observers to the : Start, Progress, End events of the filters
and so get a feeling of which ones are really running.


Luis


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

Damion Shelton wrote:

> Hi,
>
> I've run into an interesting/frustrating problem, and I'm hoping that 
> I'm just misunderstanding how the pipeline is supposed to be used.
>
> For background, I've written a program that does the following:
>
> 1) Load a meta image file (from Luis's brainweb data)
>
> 2) Find core atoms in this data - the code is very similar to the core 
> atom test
>
> 3) Convert the core atoms to VTK unstructured grid points
>
> 4) Display the points, along with the image, in VTK
>
> I'm using FLTK to provide a basic interface to interact with pipeline. 
> There are several callbacks linked to Fl_Value_Input boxes to change 
> parameters of the itkBloxBoundaryPointToCoreAtomImageFilter object in 
> the pipeline, and an update button that calls the Update() method of 
> the above filter. As long as I don't hit the update button, everything 
> works as expected.
>
> As I understand the pipeline, calls to the various Set() commands in 
> the filter cause a modified flag to be set in the filter, ensuring 
> that the output is updated when the Update() call propogates through 
> the pipeline. Additionally, pipeline members that have not be modified 
> are not re-executed.
>
> This doesn't seem to be happening, though. First off, the initial 
> execution of the pipeline, including all of the preliminary filtering 
> + core atom detection takes approximately 20 seconds. After changing 
> the filter parameters slightly (not enough to affect actual execution 
> time), updating the filter requires more than a minute - again, if I'm 
> understanding things right, the filtering done at the beginning should 
> not be happening again, so the execution time, if anything, should be 
> less.
>
> In addition, without modifying any filter parameters, calling Update() 
> on the filter seems to be causing the filter to execute (at least, 
> something is happening). I'm not sure why this is happening, since 
> intuitively "updating" something that hasn't changed shouldn't require 
> any re-computation.
>
> Any ideas what's going on? There may be a problem in 
> itkBloxBoundaryPointToCoreAtomImageFilter, but I'm at a loss. It works 
> fine when executed the first time.... perhaps I'm missing an important 
> step though? Has anyone seen behavior like this with other filters?
>
> Thanks,
> -Damion-
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>