[Insight-developers] another image transform question

[Lydia Ng]

Damion:

Ok - lines 165 and 282 is actually using the Transform supplied to the
metric as part of registration and not the Image's affine transform.

-However-

It is using the moving image's PhysicalToIndex transform for the purpose
of doing nearest neighbor interpolation of the gradient image in lines
182 and 302.

This is also done is a couple of other metrics as well.

I presume we are still keeping the
TransformPhysicalPointToContinousIndex API? If so, I will change the
code to use that instead of keeping a copy of the transform.

But I probably won't get it finished until tomorrow morning though.

-Lydia=20

-----Original Message-----
From: Damion Shelton [mailto:beowulf@cs.cmu.edu]=20
Sent: Monday, February 10, 2003 1:51 PM
To: Lydia Ng
Cc: Insight-developers@public.kitware.com
Subject: Re: [Insight-developers] another image transform question

It obtains a transform from the image on line 152 and uses it to=20
transform a point on line 165. This same process occurs again on lines=20
269 and 282. I don't think what's happening there could be replaced by=20
one of the Index<-->Physical transforms in Image, because the=20
transformed point is plugged into an interpolator.

-Damion-

On Monday, February 10, 2003, at 04:43 PM, Lydia Ng wrote:

> Hi Damion,
>
> Isn't itkMeanSquaresImageToImageMetric just using
> image->TransformIndexToPhysicalPoint()?
>
> Or am I missing something?
>
> -Lydia
>
> -----Original Message-----
> From: Damion Shelton [mailto:beowulf@cs.cmu.edu]
> Sent: Monday, February 10, 2003 1:30 PM
> To: Insight-developers@public.kitware.com
> Subject: [Insight-developers] another image transform question
>
> Ok, the previous issue is resolved. A more complicated case arises in
> itkMeanSquaresImageToImageMetric, which assumes that the transform is
> available in the image class. Rather than just transforming indices,
> this class loads the image transform in order to transform points, a
> capability which is not currently provided in the image itself.
>
> I see two solutions:
>
> 1) This class could be modified to create a local (presumably affine)
> transform by obtaining the origin and spacing information from the
> image in question.
>
> 2) Image could maintain a local affine transform, which is implicitly
> created from origin and spacing and cannot be modified. This would be
> similar to the "default" case from before. The Image implementations
of
> TransformBlahToBlah need not actually use this transform (for
> efficiency's sake) but it looks like it would be convenient to have
> around for other classes.
>
> I think the second option is the way to go. Opinions?
>
> -Damion-
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers