[Insight-developers] FOUND IT: RE: Pervasive Pipelining & Conversion of the Image Reg istration framework

[Miller, James V (Research)]

Luis, 

I found the problem.  It is related to the integrity of the pipeline
when an exception is thrown.  If I add a ResetPipeline() call to the
example after the exception is caught, then the test work.

When a pipeline is updating, a flag is kept internally to each filter
to keep track of whether it is updating.  This keeps the pipeline
from any circular updates.  When an exception is thrown, the 
flag is not cleared.  A call to ResetPipeline() is needed to reset
the flags all the way up the pipeline.  If we do not call ResetPipeline() 
then the next call to Update() will kick out immediately since the
pipeline thinks it is already updating.

I can fix this two ways.  One, in the tests, I can put a call to
ResetPipeline() in each catch() block.  Two, I can put another catch
in ProcessObject that catches any ExceptionObject and calls
ResetPipeline() before rethrowing the exception.

Jim



-----Original Message-----
From: Miller, James V (Research) 
Sent: Friday, April 23, 2004 10:13 AM
To: 'Luis Ibanez'; Miller, James V (Research)
Cc: Insight Developers List; Lydia Ng; Julien Jomier
Subject: RE: Pervasive Pipelining & Conversion of the Image Registration
framework


In ProcessObject::UpdateOutputData() there is code 

    try
      {
      this->GenerateData();
      }
    catch( ProcessAborted & excp )
      {
      excp = excp;
      this->InvokeEvent( AbortEvent() );
      this->ResetPipeline();
      throw ProcessAborted(__FILE__,__LINE__);
      }

This code catches only the "ProcessAborted" exception, resets
the pipeline to a consistent state and rethrows the exception.

I would expect, therefore, that any other exception would NOT
be caught and propagated up the call chain.

Maybe my understanding of exception catching is incomplete.  Do we
need to add a general catch

    try
      {
      this->GenerateData();
      }
    catch( ProcessAborted & excp )
      {
      excp = excp;
      this->InvokeEvent( AbortEvent() );
      this->ResetPipeline();
      throw ProcessAborted(__FILE__,__LINE__);
      }
    catch( ExceptionObject& err )
      {
	// Should we invoke the AbortEvent()?
	this->ResetPipeline();
      // Pass exception to caller
      throw err;
      }


-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
Sent: Thursday, April 22, 2004 8:56 PM
To: Miller, James V (Research)
Cc: Insight Developers List; Lydia Ng; Julien Jomier
Subject: Pervasive Pipelining & Conversion of the Image Registration
framework



Hi Jim,

As we discussed at last tcon, the itk::ImageRegistrationMethod
is now being modified in order to take advantage of the new
DataObjectDecorator<> class.

As a first step, the following modification were made in
itk::ImageRegistrationMethod:

1) A GenerateData() method was added

2) A MakeOutput() method was added

3) A DataObjectDecorator<> type was defined for the
    transform.

4) The Decorator of the Transform is now returned
    by the GetOutput() method.


All the tests of the basic registration framework are
now calling Update() instead of StartRegistration().

So far, the only problem that is surfacing is related
to the intentional test of Exceptions.  It seems that
when exceptions are thrown from the StartRegistration()
method, they are being catched by some intermediate
code in the itk::ProcessObject.

This is showing up in the failure of the following test:

    A) itkImageRegistrationMethodTest
    B) itkImageRegistrationMethodTest_13
    C) itkImageRegistrationMethodTest_14

In all cases the failure is related to test of the
exception that has to be thrown when an array of
initial transform parameters is set with the wrong
size.

The tests work ok if StartRegistration() is called,
and they fail when Update() is called. However, the
only thing that GenerateData() does is to delegate
to StartRegistration().


Do you see any places in itk::ProcessObject that may
be responsible for such effect ?


   Thanks for any hints,


    Luis