[Insight-developers] Image::TransformPhysicalPointToIndex

[Wilson Chang]

damion,
the spacing is defined for non affine images such as our ultrasound images.
The spacing is the angular seperation between each voxel.


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