[Insight-users] itkCenteredRigid2DTransform registration
optimization problems
Felix Bollenbeck
bollen at ipk-gatersleben.de
Wed Jan 30 04:39:07 EST 2008
Hello Rupert,
Thanks for your reply and the paper. I am just running a modified scale
scheme, as you suggested. The ITK docs suggest just a static scaling,
accounting for the different radiant/pixels displacement
dimensions-which I used up till now.
Yes I agree - when reading the docs and examples, the reader might get
the opinion, that optimizers are some kind of 'magic box' finding the
best transform, once parameters are set properly. But as you said,
especially gradient descent optimizers just descents into the NEXT
minimum.
My registration results are either perfect or misaligned, the correct
solution definitely has the best metric value.
Yes I also thought that a grid-search on the lowest scale might be an
option, rising the question, how dense this grid should be.
Trying flippings on pyramid top might do, on the other hand, I would
like to keep cost down as much as possible, because I have to register
several tens-thousands of images in total (serial sectioning stacks).
In my MATLAB prototype I use an initial principal-axis-transform for
bulk initialization, but I found the itkImageMomentsCalculator not so
well documented. Have you used it?
Best regards,
Felix.
--
Felix Bollenbeck Email: bollen at ipk-gatersleben.de
Pattern Recognition Group Phone: +49 (0)39482 5344
Leibniz Institute of Plant Fax : +49 (0)39482 5137
Genetics and Crop Plant Research
Correnstr.3 http://www.ipk-gatersleben.de
06466 Gatersleben,Germany
Rupert Brooks wrote:
> Sorry about that last email - i accidentally clicked send long before
> i should have
>
> Felix-
>
> I think the problem you are having could be caused by two possibilities.
>
> 1. Your image is starting out closer to the flipped solution, meaning
> the optimizer will slide downhill to the flipped solution because that
> is the bottom of the "valley" in which it starts. If this is the
> case, the optimizer is doing what it should, in some sense, and it
> will be hard to tune your way out of this problem with any optimizer.
> I suspect that this is what is happening. However, it may not be that
> difficult to solve.
>
> If the correct solution has better cost function values than the wrong
> one, then, after the first level of your pyramid, flip the image,
> reoptimize and take the best of the two. (If you have an N-fold
> symmetry, you may have to explore each of the N-possibilities.) In
> practice, i have done something like this using the
> ExhaustiveOptimizer as a first pass. However, there was a bug that
> got in the way - i believe fixed now - check mantis before you try
> using that class, if you do.
>
> If the correct solution actually looks worse than the wrong one, in
> terms of cost function values, then you have a very tricky problem.
> You'll need to find some sort of bound or regularizer to limit the
> search space.
>
> 2. The optimizer parameters are poorly tuned or the cost function is
> very noisy - I don't think this is the case because if it was, the
> problem would probably not be so specific (going to the flipped
> position), but would rather show as generally lousy performance
> (aborts, trapped in various minima, poor accuracy, etc). However, if
> you think its the scale factors, I'll refer you to MICCAI short paper
> of mine about how to set that. Alternatively, you could try using the
> Powell optimizer - i've played with all of the ITK optimizers and i
> find that its remarkably robust. Its slow though, so you might want
> to use it only on the top level of your scale pyramid.
>
> Scaling Angles and distances....
> http://www.ia.unc.edu/MICCAI2005/ShortPapers/pdfs/paper947.pdf
>
> Cheers,
> Rupert B
>
>>
>>
>>> Message: 6
>>> Date: Tue, 29 Jan 2008 15:38:39 +0100
>>> From: Felix Bollenbeck <bollen at ipk-gatersleben.de>
>>> Subject: Re: [Insight-users] itkCenteredRigid2DTransform registration
>>> optimization problems
>>> To: gabri <tartuz at gmail.com>, insight-users at itk.org
>>> Message-ID: <479F3A6F.2040404 at ipk-gatersleben.de>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>> Hi Gabriele,
>>>
>>> ok, that is some kind of random search, right? - I have to read the
>>> paper for understanding.
>>>
>>> Was it difficult to tune the parameters? I am not using mutual
>>> information metric, but I will try it out.
>>>
>>> I guess I will have to anneal 'epsilon' when going to finer scales. can
>>> you comment on your choice of parameters?
>>>
>>> Thanks for your time!
>>>
>>> FElix.
>>>
>>>
>>>
>>>
>>> gabri wrote:
>>>
>>>> Hi Felix,
>>>> I've had a lot of problems with the regularstepgrdient descent , finally
>>>> I switch all my code to use the OnePlusOneEvolutionaryOptimizer that is
>>>> relly well suited for the MattesMutulaInformationMetric .
>>>> Using that classes , after finding the correct parameters tuning for the
>>>> optimizer,all problems due to miallignement disappers in my case (MRI
>>>> AffineRegistration) .
>>>>
>>>> Best Reguards
>>>>
>>>> Gabriele
>>>>
>>>> Felix Bollenbeck ha scritto:
>>>>
>>>>
>>>>> Hi ITKusers
>>>>>
>>>>> Im using the itkCenteredRigid2DTransform to register a stack of
>>>>> light-microscopy slice images containing sectionend objects in masked
>>>>> background within the image-pyramid framework of ITK.
>>>>>
>>>>> I have a question regarding the transformtype for registration of
>>>>> image pairs:
>>>>>
>>>>> objects in the images I use have a kind of symmetry axes, they are
>>>>> 'similar' on both sides but not the 'same'. The problem is, that
>>>>> sometimes the optimizer gets stuck in a local optimum representing the
>>>>> alignment of two images where the moving images is flipped along this
>>>>> axis-can I make myself clear?
>>>>>
>>>>> The problem is- that on broader scales, this 'similarity' turns out to
>>>>> be more less 'same', which causes the parameters to remain in this
>>>>> 'valley' in the subsequent fine optimization on smaller scales.
>>>>>
>>>>> starting with a finer resolution ends up in bad convergence, or bad
>>>>> overall results.
>>>>>
>>>>> I tried to tune stepwidths, optimizer scales etc. but i couldnt find
>>>>> any overall tendency, due to my little detailed knowledge on the
>>>>> optmizer (regularstepdescent).
>>>>>
>>>>> Can anybody suggest a method how to optimize the rotation angle more
>>>>> carefully?
>>>>>
>>>>> Regards&TIA,
>>>>>
>>>>> Felix.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> Felix Bollenbeck Email: bollen at ipk-gatersleben.de
>>> Pattern Recognition Group Phone: +49 (0)39482 5344
>>> Leibniz Institute of Plant Fax : +49 (0)39482 5137
>>> Genetics and Crop Plant Research
>>> Correnstr.3 http://www.ipk-gatersleben.de
>>> 06466 Gatersleben,Germany
>>>
>>>
>
>
>
More information about the Insight-users
mailing list