[ITK-users] Mattes Mutual Information can produce a false positive?

Mon Jan 4 08:52:33 EST 2016

Hi David and all...

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".

Let's focus on this small part of the execution of the registration:

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]

*23   -0.570385   [0.5048258211954306, 0.029452473766705987,
-0.060948117243475784, -2.7709477953906707, -36.32690303936296,
-29.640626958681565] *

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).

I do not understand the relationship of the optimizer is in a local optimum
with the fact of the metric produces a wrong value ?

Regards,

2016-01-03 23:22 GMT-03:00 David Welch <david.m.welch at gmail.com>:

> You're most likely finding a local minimum - you can't discount the
> implementation just because the minimization value is high.
>
> 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.
>
> 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.
>
>
> On Sunday, January 3, 2016, Gabriel A. Giménez <gabrielgimenez85 at gmail.com>
> wrote:
>
>> Hi again...
>> 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.
>>
>> This is the transformation that generates the error, and appears at
>> random:
>>
>> Metric value:  -0.571747,
>> Transformation:   [0.45776567727601714, 0.041654583723424364,
>> -0.04058569867934432, -0.9751276082246223, -35.48376926584542,
>> -28.108117798651822]
>>
>> 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 ?
>>
>> Attached results (difference before and after) to apply the
>> transformation.
>>
>> Thanks...
>>
>>
>> 2015-12-16 14:55 GMT-03:00 David Welch <david.m.welch at gmail.com>:
>>
>>> Hi Gabriel,
>>>
>>> I’m a little rusty, so maybe someone else can correct my example.
>>>
>>> 1) Consider a circle with one half “dark: and one half “bright" with a
>>> gray background.
>>> 2) Then consider the inverted image (max() - image).
>>> 3) Rotate the inverted image randomly about the center.
>>> 4) Now register the two using Mattes’.
>>>
>>> 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.
>>>
>>> So Mattes’ CAN produce false positives depending on the underlying
>>> statistics for the image pairs.
>>>
>>> Cheers,
>>> Dave
>>>
>>>
>>>
>>>
>>> On 12/15/15, 2:25 PM, "Gabriel A. Giménez" <gabrielgimenez85 at gmail.com>
>>> wrote:
>>>
>>> >Hi all, I hope you are well...
>>> >
>>> >My question is about a implementation of Mattes Mutual Information...is
>>> >possible to produce a false positive ? at times it gives me a high
>>> metric
>>> >value ... but the result of the recording is poor. We use it as a
>>> metric for
>>> >two implementations of optimizers (PSO and Scatter search).
>>> >
>>> >Attached results of two executions, using scatter search:
>>> >
>>> >Moving image: mr_pd
>>> >Fixed image: ct
>>> >Images source: http://www.insight-journal.org/rire/download_data.php
>>> >(patient_001)
>>> >
>>> >Thank you very much and I hope you can help me, regards.
>>> >
>>> >
>>> >ct_mr_pd_incorrect_result.zip
>>> ><
>>> http://itk-insight-users.2283740.n2.nabble.com/file/n7588261/ct_mr_pd_incorrect_result.zip
>>> >
>>> >ct_mr_pd_accurate_result.zip
>>> ><
>>> http://itk-insight-users.2283740.n2.nabble.com/file/n7588261/ct_mr_pd_accurate_result.zip
>>> >
>>> >
>>> >
>>> >
>>> >--
>>> >View this message in context:
>>> http://itk-insight-users.2283740.n2.nabble.com/Mattes-Mutual-Information-can-produce-a-false-positive-tp7588261.html
>>> >Sent from the ITK Insight Users mailing list archive at Nabble.com.
>>> >
>>>
>>>
>>
>>
>> --
>> *Gabriel Alberto Giménez.*
>>
>
>
> --
> Sent from a mobile device
>

-- 
*Gabriel Alberto Giménez.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20160104/59ec9ef6/attachment.html>