<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Rupert,</div><div> I am still working my way through your thesis, and I have also downloaded the trust region optimizer you provided for the Insight Journal. I am still having trouble getting the results I desire using your optimizer for registering multimodal (T1, T2, DWI) brain data using a Rigid 3D Versor transform and the mutual information metric (this is done as an initialization to then feed deformable registrations). Based on what I've read and experimented with so far, I believe this trouble can be attributed to some or all of the following issues:</div><div><br></div><div>1. I don't think my scaling is right yet, do you have an implementation available of your scaling calculation?</div><div><br></div><div>2. I think the optimizer is not using enough samples. According to a comment I found in one of the ITK examples, "Regulating the number of samples in the Metric is equivalent to performing multi-resolution registration because it is indeed a sub-sampling of the image." However, based on my own experiments and also based on your evaluation, just arbitrarily setting a fixed percentage of pixels to use does not perform well especially in the mutual information case. I feel like I should be doing an actual multi-resolution registration or at least using all of the pixels in the image for a single-level registration.</div><div><br></div><div>3. I am not sure that I can guarantee (even if I fix 1-2 above) that I will be starting within the capture radius of the optimizer. Do you have any thoughts / recommendations / suggestions on how to better initialize the transform? Or do you have an analysis of what the ITK optimizers' capture radii are like? I still seem to have significant translation and rotation error if I use the CenteredVersorTransformInitializer with and without moments on.</div><div><br></div><div>4. I modified VersorRigid3DTransformOptimizer to derive from your trust region optimizer, but found that the API for StepAlongGradient no longer provides the factor as an argument. The Versor optimizer was scaling the rotation and the transformed gradient by that factor, is this no longer necessary?</div><div><br></div><div>5. Can you provide access to your modified Hessian approximation for mutual information?</div><div><br></div><div>Thanks!</div><div>Kris Zygmunt</div><div><a href="mailto:krismz@sci.utah.edu">krismz@sci.utah.edu</a></div><div><br></div><br><div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><br><br>Hi Rupert,<br><br>thank you for your very helpful explanations and the link to your thesis!!<span class="Apple-converted-space"> </span><br>Your thesis incidentally answered some other questions I had.<br><br>regards<br>Levin<br>________________________________________<br>Von: Rupert Brooks [<a href="mailto:rupert.brooks@gmail.com">rupert.brooks@gmail.com</a>]<br>Gesendet: Dienstag, 16. August 2011 04:01<br>An: Wolf, Levin<br>Cc:<span class="Apple-converted-space"> </span><a href="mailto:insight-users@itk.org">insight-users@itk.org</a><br>Betreff: Re: [Insight-users] Understanding OptimizerScales in its entirety<br><br>Hi Levin,<br><br>Perhaps no one responded because understanding the optimizer scales in<br>their _entirety_ is a very tall order. :-) I'll take a shot at<br>answering the immediate question anyway.<br><br>The optimizer scales are, unfortunately, not consistently applied<br>across all the ITK optimizers. However, VersorRigid3DOptimizer is a<br>subclass of RegularStepGradientDescentOptimizer and they both work the<br>same way.<br><br>In these optimizers, the gradient is divided by the scales. Then the<br>step is this direction normalized to the step length.<br><br>This sounds simple but the effect is a bit counterintuitive. This is<br>like scaling the transform parameters by the square roots of the<br>optimizer scale factors, and then limiting the step to a circle in the<br>original parameter space. Which would be an ellipse in the new one.<br>Why square root? because you change the derivative by changing the<br>scales - and then consider it a direction in the original parameter<br>space.<br><br>I apologize in advance for self-promotion, but i just put an optimizer<br>on the Insight-Journal that may interest you, if you are digging into<br>this subject. <a href="http://www.insight-journal.org/browse/publication/834">http://www.insight-journal.org/browse/publication/834</a><br>Different people have different theories about what the scales<br>accomplish - if you are up to some rather dry reading, i'll refer you<br>to Section 4.5 of my thesis<br><a href="http://www.rupertbrooks.ca/downloads/Brooks_PhDThesis.pdf">http://www.rupertbrooks.ca/downloads/Brooks_PhDThesis.pdf</a><br><br>And yes, different people have different heuristics for how to set<br>these scales. In the thesis I argued that they should be chosen to<br>precondition the Hessian matrix of the cost function. Others will<br>tell you they should roughly equalize the average pixel motion in the<br>image due to a unit shift of the parameters. It turns out that these<br>are roughly the same thing. Its important also to consider both how<br>the scales affect the optimizer path through parameter space, and how<br>they affect the stopping criteria.<br><br>Hope that helps a little,<br>Rupert<br><br><br>--------------------------------------------------------------<br>Rupert Brooks<br><a href="mailto:rupert.brooks@gmail.com">rupert.brooks@gmail.com</a><br><br></span></blockquote></div><br></body></html>