[Insight-developers] accessing metrics

[Luis Ibanez]

Lydia, Brian,


Both modifications to the metrics seems to be worth to keep.

For setting the region of the image over which the metric is
computed I was inclined for an API in which we set the
region alone:

     Metric:: SetRegion( const RegionType & region )

and then an independent:

     Metric::GetValue( const ParametersType & param )

But since the GetValue() method will usually take a long time to
be computed, this doesn't make a big difference with respect
to Lydia's API:

       GetValue( parameters, region )

So, I'm happy with this API too.

Brian, would you like to make those changes to the Metrics ?
The only tricky point will be to verify that the region is contained
on the BufferedRegion. For that you can use the Region::IsInside( Index )
method and test the corners of the region.  Probably we should add
a   Region::IsInside( Region )   method just for convinience.


I then move ahead and write a filter (Lydia's item [3] ) that explores
the parameter space using a regular sampling.

Is that ok   ?


  Thanks  


     Luis
 

=============================================



Lydia Ng wrote:

>Hi Brian and Luis,
>
>I think there are three different requests here:
>
>My interpretation of what Brian wants is a way to:
>[1] compute metric only over a particular region of the
>    target image.
>[2] a filter that will compute an image of *local* metric values  
>    by moving the computation region over the image.
>
>My interpretation of what Luis is describing is:
>[3] a filter that will sample the transform parameter space
>and produce an image of the *global* metric values at each
>point in transform parameter space.
>
>My two cents' worth:
>===================
>I think request [1] can be easily catered for. Most
>of the metric are currently using either the 
>LargestPossibleRegion or the BufferedRegion.
>
>Propose changes for SimiliarityRegistrationMetric API:
>
>/* GetValue computes the metric for the specified
>   Target region. This function assumes that the Target
>   and Mapper has already been set. */
>MeasureType GetValue( const ParametersType& parameters,
> RegionType& region );
>
>/* This version of GetValue computes the metric for
>   the BufferedRegion of the Target. */
>MeasureType GetValue( const ParametersType& parameters )
> {
>   return GetValue( parameters, 
>   this->GetTarget()->GetBufferedRegion() );
> }
>
>Ditto for the GetValueAndDerivative functions.
>
>I think BufferedRegion should be used because the metric
>calculators are assumed to be non-pipeline objects to be
>use for filters that are pipeline objects. For example, I
>think it should be the responsibility of the RegistrationFilter
>or whatever filter to negotiate how much of the image it needs.
>
>Once request [1] has been dealt with, I think [2] can easily
>be implemented by having a separate filter that repeatedly call
>GetValue from the calculator.
>
>I think all the metric can easily be altered to cope with the
>new API. For MI, it should just be a matter of limiting where
>the spatial sample are drawn from. When we've agreed on an API, 
>I'll be happy to change the MI class. 
>
>Request [2] readily lends itself to a multi-threaded implementation.
>A word of warning here: current implementation of MI cannot be used
>across different threads as it stores the samples in a member ivar.
>Yes, MI can be made thread-safe but at the cost of allocating the
>sample containers each time we want to compute a value.
>I'm very reluctant to make this change. This has not been an issue
>so far as the current registration deals with a global transform and
>as such does not lend itself to being multi-threaded.
>This issue probably requires further discussion and maybe some
>profiling.
>
>To my understanding no API changes to the 
>metric classes is required to implemented [3].
>
>Comments?
>
>- Lydia
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers
>