[Insight-users] Gradient Difference Metric

[Luis Ibanez]

Hi Aviv,

Thanks for pointing this out.


Please log a bug about this class in the MANTIS bug tracker:
http://public.kitware.com/Bug/login_page.php

Regarding the behavior of this class and its lack of consistent
documentation.

It seems that the code for computing GetDerivative() is indeed
broken.

--

As you pointed out, due to the Backward Compatibility policy is
very unlikely that we will change the Maximizing or Minizing
default setting of any metric.


Please note that all ITK optimizers provide a flag that allow you
to switch their behavior between maximization and minimization.


Following your request, we have added further documentation to the
Doxygen header, to make clear that this metric must be MAXIMIZED.

We have also added an example on how to use this metric, to the
directory:

      Insight/Examples/Registration/

under

          ImageRegistration18.cxx


You can run this example by registering two identical images
and providing an initial mis-registration value for initializing
the Transform.

Like:

       ImageRegistration18  image1 image1 3.5 4.6


Please note that in order to resucitate the metric, an option
for setting the delta used in the finite differences estimation
of the Derivative was added to the public API of the class.

You may want to update your CVS checkout of ITK before you try
this new example.


In any case, we must still track the problems with the GetDerivative
method.


   Regards,


     Luis


---------------------
Aviv Hurvitz wrote:
> I saw that in the docs.
> 
> In my opinion that bit, and the cited paper, are not enough for users to 
> understand what needs to be done. The fact is that it confused me, and 
> apparently others as well, and the cost of this confusion was big.
> 
> I suggested a few solutions:
> 1. Change the metric to go down.
> 2. Add a flag to all image metrics that says which way they go.
> 3. Clarify the metric direction in the docs.
> 
> You say #1 is impossible since it might break old code, and I agree. 
> (reluctantly... :)
> #2 is best, I think, since it would allow both kinds of metrics to be 
> plugged into the same framework.
> #3 is probably worst, because it would only solve the problem in this 
> particular metric, and it would still leave room for user errors.
> 
> Having read the code, I got the feeling that no one has used this metric 
> successfully. Sadly, I can't actually PROVE it now with a smoking gun. 
> I'm curious to know if there is any reader out there who uses this 
> metric. I'm not saying that we have a license to break it, I'm just 
> giving you some background about how I feel about this metric. In my 
> opinion, it's not on par with the rest of ITK, with regards to 
> documentation, test cases, and code quality.
> 
> I wish this thread wouldn't end with the conclusion that everything is 
> perfect just the way it is. Would someone please acknowledge that there 
> is a problem?
> 
> Regards,
> 
> - Aviv
> 
> 
> On Thu, Jun 26, 2008 at 1:17 PM, Hauke Heibel <heibel at cs.tum.edu 
> <mailto:heibel at cs.tum.edu>> wrote:
> 
>     Aviv Hurvitz wrote:
> 
>         All the metrics I know in ITK go "down". There was no special
>         documentation, ...
> 
>     As a matter of fact there is. Take a look at
>     http://www.itk.org/Doxygen34/html/classitk_1_1GradientDifferenceImageToImageMetric.html
>     It states "after passing the squared difference through a function
>     of type 1/(1+x)".
> 
>     And I would not expect the functionality to change since there are
>     many people who got the usage right and whose code would break if
>     the class's functionality would change.
> 
>     - Hauke
> 
>     -- 
>     Tim Hauke Heibel
>     Computer Aided Medical Procedures (CAMP)
>     fon: +49 89 289 19427
>     fax: +49 89 289 17059
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users