[Insight-developers] another image transform question

Lydia Ng lng@insightful.com
Mon, 10 Feb 2003 15:30:43 -0800


Ok - I've modified the metrics so that they don't try to
GetPhysicalToIndexTransform anymore - please update.

-Lydia

-----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