[Insight-users] gaussian filtering in itkSymmetricForcesDemonsRegistrationFilter

[Luis Ibanez]

Hi Corinne

Here is the class hierarchy of the DemonsRegistrationFilter
http://www.itk.org/Insight/Doxygen/html/classitk_1_1DemonsRegistrationFilter.html




    FiniteDifferenceImageFilter   (iterations are done here)
            ^
            |
            |
    DenseFiniteDifferenceImageFilter
            ^
            |
            |
    PDEDeformableRegistration     (smoothing is done here)
            ^
            |
            |
    DemonsRegistrationFilter




The iterations of the PDE solver are stopped in the
Halt() method in FiniteDifferenceImageFilter. .txx

The two stopping criteria are:

    if (this->GetElapsedIterations() >= m_NumberOfIterations)
    if ( this->GetMaximumRMSError()  >  m_RMSChange )



So, yes,
you can set your stopping criteria by invoking the
SetMaximumRMSError method.  In practice, any run of
this filter, that uses all the alloted iterations,
should be considered as 'non-converging', since the limit
of number of iteration is there only for preventing the
filter from running forever. Users should check at the
end of the run if the filter stopped due to a convergence
of the changes being under the MaxRMSError value or because
it used all the iterations.


I'm not quite convinced that it is desirable to run an
extra smoothing on the deformation fields.... but if you
manage to make your case on this, and easy option is to
add a boolean flag to the PDEDeformableRegistration filter,
that will decide whether this final smoothing is applied
or not.


If you find that this has a significant impact on the
use of this filter I would suggest you to put together
a minimal example in which you illustrate why one option
is better than the other.


Hey,
That could be a paper in an Open Access
Journal if there were anyone around...    :-)



Regards,



    Luis



--------------------------
Corinne Mattmann wrote:

> Hi Luis,
> 
> Thanks for you fast reply.
> Hmm... I've never used this threshold to stop the registration. I guess
> you mean the metric which has lately been implemented in
> itkDemonsRegistrationFunction? Can I set the threshold with
> "SetMaximumRMSError"?
> Why I was thinking about this extra smoothing: I expected this algorithm
> to be "calculate deformable field and smooth it" - "calculate deformable
> field and smooth it" - ... and I thought it was strange to output a
> different deformable field than you use for the next iteration.
> Another thing I was thinking about is, when you have a poorly registered
> region and you have one step at the end with no filtering (always
> assumed that you have no threshold to stop the algorithm), it might be
> possible that this region gets completely wrong.
> For me, the logical step to use a metric would be "calculate deformable
> field, smooth it, calculate metric". However, I guess this
> implementation would rise the computation time quite strongly.
> I can't say, which implementation is better. The one with not smoothing
> the field at the end has the advantage, that small regions with big
> changes (which get always too small due to the smoothing) are registered
> better.
> 
> Regards,
> Corinne
> 
> 
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez at kitware.com] 
> Sent: Monday, March 08, 2004 6:14 PM
> To: Corinne Mattmann
> Cc: insight-users at itk.org
> Subject: Re: [Insight-users] gaussian filtering in
> itkSymmetricForcesDemonsRegistrationFilter
> 
> 
> 
> 
> Hi Corinne,
> 
> The purpose of the smoothing in the implementation of
> the Demons algorithm is to regularize the deformation
> field.
> 
> In principle, what would be expected from this filter
> is to return the deformation field that minimizes the
> sum of squared differences between the fixed image and
> the deformed moving image.  Since the algorithm is
> stopped when the changed in this difference is under
> a threshold, it is reasonable to return the latest
> deformation field that produced this minimum value.
> 
> If the filter is changed to smooth the last deformation
> field, a user will find the inconsistent situation in
> which by using this (smoothed) deformation fields for
> resampling the moving image, and recomputing the sum
> of squared differences she/he will not be able to find
> the same last metric value returned by the filter.
> 
> In addition, it is expected that if the algorithm really
> converged, no further modification of the deformation
> field should be necessary.
> 
> 
> Do you find any particular reason for which the
> deformation field should have this extra smoothing
> after convergence ?
> 
> 
> Please let us know,
> 
> 
>     Thanks
> 
> 
>       Luis
> 
> 
> 
> -------------------------
> Corinne Mattmann wrote:
> 
> 
>>Hi,
>>
>>I've just noticed, that in itkSymmetricForcesDemonsRegistrationFilter
>>the deformable field is always smoothed before performing an iteration
>>(line 70 in itkSymmetricForcesDemonsRegistrationFilter.txx). Like
> 
> this,
> 
>>the output field (the one after the last iteration) is never filtered.
>>Is there a reason not doing this?
>>
>>Thanks,
>>Corinne
>>
>>_______________________________________________
>>Insight-users mailing list
>>Insight-users at itk.org
>>http://www.itk.org/mailman/listinfo/insight-users
>>
> 
> 
> 
> 
>