[Insight-developers] multi-label point sets

[Nicholas Tustison]

On Apr 13, 2012, at 12:34 PM, M Stauffer -V- wrote:

>> In my implementation for multilabel point set registration, I processed
>> each labeled set within the metric and then just used the existing k-d
>> tree to do single label point location.   That would seem the easiest
>> or at least that's what I thought was the easiest.  
> 
> OK just to make sure I understand, you did one of the options I
> suggested below, i.e. to have the metric pre-process a multi-label point
> set into multiple single-label point sets, and evaluate each set
> individual within the metric and combine for the final metric output?

Yes, that is what I did and in our previous discussions where we've
discussed a itkLabelPointSetMetric class that accepts as input one 
of the existing point set metrics, that is what I had in mind.

> 
>> Tell me more about the labeled point set class.  What would you add
>> to it to help with labeled point set registration?
> 
> The idea is to put the label-specific analysis within the point-set to
> simplify the metrics. That is, the code to analyze on a per-label basis
> would be in the point set itself. e.g. GetNearestNeighbor would use the
> point's data as a label and only consider the nearest point with the
> same label. Probabilistic distance evaluation could be done in the point
> set then instead of the metric. Thus the euclidean distance would be a
> special case where K = 1, and the expectation-based metric could be the
> same as the euclidean distance metric. Of course come to think of it, we
> could merge the expectation and euclid metrics anyway, and internally
> just call a different method on the point locators depending on K.
> 
> In the interest of getting reasonable working code together faster,
> it'll be easier for me to add the multi-label handling to the metrics,
> with a shared method for pre-processing a point set into one or more
> single-label sets. Otherwise
> 

Thanks for the clarification.  Interestingly enough, a related issue came
up when I was making the current k-d tree thread safe and implementing
the current point set metrics.  I had put the point locator in the point set
itself.  THere was, at the time, functionality for computing the bounding box
and I thought point location would also be suited for the point set class.
However, Luis pointed out to me that processes like calculating point locations
or bounding boxes shouldn't be located inside data objects which all made
sense to me so I took out all the bounding box stuff and put the point location
in the metric.  I suspect that would be the easiest and best option.

Nick









> -M
> 
> 
>> On Apr 12, 2012, at 2:28 PM, M Stauffer -V- wrote:
>> 
>>> Hi Nick,
>>> 
>>> Brian and I have been discussing the new point set metrics and how to
>>> use them with labels. We're thinking we'll want to have single point
>>> sets containing multiple labels, and the metrics will 
>> evaluate using the
>>> labels. Presumably we'll store the label information in the point set
>>> data.
>>> 
>>> One need is to be able to perform neighbor searches constrained by
>>> label, and probabilistic searches e.g. for the expectation-based and
>>> jensen point set metrics. Currently the PointsLocator is 
>> used within the
>>> point set metric to find N nearest neighbors, which creates 
>> a k-d tree
>>> representation of the point set during pre-processing. 
>>> 
>>> Do we add per-label search directly to the point sets, presumably by
>>> adding a new k-d tree type? Perhaps creating one that does 
>> probabilistic
>>> neighbor searching as well? Or do we pre-process the 
>> user-supplied point
>>> sets into individual point sets for each label, and then just use the
>>> exciting point locator methods on those?
>>> 
>>> Do we create a separate LabeledPointSet class that knows how 
>> to do these
>>> things, and require that the point set metrics take this type?
>>> 
>>> What do you think?
>>> 
>>> -M
>>> 
>> 
>