BTW, my images were 512x512, I guess for lower resolutions there <div><br></div><div>would be less shifting in the origin of the mask.</div><div><br></div><div>Dawood</div><div><br></div><div><br><br><div class="gmail_quote">
On Tue, Jul 12, 2011 at 9:40 PM, Dawood AlMasslawi <span dir="ltr"><<a href="mailto:masslawi@gmail.com">masslawi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Yann,<div><br></div><div>Since you are using a mask for metric calculation I don't think the </div><div><br></div><div>cause of your problem is the optimizer, I assume you are using the</div><div><br></div><div>ImageMaskSpatialObject after segmenting part of your image (?!!).</div>
<div><br></div><div>How do you initiate your mask? This can be tricky sometimes!</div><div><br></div><div>I had a similar problem in the past, the origin of the image mask </div><div><br></div><div>had a 256 pixles shift towards the center of the image, but this was</div>
<div><br></div><div>only detectable when used in a Free Form Deformation due to obvious</div><div><br></div><div>deformations induced only in the lower right corner of the image! </div><div><br></div><div>When I used the SpatialObjectToImageFilter to see whether if my </div>
<div><br></div><div>mask was valid everything seemed fine but the results still were wrong.</div><div><br></div><div>If this is your problem it can be solved by shifting the mask towards</div><div><br></div><div>the origin of the image, a sample code for this would look like the following,</div>
<div><br></div><div><div> SOTransformType::OffsetType originOffset;</div><div><br></div><div> originOffset[0] = -255;</div><div><br></div><div> originOffset[1] = -255;</div><div><br></div><div> maskSO->GetIndexToObjectTransform()->SetOffset(originOffset);</div>
<div><br></div><div><br></div></div><div>As for the LBFGSB optimizer you can read the following papers,</div><div><br></div><div><span style="font-family:Geneva, Arial, Helvetica, sans-serif;font-size:14px"><p style="font-family:Geneva, Arial, Helvetica, sans-serif">
[1] R. H. Byrd, P. Lu and J. Nocedal. <a href="http://www.itk.org/Doxygen314/html/classA.html" style="color:rgb(26, 65, 168);text-decoration:none;font-weight:bold" target="_blank">A</a> Limited Memory Algorithm </p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">
<br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">for Bound Constrained Optimization, (1995), SIAM Journal on Scientific </p><p style="font-family:Geneva, Arial, Helvetica, sans-serif"><br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">
and Statistical Computing , 16, 5, pp. 1190-1208.</p><p style="font-family:Geneva, Arial, Helvetica, sans-serif"><br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">[2] C. Zhu, R. H. Byrd and J. Nocedal. L-BFGS-B: Algorithm 778: </p>
<p style="font-family:Geneva, Arial, Helvetica, sans-serif"><br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">L-BFGS-B, FORTRAN routines for large scale bound constrained </p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">
<br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">optimization (1997), ACM Transactions on Mathematical Software, </p><p style="font-family:Geneva, Arial, Helvetica, sans-serif"><br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">
Vol 23, Num. 4, pp. 550 - 560.</p><p style="font-family:Geneva, Arial, Helvetica, sans-serif"><br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">HTH,</p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">
<br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">Dawood</p><p style="font-family:Geneva, Arial, Helvetica, sans-serif"><br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<</p>
<p style="font-family:Geneva, Arial, Helvetica, sans-serif"><br></p><p style="font-family:Geneva, Arial, Helvetica, sans-serif">>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<</p>
</span></div><div><div></div><div class="h5"><div><br></div><div><br></div><div><br><div class="gmail_quote">On Mon, Jul 11, 2011 at 9:51 PM, asertyuio <span dir="ltr"><<a href="mailto:asertyuio@yahoo.fr" target="_blank">asertyuio@yahoo.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hy dawood, and thanks for your interest !<br>
<br>
Because I did not found any solution to my divergence problem, I
did abandon the mutual information metric. I try again today, and
found what 'cause' the divergence.<br>
It comes only when I set a moving mask on the metric. No problem
with the fixed mask. Although, I'm sure of my mask validity, because
I'm doing an initialization with them, and I've no problem with
others metrics.<br>
<br>
I join a animated gif showing it. First step is mask registration,
second, image registration, with only a mask on moving image. The
metric value increase, despite the optimizer is set to do the
opposite.<br>
<br>
Setting both masks is important for me because I don't want to take
account of the background outlines on the registration process.<br>
<br>
As I have mostly problems with the regular step gradient optimizer,
I think the problem must be related to derivative computation in the
metric, but I don't know.<br>
Could you confirm this ?<br>
<br>
I'm going to try the LBFGSB optimizer, but there is not much
information on it on itk user guide.<br>
<br>
Best regards,<br>
<br>
Yann<br>
<br>
Le 03/07/2011 19:59, Dawood Al Masslawi a écrit :
<blockquote type="cite">Yann,
<div><br>
</div>
<div>Apparently I misread your outputs, sorry :)</div>
<div><br>
</div>
<div>Have you tried other optimizers? LBFGSB optimizer have proved
to work well</div>
<div><br>
</div>
<div>with the Mattes MI.</div>
<div>
<br>
</div>
<div>Best regards,</div>
<div><br>
</div>
<div>Dawood</div>
<div><br>
</div>
<div><br>
</div>
<div>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<</div>
<div><br>
</div>
<div>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<</div>
<div><br>
</div>
<div><span style="font-family:'Times New Roman';font-size:medium">
<pre>Hi Yann,
If your initialized transform is precise (near perfect?!!) it's only natural
that the optimizer would change less. Have you tried to set the minimum
step length to a higher value?
In the example you provided the metric value is decreasing, isn't that
what you want?
Your fixed and moving images and their intensity distribution also can
effect the quality of the registration, it might be helpful to give us more
information about your images.
HTH,
Dawood
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><i><<<<<<<<<<<<<<<<<<<<<<<<<<<<<
</i>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><i><<<<<<<<<<<<<<<<<<<<<<<<<<<<<
</i>
Hi all,
I'm exploring the mattes mutual information metric with the similarity
transform. I have big problems with the regular step gradient optimizer.
First one, I initialize the transform quite precisely, so only small
change are required, especially for scale and rotation. But I must put
the scaling factor to 100 000, for a maximal step length of 2 to obtain
change around 0.01 for each step. Why is there a x100 between 2/100 000
(what I expect to be the scaled step length) and the one which really
append ?
Second one, the optimizer fails to minimize the metrics (the value seems
to increase), despite the fact that minimizeOn is set, and that I see a
clear behavior difference when maximizeOn is set.
I've played a lot with parameters without significant improvement.
Here is an example :
0 -0.0794786 [1.08213, 0.215013, 142.753, 93.1165, 19.484, -5.38814]
1 -0.0837397 [1.09388, 0.224094, 142.734, 93.1303, 21.0015, -4.08564]
2 -0.0781118 [1.10518, 0.231022, 142.713, 93.1446, 22.5308, -2.79707]
3 -0.07013 [1.11679, 0.230021, 142.688, 93.1515, 23.5889, -1.10016]
4 -0.060149 [1.13054, 0.220847, 142.661, 93.1574, 24.6365, 0.603225]
5 -0.0533438 [1.15086, 0.197135, 142.637, 93.1682, 26.0843, 1.98246]
6 -0.0552559 [1.16682, 0.181277, 142.611, 93.1705, 27.2256, 3.62452]
7 -0.0499306 [1.17806, 0.163796, 142.586, 93.1626, 27.8154, 5.53527]
8 -0.0436633 [1.18673, 0.144479, 142.567, 93.1464, 27.8202, 7.53499]
9 -0.0373628 [1.19785, 0.129059, 142.55, 93.1295, 27.8735, 9.53404]
10 -0.0307262 [1.21034, 0.0999255, 142.53, 93.1149, 28.3516, 11.4756]
11 -0.0280043 [1.21907, 0.0717341, 142.518, 93.0946, 28.3674, 13.4752]
12 -0.0261761 [1.22857, 0.0535265, 142.507, 93.0742, 28.5985, 15.4616]
13 -0.0226728 [1.23642, 0.0331298, 142.5, 93.0514, 28.5777, 17.4612]
14 -0.022181 [1.24189, 0.0185733, 142.495, 93.0282, 28.7283, 19.4553]
15 -0.0190938 [1.25188, -0.00835667, 142.492, 93.0041, 28.7346, 21.455]
16 -0.0196048 [1.25686, -0.0400155, 142.497, 92.9792, 28.4755, 23.4377]
17 -0.0188159 [1.2638, -0.0595771, 142.508, 92.9557, 27.975, 25.3738]
18 -0.0174128 [1.27541, -0.0936444, 142.496, 92.9314, 29.3307, 26.8434]
I've done a deep analysis of the metrics value on my images, and it
is very regular, so the gradient approach seems to be good. The global
minimum with exhaustive search is good also.
I try the 1+1 evo optimizer, he is doing much better, but do not reach
the desired minimum.
I really don't understand where does this behaviour comes from !
Does anyone have any idea of the step I could have missed up ?
Thanks in advance,
Regards,
Yann
</pre>
<div><br>
</div>
</span></div>
</blockquote>
<br>
</div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>