[Insight-users] 3d Deformable Registration problem based on DeformableRegistration8

Albert Gubern bertkrek at gmail.com
Thu May 21 05:00:20 EDT 2009


Hi Luis,

Thanks for your answer.

I tried it  (3D and modified 2d version) but it doesn't work. The link shows
fixed, moving images and differences before and after registration:
http://img207.imageshack.us/img207/2383/deformablereg15.png.
However, my goal is finding only deformable transform, because previously I
modified the image only applying non-rigid transformation (I know that my
test images don't have rigid and affine transformation).

I don't know where is the problem. I've done all kind of tests (2D, 3D,
changing the metric, smoomthing images, changing number of colous...). I
explain to you in detail:

The basic code uses LBFGSBOptimizer, MattesMutualInformation and only one
BSplineDeformableTransfrom in 3 dimensions (based on
DeformableRegistration8.cxx). This works correctly with 3D phantom images as
you can see in the next link:
http://img140.imageshack.us/img140/1831/phantomdeformableregist.png. Also I
modified the code to use with 2D images, and the result is the same taking
one slice of the phantom.

The parameters of the LBFGSBoptimizer are setting like this:

  double costFunctionconvergenceFactor = 1e-3;
  double projectedGradientTolerance = 1e-12;
  int maxNumberOfIterations = 500;
  int maxNumberOfEvaluations = 500 ;
  int maxNumberOfCorrections = 20;

The problem appears when I use MRI prostate images of real patient. The
registration should recovery the same deformation that it has recovered in
phantom images, but it doesn't work. The prostate images have these
features:

Spacing =  [0.46875, 0.46875, 3]
Size = [128, 128, 21]
Origin = [0, 0, 0]
Resolution = 8 bits

The following part of the mail are the tests I've done in order to find the
problem. I noticed that working with 2D slices of the volume I has the same
problem. For this reason the tests are done in 2D because 3D registration
spends more time. In all tests I've tried differents values of bins  (16,32
and 64) and nodes of grid (from 4 to 30), and the number of samples are 100%
of the image. You can see  fixed and moving image in this link:
http://img339.imageshack.us/img339/6524/fixedandmoving.png.

2D TESTS:

- My original code cited before: it doesn't work. Most of test do few
iterations for little grid (4 - 15). Increasing the grid (20) I achieve more
iterations, but no good results. The next link is the checkerboard after the
registration with 20 nodes:
http://img34.imageshack.us/img34/783/2doriginaltest.png.

- Smoothing, binarizing and dicreasing  the colors of fixed and moving
image.  Each of this pre-process had been applied and tested separately not
achieving good results (the same output as in the last test).
http://img36.imageshack.us/img36/2329/preprocessedimages.png

- Taking only a region of the image in order to focus the registration. In
this case I've extracted the first quadrant that corresponds to the part
where the deformation was applied obtaining a 64x64 image.

- Changing MattesMutualInformationMetric for MeanSquaresMetric: In this case
I've got better results and I've seen a transformation applied to the moving
image. The number of nodes of the grid in the best test is 5.
http://img20.imageshack.us/img20/3776/rmstest2dresult.png


Any idea where is the problem? The metric? The optimizer? I've also tried
RegularGradientOptimizer with MI and the results are the same.

Thanks in advance.

Albert




2009/5/21 Luis Ibanez <luis.ibanez at kitware.com>

