[Insight-users] Gradient Difference Metric

[Aviv Hurvitz]

Hi Dan,

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.

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.

Please note that:

1. the name "GradientDifference" suggests that you want to minimize this
metric.
2. there is no clear documentation on which way this metric goes.
3. most metrics do go down, so I think users are right to expect this by
default.

Maybe the confusion could be solved by having metrics return a flag that
tells the framework which way they should go?

- Aviv


On Thu, Jun 26, 2008 at 10:49 AM, Aviv Hurvitz <aviv.hurvitz at gmail.com>
wrote:

> Hi Dan,
>
> Thanks, I've been using ITK for a while now and I didn't know about this
> feature of optimizers.
>
> 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.
>
> 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").
>
> 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.
>
> So for future reference, I still classify this bug as really "huge".
>
> Kind regards,
>
> - Aviv
>
>
> On Thu, Jun 26, 2008 at 9:20 AM, Dan Mueller <dan.muel at gmail.com> wrote:
>
>> Hi Aviv,
>>
>> 2008/6/25 Aviv Hurvitz <aviv.hurvitz at gmail.com>:
>> > In short, the GradientDifferenceImageToImageMetric is bad! It has one
>> huge
>> > bug and a few other debatable problems. The huge bug is that it returns
>> the
>> > MAXIMUM value when the registered images are perfectly aligned, whereas
>> it
>> > should return the MINIMUM. That's right, this metric actually pushes the
>> > moving image away from the right result.
>> >
>> > I wonder how this came to be? My guess is that the original developer
>> was
>> > using it in a different framework, where registration involved
>> maximizing. I
>> > Googled a bit and the few reports on this metric were either that it
>> doesn't
>> > work or that it *maybe* works, so I guess it  checks out.
>>
>> For future reference, this is not really a "huge" bug. Optimizers can
>> be configured to either minimize or maximize a metric; simply call
>> optimizer->MinimizeOn() or optimizer->MinimizeOff() depending on your
>> chosen metric.
>>
>> HTH
>>
>> Regards, Dan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20080626/227a291a/attachment.htm>