[Insight-users] Need help with itkPointSetToPointSetRegistration
Elena Pavlovskaia
elena.pavlovskaia at otismed.com
Mon Apr 9 16:46:17 EDT 2007
Hi Luis,
Thank you for pointing out my mistakes.
I am sorry for not following
"... the discipline of providing
* Source code
* Data
* Parameters
When we report *ANY* observation."
I am using this e-mail opportunity to thank you for all your clear and
detailed answers in the Insight-Users list. I read MANY of them and find
them very helpful and expiring.
Thank you very much!
Elena
-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
Sent: Saturday, April 07, 2007 5:01 PM
To: Elena Pavlovskaia
Cc: Insight-Users at Itk. Org; Dirk Hollstein
Subject: Re: [Insight-users] Need help with
itkPointSetToPointSetRegistration
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
>
More information about the Insight-users
mailing list