[Insight-developers] Image::TransformPhysicalPointToIndex

[Miller, James V (CRD)]

It's one thing when we talk about a user creating an image and
then setting the transform on it that converts between physical
and index coordinates.

I would guess, however, that if said image is passed through a filter,
the transform the user supplied for the input will not be transferred
to the output.  Furthermore, if a filter shrunk or enlarged an image 
(or flipped, cropped, padded, etc.), the filter would not know how to 
appropriately modify the input transform (given that the input transform 
could be anything from an affine to an ultrasound transform).  

We probably need to think about how a filter's output image's transform can be 
different from its input image's transform and develop an API that any filter
can call to modify a transform.

Or, develop a mechanism where a filter either says that it does not modify
the mapping from physical to world or only knows how to modify the mapping
if the transform is an affine.

Finally, some of the filters currently use or should use the spacing for 
proper calculation (gradients being a prime example). If a user swaps the 
transform on a image to something other than the standard affine, then these
filters "should" have to query something on the transform to convert the 
derivatives in index space into derivatives in physical space.



-----Original Message-----
From: Damion Shelton [mailto:dmshelto@andrew.cmu.edu]
Sent: Thursday, February 28, 2002 12:24 PM
To: Luis Ibanez
Cc: insight-developers@public.kitware.com
Subject: Re: [Insight-developers] Image::TransformPhysicalPointToIndex


Hi...

>     if somebody call RebuildTransform() that will
>    crash because the RebuildTransform() method
>    assumes an "AffineTransform"

Perhaps we should remove "RebuildTransform()" altogether. With the 
assumption that origin and spacing are only defined for an affine image, 
the affine transformation could be rebuilt whenever the origin/spacing are 
set, and at no other time.

> 2) If we change the current state, and Nobody (not even
>     RebuildTransform() initialize the transform... then
>     the image will not have a Transform at all and any
>     call to TransformIndexToPhysicalPoint() will be
>     pointless.

We could initialize the origin to 0xN and the spacing to 1xN in the 
constructor, prior to creating the default affine transform (which would 
use these values). So, if you do nothing at all and start transforming 
points, you at least get something that works.

> I will follow Jim's suggestion that the image should
> not be responsible for managing conversions from
> pixels to world coordinates.   Let the image be a
> grid like container and let some other class take over
> the task of interpreting how this grid maps to physical
> space.

<snip>

> This has the drawback (as Damion pointed out before) that
> conversions that are done now with one line of code will
> require three or four....

Afraid I still stick to this position. I think it's safe to assume the 
following:

1) A default affine transformation with origin 0 and spacing 1 is not "bad" 
- if the user intends something else, they should be smart enough to 
specify it by setting the transform explicitly.

2) If the user does not specify a transform explicity, but instead modifies 
the values of origin and spacing, they intend to modify the default affine 
transformation.

3) If the user specifies some other kind of transform, then the image 
should leave well enough alone and not mess with it.

As long as these assumptions are true, there's no reason to move the 
computations offboard.

Agree/disagree?

-Damion-

_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers