[Insight-developers] is it a bug in mean reciprocal square image to image metric

Ashish Poddar ahpoddar at gmail.com
Fri Jul 8 21:05:18 EDT 2005


Hi Luis,

Thanks for the explanation, now i do understand and appreciate the motive 
behind the metric, the way it is. It is only the name of the metric
"MeanReciprocal Square Metric" which caused the confusion. But in fact
its
behaving like a (Sum of (Normalized (Squared Differences))) Metric ... 

may be a comment about this should be added in the documentation as well.

with regards,
Ashish.



On 7/8/05, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> 
> 
> 
> Hi Ashish,
> 
> No,
> this Metrics *must not* be divided by the number of pixels counted.
> 
> In fact, the nice property of this metric is that it gets better
> when you use many pixels.
> 
> Here is the rationale:
> 
> When you use a metric such as mean squares, where the contributions
> of individual pixels are "good" when they have numerical values,
> you have the conflicting situation that you can get a good value
> because the pixels are very close in intensities, or because you
> have just a few pixels. Therefore, in order to eliminate the second
> case you are forced to divide by the number of pixels.
> 
> In the case of the reciprocal metric, the more pixels you count,
> the better the metric gets, and the closer their intensities are
> between the fixed and the moving image, the better the metric gets.
> 
> Dividing by the number of pixels will destroy the most interesting
> property of this metric.
> 
> 
> Another nice property of this metric is the fact that you know what
> the optimal value would be. It is equal to the number of pixels
> counted. E.g. this is obtained only when all the intensities of the
> fixed image pixels are equal to the intensities of the moving image
> pixels.
> 
> 
> 
> Please let us know if you have any other questions,
> 
> 
> Thanks
> 
> 
> 
> Luis
> 
> 
> ---------------------
> Ashish Poddar wrote:
> 
> > Hi,
> >
> > in mean reciprocal square image to image metric, the value being
> > returned is simply the sum of 1.0f / ( 1.0f + m_Lambda* ( diff * diff )
> > ); for all the differences computed throughout the image. isnt it
> > supposed to be divided by the this->m_NumberOfPixelsCounted in the end
> > before returning?
> >
> > with regards,
> > Ashish.
> >
> 
> 
> 
> 


-- 
Ashish Poddar
Have an acceptable reason for accepting anything.
Y:ashish_poddar | MSN:ashish_poddar at yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.itk.org/mailman/private/insight-developers/attachments/20050708/4e42a62f/attachment.htm


More information about the Insight-developers mailing list