[Insight-developers] accessing metrics

[Lydia Ng]

Luis, Brian:

Since both are you seems okay with it, shall we
say that we go for this API?

>=20
>        GetValue( parameters, region )
>=20

> The only tricky point will be to verify that the region is contained
> on the BufferedRegion. For that you can use the=20
> Region::IsInside( Index )
> method and test the corners of the region.  Probably we should add
> a   Region::IsInside( Region )   method just for convinience.

I like the idea of Region::IsInside( otherRegion ).

The other question is what should we do if the region is not wholly
contained within the BufferedRegion?

Brian: for your application what do you require when the
region is overlaps the image boundary?

Lydia



> -----Original Message-----
> From: Luis Ibanez [mailto:ibanez@cs.unc.edu]
> Sent: Tuesday, February 05, 2002 9:15 AM
> To: Lydia Ng
> Cc: Brian B Avants; insight-Developers
> Subject: Re: [Insight-developers] accessing metrics
>=20
>=20
>=20
> Lydia, Brian,
>=20
>=20
> Both modifications to the metrics seems to be worth to keep.
>=20
> 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:
>=20
>      Metric:: SetRegion( const RegionType & region )
>=20
> and then an independent:
>=20
>      Metric::GetValue( const ParametersType & param )
>=20
> 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:
>=20
>        GetValue( parameters, region )
>=20
> So, I'm happy with this API too.
>=20
> 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=20
> Region::IsInside( Index )
> method and test the corners of the region.  Probably we should add
> a   Region::IsInside( Region )   method just for convinience.
>=20
>=20
> I then move ahead and write a filter (Lydia's item [3] ) that explores
> the parameter space using a regular sampling.
>=20
> Is that ok   ?
>=20
>=20
>   Thanks =20
>=20
>=20
>      Luis
> =20
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
>=20
>=20
> Lydia Ng wrote:
>=20
> >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
> >_______________________________________________
> >Insight-developers mailing list
> >Insight-developers@public.kitware.com
> >http://public.kitware.com/mailman/listinfo/insight-developers
> >
>=20
>=20
>=20
>=20