[Insight-developers] accessing metrics

[Lydia Ng]

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 =20
    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:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I think request [1] can be easily catered for. Most
of the metric are currently using either the=20
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,=20
   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,=20
I'll be happy to change the MI class.=20

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=20
metric classes is required to implemented [3].

Comments?

- Lydia