[Insight-users] 3d Deformable Registration problem based on DeformableRegistration8
Albert Gubern
bertkrek at gmail.com
Thu May 21 05:48:14 EDT 2009
There were two mistakes in the last mail.
The images link don't have the final dot and the double
costFunctionconvergenceFactor is 1e3 instead of 1e-3.
Sorry.
Albert
2009/5/21 Albert Gubern <bertkrek at gmail.com>
> 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
>
--
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090521/815ba575/attachment-0001.htm>
More information about the Insight-users
mailing list