[Insight-users] 2 "Update()" - related problems

Miller, James V (Research) millerjv at crd.ge.com
Thu, 15 Jan 2004 16:33:42 -0500


Background:

The pipeline operates in a "request" manner.  A filter is asked to produce a
specific amount of data (a specific region).  The filter then asks its input
for that amount of data.  If that amount of data is not available on its
input, the preceeding filter is asked to produce it.  This continues on up
the pipeline.

The first time Update() is called on the tail of the pipeline, it defaults
to producing all the output.  The second time Update() is called on the tail
of the pipeline, it tries to issue the same request it had the first time.
At any time, you can tell a pipeline to produce all of the output by calling
UpdateLargestPossibleRegion() instead of calling Update().

Finally, suppose a filter is asked to produce region A.  The filter
determines that to produce region A it needs to request region B from its
input. Let's assume an input is available that has region C.  If C is a
superset of B, then the filter can execute directly because the data it
needs is available (most filters don't care if there is more data on input
than they need to process).  If C is not a superset of B (or at least B),
then the preceeding filter will have to re-execute to produce the region B.


For this first problem:

The pipeline caches information about previous requests.  It is possible for
a parameter change to make the previous requests "invalid".  There are two
instances where this occurs frequently. One in the case you have using a
filter that changes the resolution of an image.  The other is the case where
the user changes the input to a filter (or the filename to reader) where the
new input is a different size than the previous input. Here is what happens:

The first time you call Update() on your pipeline, the pipeline produces all
of the output.  The next time you call Update() on your pipeline, the
pipeline tries to request the same amount of data as the previous request.
If that request cannot be satisfied by the pipeline, an exception is thrown.

Whenever you change a parameter that can affect the size of a requested
region, your should call UpdateLargestPossibleRegion() instead of calling
Update().  Same for changing a file read on input.

Connecting a writer to the pipeline fixed your problem because writers try
to update the LargestPossibleRegion instead of a cached region size.

The second problem is similar to the first.  When you change the slice, the
smoother may have to execute again to produce the piece of the data that you
want.  In your pipeline

      smoother3D->SetInput(reader3D->GetOutput());
      extractSlice->SetInput(smoother3D->GetOutput());
      viewer2D->SetInput(extractSlice->GetOutput());

	viewer2D->Update();

Based on this pipeline, the smoother3D will only smooth enough of the data
to satisfy the 
extractSlice filter.  Whenever the parameters of the extractSlice are
changed, the smoother 
needs to re-execute.  

If you have enough memory, you can have the pipeline produce all the
smoothed data and have that available to the extractSlice.


      smoother3D->SetInput(reader3D->GetOutput());
 	smoother3D->UpdateLargestPossibleRegion();    // Force all the
smoother3D data to be available
      extractSlice->SetInput(smoother3D->GetOutput());
      viewer2D->SetInput(extractSlice->GetOutput());

	viewer2D->Update();

Now, you can change the parameters to extractSlice and the smoother will
never have to re-execute because there will always be "enough" data on the
input side of extractSlice to satisfy any valid request.

Again, a writer does not need to be added to the pipeline.



-----Original Message-----
From: Ivan.Bricault at imag.fr [mailto:Ivan.Bricault at imag.fr]
Sent: Thursday, January 15, 2004 4:09 PM
To: insight-users at itk.org
Subject: [Insight-users] 2 "Update()" - related problems


Hi all,

I started using ITK a few weeks ago, and it's a great toolkit ! 
Nevertheless, I had some hard time identifying and solving 2 "update()"-
related problems.
Are you aware of that kind of problems ?
Are there any possibly more elegant solutions for that ?
Thanks !

  Ivan.


--------- (1) ---------------

PROBLEM

Within my GUI, a button executes a itk::ResampleImageFilter on a 3D image
with 
a user-defined isotropic spacing value (same spacing for x,y,z).

When the user executes the filter various time with various spacing values, 
the following exception is caught during " resampler->Update(); " : 


     Requested region is (at least partially) outside the largest possible 
region.
     Location: Image::PropagateRequestedRegion()


This happens when (and only when) the new spacing value is superior to the 
spacing value used during the previous resample filter update.



SOLUTION

I connected a writer to the resampler :  " writer->SetInput(resampler-
>GetOutput()); "
In my code, instead of doing
     " resampler->Update(); "
I changed for 
     " writer->Update(); "

Now everything is fine, and no exceptions occur.


------------- (2) --------------------------------------

PROBLEM

I use the following pipeline to smooth a 3D image (with 
itk::CurvatureFlowImageFilter), extract a particular slice and then view it 
with a 2D viewer

      smoother3D->SetInput(reader3D->GetOutput());
      extractSlice->SetInput(smoother3D->GetOutput());
      viewer2D->SetInput(extractSlice->GetOutput());

Then, after executing " smoother3D->Update(); " : 

if the user interactively changes the extracted slice to be viewed and 
generates a " viewer2D->Update(); ",
it takes a long time to see the new smoothed slice, because ITK seems to
need 
to compute a new smoother3D->Update() which corresponds to some part of the
3D 
image that was not extracted before, and that has not been smoothed yet 
(despite of the smoother3D->Update() ).

SOLUTION

Again, I connected a writer to the smoother :  "
writer->SetInput(smoother3D-
>GetOutput()); "
And in my code, instead of doing
     " smoother3D->Update(); "     (*)
I changed for 
     " writer->Update(); "         (**)

The time needed for executing (**) is longer than for (*). But now the 
smoothing process is computed all at once, and the user can view the various

smoothed slices without experiencing any delay.






-------------------------------------------------
envoye via Webmail/IMAG !

_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users