[Insight-users] More on: Can metrics handle nodata/void data values ?

Luis Ibanez luis . ibanez at kitware . com
Fri, 03 Oct 2003 15:34:27 -0400


Hi Carolyn,

Yes, we want the masking functionality into ITK.
This subject was discussed a while ago in one of
the developers meetings. We agree in general in
that masking is a useful and desirable functionality
but we haven't attacked the actual implementation.

This item is among the list of thing to add to the
toolkit this year (before september 2004).


----

About option (C) the idea was to encapsulate in
a single entity both the image to be registered
and the mask of valid pixels. This entity will
have the API of a SpatialObject. this option
may result in a more complex implementation.

I would rather go with adding only the masks
as spatial objects to the Metrics.

What metric are you currently using ?

maybe we could start introducing these changes
in a specific Metric.



   Luis



------------------------
Carolyn Johnston wrote:
> Hi Luis,
> 
> I'm looking at doing the modification in the short term.
> 
>> Option (C) could be implemented using SpatialObjects.
>> The big difference here is that the registration will
>> be then performed between two SpatialObjects that
>> each one encapsulate an image (fixed and moving images
>> respectively). 
> 
> 
> I am not completely  clear on what you mean by this... Is it necessary 
> to modify the registration code so that SpatialObjects are used 
> throughout, instead of images?
> 
> I was trying to design my changes so that I affect ITK code to the least 
> extent possible, and do most of it through extending classes. If you 
> want this functionality in ITK, however, maybe I shouldn't worry about 
> that.
> 
>> I still would be inclined to do the modifications on
>> the metrics themselves, rather than the iterators.
>> Making the change in the iterator simply hides the
>> "if" deeper into the code. 
> 
> 
> OK, I agree with this. I also wanted to avoid duplicating code in the 
> subclasses of ImageToImageMetric. I don't see any way around that though.
>