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

[Carolyn Johnston]

Hi Luis,

apropos of this discussion about handling nodata values, which actually 
took place a little while ago (but I am actually now on the verge of 
making these modifications):

I like the idea of making the interpolator return 'true' to the query of 
whether a nodata pixel is outside the moving data region. That's slick, 
by golly, which is what OO programming is all about: slickness!

But sticking an 'if' statement into the loop that iterates over the 
fixed image's datapoints, to check for nodata values... welllll... 
that's not very slick. :D

But here's what I'm thinking. I'm thinking of using a "Decorator" 
pattern to make the images aware of their own nodata values (lest this 
sound pointlessly tricky, realize that I am also doing multiresolution 
registration and will have to figure out how to handle the filtering of 
nodata values as well). What do you think about modifying the fixed 
image iterator so that it simply skips over image pixels that are nodata 
values as though they weren't there?

If I made these modifications, I don't believe I would have to rewrite 
the metrics at all.

Please let me know what you think of all this and how you would do it 
differently.

:) Thanks, Carolyn
 

Luis Ibanez wrote:

> Hi Carolyn,
>
> Thanks for the clarification.
>
> That actually raises a good point: We will need two masks
> instead of one. In that way one mask can be associated to
> the fixed image space and the other to the moving image
> space.
>
> ---
>
> Now that, on the pragmatic side:
> You probably already have assigned a distinct gray value
> to the pixels that you know are "void".
>
> You can make a "minimally invasive intervention" in the
> itkNormalizedCorrelation ImageToImageMetric and/or
> the itkMeanSquaresImageToImageMetric.
>
> Simply go to the loop that iterates over the pixels of the
> fixed image and add an "if()" that test for the "void" pixel
> value.
>
> For the moving image you have two options
>
>  1) the easy option
>  2) the correct option
>  3) the elegant option
>
> The easy option is to use nearestneighbor interpolator,
> and let the interpolator get the gray value of the moving
> image for you. Then you test this value against your "void"
> value and reject or accept the pixel accordingly.
>
> The correct option requires you to first map the point to the
> coordinates of the moving image, then convert Physical point
> to index, and finally probe the moving image in order to
> obtain the pixel value.
>
> The elegant option involves to built-in this functionality
> on the interpolator itself.  Part of the work of the interpolator
> is to determine if the requirested position is inside or outside
> of the image. So, it is natural for the API to also manage
> holes inside the image.   In this option you could take your
> favorite ITK interpolator,  copy it, rename it and modify
> its code, for the verifiction of being inside or outside.
> You will add a check for the pixel value against the code
> you user for "void" pixels.
>
>
>
> Regards,
>
>
>    Luis
>
>
> ---------------------------
>

-- 
Carolyn P. Johnston, Ph.D.
Sr. Research Engineer
Vexcel Corporation
1690 38th Street, Boulder, CO 80301
ph: 303-583-0273
fax: 303-583-0246