[Insight-users] Need help with itkPointSetToPointSetRegistration

[Luis Ibanez]

Hi Dirk, Elena,



           Thanks for reporting your
           observations with this test.



     It seems that both of your modification
     may have been inconsistent.




In order to test the code the modifications
should include the following changes:


64c57
<     point[0]=artificialOffset;
---
 >     point[0]=0;
70c63
<     point[0]=artificialOffset+i;
---
 >     point[0]=i;
180c173
<     parameters[k]= 0.0;
---
 >     parameters[k]= 10.0;
221c214
< //  std::cout << "psToImageFilter: " << psToImageFilter << std::endl;
---
 >   std::cout << "psToImageFilter: " << psToImageFilter << std::endl;
236c229
<     parameters[k]= 0.0;
---
 >     parameters[k]= 10.0;





Note that the way this program was testing the registration method was
by purposely providing an incorrect initialization of the transform.

This initial shifted transform was set to (10,10) in translations.

Now that you are shifting the point set coordinates themselves, the
initial transform must set to a better default. For example (0,0).


With this change, the program converges to a translation of

             [10.1029, 0.444 ]


Which admittedly, could have better precision...


That's were the fun of fine tunning the algorithm parameters
starts, and where, of course, we remind everybody that the
absence of including such parameters when publishing papers
makes a mockery of scientific publishing, because, as we all
know, finding the right parameters makes the difference between
having an algorithm that works or an algorithm that fails.



Elena,
I must differ with your statement that the Levenberg-Marquardt
optimizer is not well suited for this problem. The point set
to point set registration problem is very well suited for the
capability of the Levengerg-Marquardt optimizer for dealing
with multivalued cost functions.



By changing the parameters of the optimizer, we manage to
recover the values of artificial shift in X and Y with
a precision of about three digits. Here are the results
of running some example argument values:


./PointSetRegistration 10 10
Solution = [10, 10]

./PointSetRegistration 15 19
Solution = [15.0001, 18.9998]

./PointSetRegistration 35 47
Solution = [34.9994, 46.9993]

./PointSetRegistration 39 55
Solution = [38.9985, 54.9992]

./PointSetRegistration 79 41
Solution = [79.001, 40.9992]

./PointSetRegistration 179 241
Solution = [178.997, 241.5]

./PointSetRegistration 279 341
Solution = [278.995, 340.998]





Here are the new parameters

<   unsigned long   numberOfIterations =   500;
<   double          gradientTolerance  =  1e-5; // convergence criterion
<   double          valueTolerance =  1e-5; // convergence criterion

--- [For reference: here are the old parameters]
 >   unsigned long   numberOfIterations =   100;
 >   double          gradientTolerance  =  1e-1; // convergence criterion
 >   double          valueTolerance =  1e-1; // convergence criterion




Please find attached the modified program, where artificial
shifts are introduced from the command line arguments.


Please give it a try to the attached code and let us
know if you find any problems or have any further questions.



    Regards,



        Luis



PS:

This field will only get out of its Dark Ages,
when we all get the discipline of providing

      * Source code
      * Data
      * Parameters

When we report *ANY* observation.


Until then, we are simply promoting superstitions and
divulging unfounded speculations that can not be verified.

It is about time to get rid of such medieval practices.





------------------------------------------------------------
Elena Pavlovskaia wrote:
> Hello Dirk,
> 
> I am not an expert in ITK so I might be wrong in what I say.
> 
> 1. I tried your example, and I also got a wrong result. It was different
> from your result though. My result was: ShiftInX = -2.29, ShiftInY
> = -100.08. It's strange that your result is different. Did you see that
> there are two for-loops for setting the moving points? Did you add offset in
> both loops?
> 
> 2. Per my understanding the LevenbergMarquardtOptimizer used in that example
> is not a good choice for this task: it seems to be subject to local minima
> and to be very slow. We are using the VTK vtkLandmarkTransform for the Point
> Set to Point Set registration. It works very precisely and very fast.
> 
> Elena
> 
> ---------------------------
> Dirk Hollstein wrote:
> 
> Hello list,
> 
> I'd like to ask for help with the
> itkPointSetToPointSetRegistrationTest example in ITK
> (itkAlgorithmsTest2).
> 
> To understand how the example works, we changed the offset of the
> moving point set by setting the fixed x, resp. y component from 0 to
> 100, such introducing an offset of 100 between the fixed and moving
> point set:
> 
> point[0]=100;
> point[1]=i;
> 
> instead of:
> point[0]=0;
> point[1]=i;   etc.
> 
> 
> When running the registration with all other parameters unchanged,
> the calculated distance is surprisingly about -75, not -100.
> 
> Next we changed the number of points, number of iterations,
> gradientTolerance, valueTolerance, epsilonFunction, but none helped
> to improve the result.
> What can we do to register correctly? Any suggestions are welcome.
> 
> Thanks a lot in advance.
> 
> Regards,
> Dirk
> 
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itkPointSetToPointSetRegistrationTest.cxx
Type: text/x-c++src
Size: 8285 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/insight-users/attachments/20070407/96a089e3/itkPointSetToPointSetRegistrationTest.cxx