[Insight-developers] Image::TransformPhysicalPointToIndex

[Stephen R. Aylward]

Just to help me understand the issues, basically we have several kinds
of expected element spacings...

Isotropic
	- consistent throughout volume
	- no re-scaling of image space necessary

Rigid
	- consistent throughout volume
	- scale image space by coordinate
	- gradient calculations (for example) scaled by a global vector
Affine
	- scale and shear image space
	- gradient calculations scaled by a global matrix

Varying slice thickness (common in radiation oncology)
	- scale image space different in each slice
	- gradient calculations scaled by a locally varying vector
Ultrasound
	- polar coordinates
	- gradient calculations scaled by a locally varying matrix
Arbitrary (result of non-rigid registration)
	- gradient calculations scaled by a locally varying matrix

To me, this implies that basically there are three general classes of
transforms for our filters:
Isotropic, GlobalTransform, LocallyVaryingTransform

These groupings reflect computational complexity/speed issues.   Could
these be made into concepts?

I just read Luis' follow-up email.   I like the idea of having the input
transforms be responsible for producing output transforms given a
transform performed by the filters.

Stephen


"Miller, James V (CRD)" wrote:
> 
> 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers

-- 
===============================================
Dr. Stephen R. Aylward
Assistant Professor of Radiology
Adjunct Assistant Professor of Computer Science
http://caddlab.rad.unc.edu
aylward@unc.edu
(919) 966-9695