<div dir="ltr">Hi David and all...<div><br></div><div>David,really I do not understand some aspects of your answer ... ,first ... sorry for my bad english. With a "high" value of metrics I refer to a "good" value, not mathematically "high".</div><div><br></div><div>Let's focus on this small part of the execution of the registration:<br></div><div><br></div><div><pre class="">19   -0.56353   [0.019933984547764932, -0.010499154976998975, -0.00811108303741948, 0.6163571650068174, -24.641443477933247, -2.2643196247633544]
20   -0.56353   [0.019933984547764932, -0.010499154976998975, -0.00811108303741948, 0.6163571650068174, -24.641443477933247, -2.2643196247633544]
21   -0.56353   [0.019933984547764932, -0.010499154976998975, -0.00811108303741948, 0.6163571650068174, -24.641443477933247, -2.2643196247633544]
22   -0.56353   [0.019933984547764932, -0.010499154976998975, -0.00811108303741948, 0.6163571650068174, -24.641443477933247, -2.2643196247633544]
</pre><pre class=""><b><span style="color:rgb(0,0,0);font-family:'Courier New',Courier,monospace,arial,sans-serif;font-size:14px;white-space:pre-wrap">23   -0.570385   [0.5048258211954306, 0.029452473766705987, -0.060948117243475784, -2.7709477953906707, -36.32690303936296, -29.640626958681565]</span> </b></pre><br>The  transformation in "bold" (23) is the erroneous, before this trasform definitely the optimizer is in a local minimum or perhaps in a global (the transformations 19 - 22 produce excellent registrations). The transform 23 is "better" (according to the metric value) but the registration is very bad (really bad). </div><div><br></div><div>I do not understand the relationship of the optimizer is in a local optimum with the fact of the metric produces a wrong value ?<br></div><div><br></div><div>Regards, <br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-03 23:22 GMT-03:00 David Welch <span dir="ltr"><<a href="mailto:david.m.welch@gmail.com" target="_blank">david.m.welch@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You're most likely finding a local minimum <span></span>- you can't discount the implementation just because the minimization value is high.  <div><br></div><div>For example, two images of different patients would produce a "high" minimization value even though the registration might be very good.  Each registration problem is unique, so you haven't found a "smoking gun" yet. </div><div><br></div><div>Try plotting the metric value over the range of accepted values for your transform and I'll wager you'll see that the minimization is converging on a local minimum somewhere.  That will tell you what parameter of your optimization you need to tweak.<div><div class="h5"><br><br>On Sunday, January 3, 2016, Gabriel A. Giménez <<a href="mailto:gabrielgimenez85@gmail.com" target="_blank">gabrielgimenez85@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi again...</div><div>Thanks for your answer David, I was doing more tests to be sure of the problem. I do not know the implementation of metrics and is beyond of the scope of my work, but definitive think it's a bug of the implementation.</div><div><br></div><div>This is the transformation that generates the error, and appears at random:<br></div><div><br></div><div>Metric value:  -0.571747, </div><div>Transformation:   [0.45776567727601714, 0.041654583723424364, -0.04058569867934432, -0.9751276082246223, -35.48376926584542, -28.108117798651822]<br></div><div><br></div><div>My optimizer generates random solutions, perhaps it could be generating an "rare"  solutions ... but the metric should not calculate a high value for this types of solutions, no ?<br></div><div><br></div><div>Attached results (difference before and after) to apply the transformation.<br></div><div><br></div><div>Thanks...</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-16 14:55 GMT-03:00 David Welch <span dir="ltr"><<a>david.m.welch@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Gabriel,<br>
<br>
I’m a little rusty, so maybe someone else can correct my example.<br>
<br>
1) Consider a circle with one half “dark: and one half “bright" with a gray background.<br>
2) Then consider the inverted image (max() - image).<br>
3) Rotate the inverted image randomly about the center.<br>
4) Now register the two using Mattes’.<br>
<br>
Do you see the problem? Statistically, both pairings of bright->bright and bright->dark have the same entropy to Mattes’, so neither would be preferred and the algorithm would settle on which ever solution it reaches first and would give a false positive 50% of the time.<br>
<br>
So Mattes’ CAN produce false positives depending on the underlying statistics for the image pairs.<br>
<br>
Cheers,<br>
Dave<br>
<div><div><br>
<br>
<br>
<br>
On 12/15/15, 2:25 PM, "Gabriel A. Giménez" <<a>gabrielgimenez85@gmail.com</a>> wrote:<br>
<br>
>Hi all, I hope you are well...<br>
><br>
>My question is about a implementation of Mattes Mutual Information...is<br>
>possible to produce a false positive ? at times it gives me a high metric<br>
>value ... but the result of the recording is poor. We use it as a metric for<br>
>two implementations of optimizers (PSO and Scatter search).<br>
><br>
>Attached results of two executions, using scatter search:<br>
><br>
>Moving image: mr_pd<br>
>Fixed image: ct<br>
>Images source: <a href="http://www.insight-journal.org/rire/download_data.php" rel="noreferrer" target="_blank">http://www.insight-journal.org/rire/download_data.php</a><br>
>(patient_001)<br>
><br>
>Thank you very much and I hope you can help me, regards.<br>
><br>
><br>
>ct_mr_pd_incorrect_result.zip<br>
><<a href="http://itk-insight-users.2283740.n2.nabble.com/file/n7588261/ct_mr_pd_incorrect_result.zip" rel="noreferrer" target="_blank">http://itk-insight-users.2283740.n2.nabble.com/file/n7588261/ct_mr_pd_incorrect_result.zip</a>><br>
>ct_mr_pd_accurate_result.zip<br>
><<a href="http://itk-insight-users.2283740.n2.nabble.com/file/n7588261/ct_mr_pd_accurate_result.zip" rel="noreferrer" target="_blank">http://itk-insight-users.2283740.n2.nabble.com/file/n7588261/ct_mr_pd_accurate_result.zip</a>><br>
><br>
><br>
><br>
>--<br>
>View this message in context: <a href="http://itk-insight-users.2283740.n2.nabble.com/Mattes-Mutual-Information-can-produce-a-false-positive-tp7588261.html" rel="noreferrer" target="_blank">http://itk-insight-users.2283740.n2.nabble.com/Mattes-Mutual-Information-can-produce-a-false-positive-tp7588261.html</a><br>
>Sent from the ITK Insight Users mailing list archive at Nabble.com.<br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><font color="#666666" size="1"><i><b>Gabriel Alberto Giménez.</b></i></font></div></div>
</div>
</blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br>-- <br>Sent from a mobile device<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font color="#666666" size="1"><i><b>Gabriel Alberto Giménez.</b></i></font></div></div>
</div>