[Insight-developers] Diffeomorphic demons registration

[Luis Ibanez]

Hi Tom,

I'm starting to think that I didn't start from the most
recent revision of the code in your paper.

Can you point me to the version that I should have used ?

The missing functionalities of the
MultiResolutionPDEDeformableRegistration class, don't seem
to be used from the current version of the Diffeomorphic
Demons class...


About the unit tests, I blindly experimented with parameters
yesterday and got a couple of them to pass.

Only three of them are failing now.

I'll revise the parameters again, following your guidelines.


The number of iterations is "arbitrarily" stopped at 150,
we could increase it if you think that it will help to
reach convergence. From the experiments I ran, the values
of the Metric seemed to be stable (but non-zero) by the
time we reach 150 iterations, but it may have been that
the filter was slowly making progress.

How many iterations would you expect that are needed for
these tests.



I agree that some smoothing would help, but considering
that this was the original test for Demons, I thought that
we should be able to make it work with the Diffeomorphic
Demons as well.


    Thanks


       Luis


-----------------------
Tom Vercauteren wrote:
> Hi Luis,
> 
> A.
> First a few comments with respect to your last email.
> 
> 
> 
>>1) The SetRequestedRegion() are probably my mistake.
>>  I don't recall to consciously remove these lines.
>>
>>  I'll simply insert them according to your diff.
> 
> 
> OK thanks. Since I am not 100% comfortable with the region passing in
> ITK's pipeline, I thought you might have done it purposely.
> 
> 
> 
>>2) About the MultiResolutionPDEDeformableRegistration
>>  I actually fused your changes from
>>  MultiResolutionPDEDeformableRegistration2
>>  into the ITK MultiResolutionPDEDeformableRegistration.
>>
>>  So it should be now equivalent to yours...
>>
>>  It doesn't hurt to take a quick look to verify that
>>  I didn't snipped any other piece from your code  :-)
> 
> 
>>From what I see on viewvc, my proposed changes to
> MultiResolutionPDEDeformableRegistration have not been integrated into
> ITK. The change you committed only relates to an additional template
> parameter.
> 
> The two points I would like to see are (the first one being the most
> important as no easy workaround is available yet):
> 
> 1) The FieldInterpolatorType used by this->m_FieldExpander should be
> customizable. I don't
> say that the default interpolator type should be changed by the one I
> proposed but
> al least, there should be some way to allow the user to change it.
> 
> 2) The way one can specify the input deformation field. When I wrote
> my code, this function was not implemented in ITK. What I did was
> allow the user to specify an input filed that has the same size as the
> input image. My MultiResolutionPDEDeformableRegistration2 then takes
> care of downsampling it to the first used resolution. In the function
> that is now implemented in ITK, the user has to specify an input
> deformation field that has the same size has the downsampled input
> image. It would be great if both options were available.
> 
> 
> 
> 
>>4) About the application:
>>
>>  It was a bit heavy for a test,
>>  so I stripped it down to a minimal set.
>>
>>  It will be great to have the application in
>>  InsightApplications.
>>
>>  The main issue is that getopt() is only available
>>  in some platforms. My recommendation will be to
>>  replace it with MetaCommand, from
>>
>>         Insight/Utilities/MetaImage
>>
>>  which is an equivalent class for parsing command
>>  line arguments.
> 
> 
> OK, I will try and take a look at this. Unfortunately, my current
> schedule will not allow me to do this prior to July 15.
> 
> 
> 
> B.
> A few notes concerning the unit test.
> 
> 1) The current parameters used by the diffeomorphic demons tests seem
> far from common values.
> - Typically the user will never play with the intensity difference
> threshold, the maximum error or the maximum kernel width
> - The maximum update step lentgh will typically be taken between 0.5
> and 3 pixels (2 being a good choice)
> - The standard deviation will typically be chosen between 0.5 and 4
> pixels (something between 1 and 3 being a good default)
> 
> 2) In the ShowProgress object, the registration is stopped after
> iteration 150. Is this done on purpose?
> 
> 3) Since you are looking are binary objects, it might be worth
> introducing some smoothing on the update fields.
> 
> Regards,
> Tom
>