[Insight-developers] another image transform question

[Damion Shelton]

Looks like that did the trick. I'm still building the tests, but I'll 
commit once it looks stable.

Thanks,
-Damion-

On Monday, February 10, 2003, at 06:30 PM, Lydia Ng wrote:

> 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]
> 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
> transform a point on line 165. This same process occurs again on lines
> 269 and 282. I don't think what's happening there could be replaced by
> one of the Index<-->Physical transforms in Image, because the
> 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
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers