Hi Dan,<br><br>On second look, it's true that some metrics in ITK go up and some go down. I thought there was a convention of minimizing, but there isn't.<br><br>I think the current situation is very confusing, and the fact is that a few people did use the metric incorrectly. I think something needs to be fixed, but I'm not sure it's the metric anymore.<br>
<br>Please note that:<br><br>1. the name "GradientDifference" suggests that you want to minimize this metric.<br>2. there is no clear documentation on which way this metric goes. <br>3. most metrics do go down, so I think users are right to expect this by default.<br>
<br>Maybe the confusion could be solved by having metrics return a flag that tells the framework which way they should go?<br><br>- Aviv<br><br><br><div class="gmail_quote">On Thu, Jun 26, 2008 at 10:49 AM, Aviv Hurvitz <<a href="mailto:aviv.hurvitz@gmail.com">aviv.hurvitz@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Dan,<br><br>Thanks, I've been using ITK for a while now and I didn't know about this feature of optimizers.<br>
<br>All the metrics I know in ITK go "down". There was no special documentation, so that's what I expected. For comparison, the Mutual Information metric, which is something you want to maximize, is actually minimized by the framework. <br>
<br>I think people shouldn't use the metric like you suggest. Defaults are important if you want the registration metric to be modular ("plug-and-play").<br><br>Please try to imagine the typical user experience with this metric. It is EXTREMELY frustrating, because you have to play around with many optimization parameters before you either debug it or give up. Who knows how many users went down the path Sven and I went before giving up? I know of at least two more users who gave up.<br>
<br>So for future reference, I still classify this bug as really "huge".<br><br>Kind regards,<br><font color="#888888"><br>- Aviv</font><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Thu, Jun 26, 2008 at 9:20 AM, Dan Mueller <<a href="mailto:dan.muel@gmail.com" target="_blank">dan.muel@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Aviv,<br>
<br>
2008/6/25 Aviv Hurvitz <<a href="mailto:aviv.hurvitz@gmail.com" target="_blank">aviv.hurvitz@gmail.com</a>>:<br>
<div>> In short, the GradientDifferenceImageToImageMetric is bad! It has one huge<br>
> bug and a few other debatable problems. The huge bug is that it returns the<br>
> MAXIMUM value when the registered images are perfectly aligned, whereas it<br>
> should return the MINIMUM. That's right, this metric actually pushes the<br>
> moving image away from the right result.<br>
><br>
> I wonder how this came to be? My guess is that the original developer was<br>
> using it in a different framework, where registration involved maximizing. I<br>
> Googled a bit and the few reports on this metric were either that it doesn't<br>
> work or that it *maybe* works, so I guess it checks out.<br>
<br>
</div>For future reference, this is not really a "huge" bug. Optimizers can<br>
be configured to either minimize or maximize a metric; simply call<br>
optimizer->MinimizeOn() or optimizer->MinimizeOff() depending on your<br>
chosen metric.<br>
<br>
HTH<br>
<br>
Regards, Dan<br>
</blockquote></div><br>
</div></div></blockquote></div><br>