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

[Luis Ibanez]

Jim,

Great !

Thanks a lot for solving this problem.

I'll then move ahead then with converting the ResampleImageFilter
in order to accept a decorated Transform as input.


   Luis


---------------------------------
Miller, James V (Research) wrote:

> I checked in the fixes to ProcessObject and ImageRegistrationMethod.
> 
> -----Original Message-----
> From: Miller, James V (Research) 
> Sent: Friday, April 23, 2004 3:35 PM
> To: Miller, James V (Research); 'Luis Ibanez'
> Cc: 'Insight Developers List'; 'Lydia Ng'; 'Julien Jomier'
> Subject: RE: [Insight-developers] FOUND IT: RE: Pervasive Pipelining &
> Conversion of the Image Reg istration framework
> 
> 
> I found the problem with ImageRegistrationMethodTest_13 and _14.
> 
> These tests modify things like the metric then expect the registration
> to rerun on a call to Update on the registration method.
> 
> But if you modify the metric (by setting a value on the metric), the
> registration method does not know the value was changed.  I am adding a 
> GetMTime() method to the registration method that returns the latest
> of the object and its ivars. This routine will need to be rewritten
> when any of these ivars are put in the input and output lists (since the 
> MTimes will be managed automatically).
> 
> Jim
> 
> -----Original Message-----
> From: Miller, James V (Research) [mailto:millerjv at crd.ge.com]
> Sent: Friday, April 23, 2004 2:55 PM
> To: 'Luis Ibanez'
> Cc: 'Insight Developers List'; 'Lydia Ng'; 'Julien Jomier'
> Subject: [Insight-developers] FOUND IT: RE: Pervasive Pipelining &
> Conversion of the Image Reg istration framework
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>