>
> Hi Albert,
>
> Please try try using:
>
>
>       DeformableRegistration15.cxx
>
>
> This example performs a sequence of
>
>
>   * Rigid
>   * Affine
>   * and two resolutions of
>     deformable registration
>
>
> Please let us know what you find,
>
>
>    Thanks
>
>
>       Luis
>
> ---------------------
> Albert Gubern wrote:
>
>> Hi again,
>>
>> I've changed my code using RegularStepGradientDescentOptimizer instead of
>> LBFGSBOptimizer.
>>
>> Using brain phantom volume, I had good visual results (the moving image is
>> transformed looking like fixed image) with LBFGSBOptimizer, and the final
>> value of the metric was  -0.836697.
>>
>> Starting Registration
>> 0   -0.580566   0 0
>> 0   -0.580643   0 0
>> 0   -0.583835   0 0
>> 0   -0.583835   0.000114794 0
>> 1   -0.598343   0.000114794 0
>> 1   -0.598343   7.34998e-05 0
>> 2   -0.617556   7.34998e-05 0
>> 2   -0.617556   0.000133695 0
>> (...)
>> 83   -0.836697   0.000103487 0
>> 83   -0.836697   0.000103487 0
>> 83   -0.836686   0.000103487 0
>> 83   -0.836697   0.000103487 0
>> 83   -0.836697   0.000103487 0
>> 83   -0.836686   0.000103487 0
>> 83   -0.836697   0.000103487 0
>> 83   -0.836697   0.000103487 0
>>
>> On the other hand, using RegularStepGradientDescentOptimizer the final
>> value of the metric with 800 iterations is -0.638617 and the resampled image
>> is not good and only is deformed in their first and last slices. With MRI
>> prostate volume I had the same problem: the transformation only deforms the
>> first and the last slice of the volume.
>>
>>  Starting Registration
>> 0   -0.580566 1   -0.57976 2   -0.579975 3   -0.579813 4   -0.580218 5
>> -0.580442 (...)
>> 793   -0.637725 794   -0.637952 795   -0.637915 796   -0.637942 797
>> -0.638316 798   -0.637498 799   -0.638617
>>
>> I've set the stepLength of the optimizer but I haven't achieved better
>> metric values progress in each step of the registration. Also, I don't
>> understand why the output image only is transformed in the first and the
>> last slice.
>>
>> So, having in consideration that with  LBFGSBOptimizer I have good results
>> registering the brain phantom volume, I would like to know how can I tune
>> this optimizer in order to work with MRI prostate images.
>>
>> If we need more information about my code, don't doubt to ask me.
>>
>> Thanks.
>>
>> Albert
>>
>> 2009/5/12 Luis Ibanez <luis.ibanez at kitware.com <mailto:
>> luis.ibanez at kitware.com>>
>>
>>    Hi Albert,
>>
>>    It turned out in practice that the LBFGSBOptimizer is not as superior
>>    as it may have been assumed.
>>
>>    Lately we have simply used the RegularStepGradientDescentOptimizer
>>    with reasonable results.
>>
>>    See for example:
>>
>>        Insight/Examples/Registration/DeformableRegistration15.cxx
>>
>>    In general,
>>    any claims saying than some component is
>>
>>                                 "The Best"
>>
>>    should be taken with a lot of suspicion.
>>
>>
>>    Such claims are good only for publishing papers in traditional
>>    Journals and Conferences that do not exercise reproducibility.
>>    You can not rely on such sources when you are working on
>>    serious applications.
>>
>>
>>    Don't hesitate to experiment with other components of the
>>    registration framework.
>>
>>    In many cases, the challenge is not so much about what components
>>    to use, but about how to fine-tune their parameters for the problem
>>    at hand.
>>
>>
>>    Please let us know what you find,
>>
>>
>>        Thanks
>>
>>
>>             Luis
>>
>>
>>    -------------------------
>>    On Tue, May 12, 2009 at 11:21 AM, Albert Gubern <bertkrek at gmail.com
>>    <mailto:bertkrek at gmail.com>> wrote:
>>     > Hi,
>>     >
>>     > I've modified the example DeformableRegistration8.cxx in order to
>>    do a 3D
>>     > DeformableRegistration. This example uses
>>    MattesMutualInformationMetric,
>>     > BSplineDeformableTransform and LBFGSBOptimizer.
>>     >
>>     > I tested the code with a brain phantom generated with Matlab. The
>>    original
>>     > volume is deformed using Matlab b-spline deformation based on
>>    this routine
>>     > http://www.mathworks.com/matlabcentral/fileexchange/20057, and I
>>    want to use
>>     > the deformable registration of ITK to recover the deformation.
>>    The next link
>>     > shows two checkerboard of one slice, before and after the succesful
>>     > registration:
>>     >
>>    http://img140.imageshack.us/img140/1831/phantomdeformableregist.png.
>> The
>>     > original volume is set as the fixed image and the deformed
>>    phantom as the
>>     > moving.
>>     > - Mostra el text citat -
>>     >
>>     > The output of the execution is:
>>     >
>>     > Starting Registration
>>     > 0   -0.579387   0 0
>>     > 0   -0.581355   0 0
>>     > 0   -0.584345   0 0
>>     > 0   -0.584345   6.33911e-05 0
>>     > 1   -0.603649   6.33911e-05 0
>>     > 1   -0.603649   6.41689e-05 0
>>     > 2   -0.624884   6.41689e-05 0
>>     > 2   -0.624884   7.76054e-05 0
>>     > 3   -0.638071   7.76054e-05 0
>>     > 3   -0.638071   6.32524e-05 0
>>     > 4   -0.655438   6.32524e-05 0
>>     > 4   -0.655438   7.51525e-05 0
>>     > 5   -0.677776   7.51525e-05 0
>>     > 5   -0.677776   6.37494e-05 0
>>     > 6   -0.696669   6.37494e-05 0
>>     > 6   -0.696669   5.09743e-05 0
>>     > 7   -0.713613   5.09743e-05 0
>>     > 7   -0.713613   5.48518e-05 0
>>     > ... (60 iterations more)
>>     > 67   -0.854863   4.01611e-05 0
>>     > 67   -0.854863   4.01611e-05 0
>>     > 67   -0.854863   4.01611e-05 0
>>     > 67   -0.854863   4.01611e-05 0
>>     >          Probe Tag    Starts    Stops             Time (s)
>>     >        Registration           1            1           3289.35
>>     >
>>     > Next step was to test the same code with prostate MRI images but the
>>     > registration doesn't work. The original volume is a central
>>    region of MRI to
>>     > focus the registration on the prostate
>>     > (http://img145.imageshack.us/img145/200/mrireal.png), and the same
>>     > deformation, that was applied to the phantom test, is used to
>>    deform the
>>     > original prostate. The goal of the registration is the same:
>>    recovering the
>>     > deformation. The next link is a checkerboard of one slice of the
>>    volume to
>>     > show that fixed and moving images look different enough
>>     > (http://img26.imageshack.us/img26/8905/im011.png).
>>     >
>>     > In this test the program the registration stops too early doing
>>    only few
>>     > iterations and the InfinityNormOfProjectedGradient is always zero:
>>     >
>>     > Starting Registration
>>     > 0   -0.742878   0 0
>>     > 0   -0.722791   0 0
>>     > 0   -0.721167   0 0
>>     > 0   -0.721134   0 0
>>     > 0   -0.733701   0 0
>>     > 0   -0.733701   0 0
>>     > 0   -0.742878   0 0
>>     > 0   -0.742878   0.000122748 0
>>     >          Probe Tag    Starts    Stops             Time (s)
>>     >        Registration           1            1           97.3459
>>     >
>>     > I have tested the registration using different values of bins
>>     > (32,64,100,etc), % samples (100, 50, ...), using the original
>>     > (0.46875,0.46875,0.46875) and the unitary spacing, different
>>    number of grids
>>     > (from 5 to 50) and the parameters of the LBFGSBOptimizer are the
>>    following:
>>     >
>>     >  double costFunctionconvergenceFactor = 1.e7;
>>     >  double projectedGradientTolerance = 1e-6;
>>     >  int maxNumberOfIterations = 500;
>>     >  int maxNumberOfEvaluations = 500 ;
>>     >  int maxNumberOfCorrections = 5;
>>     >
>>     > Among other tests, I've also changed the metric to
>>    MeanSquareMetric to know
>>     > if mattes mutual information metric is the problem or,
>>    separately, the fixed
>>     > and moving image have been binarized to reduce the information of
>>    each
>>     > image. The output has been the same.
>>     >
>>     > All the tests seem to show that the problem is the optimizer, but
>>    I don't
>>     > know how I can solve it because in some posts in the mailing list
>>    I've read
>>     > that it is the best optimizer for deformable registration. Should
>>    I change
>>     > it for another one (Regular or LBFGS)? Any other idea?
>>     >
>>     > Thanks in advance.
>>     >
>>     > Albert
>>     > _____________________________________
>>     > Powered by www.kitware.com <http://www.kitware.com>
>>     >
>>     > Visit other Kitware open-source projects at
>>     > http://www.kitware.com/opensource/opensource.html
>>     >
>>     > Please keep messages on-topic and check the ITK FAQ at:
>>     > http://www.itk.org/Wiki/ITK_FAQ
>>     >
>>     > Follow this link to subscribe/unsubscribe:
>>     > http://www.itk.org/mailman/listinfo/insight-users
>>     >
>>     >
>>
>>
>>
>>
>> --
>> Albert
>>
>


-- 
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090521/c819aa1f/attachment-0001.htm>


More information about the Insight-users mailing list