[Insight-developers] accessing metrics

[Luis Ibanez]

Lydia, Brian,

I'm Ok with the API   :   GetValue( parameters, region )


I'll add then the method   :   Region::IsInside( otherRegion )

About what to do when the two regions don't overlap completly...

I'll vote for :

1) throwing an exception as a first option,
2) croping the region as a second option

The disadvantage of the first is that it is too drastic...,
The drawack with the second is that the user can get the
impression that the process is working ok, and never notice
the problem.

What would you prefer ?
maybe there are other options...


    Luis

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


Lydia Ng wrote:

>Luis, Brian:
>
>Since both are you seems okay with it, shall we
>say that we go for this API?
>
>>
>>
>
>>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 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
>>
>>
>>
>>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
>>>
>>
>>
>