[Insight-developers] itkAzimuthElevationToCartesianTransform

[Wilson Chang]

> Some template parameters are being removed from the Transforms.
>
> Among the transforms there is
>
>                itkAzimuthElevationToCartesianTransform
>
> deriving from
>
>                itkAffineTransform.
>
> Is there any advantage in deriving from itkAffineTransform
> instead of deriving from the generic itkTransform ?
>

What Jim said about AzimuthElevationToCartesianTransform is correct.  It was
just a stop-gap.

what do you think about definining an itkTransformBase class that the
itkImage class uses (as opposed to the current use of itkAffineTransform)?

> What are the parameters of this transformation ?

azimuth sweep angle, elevation sweep angle, azimuth angular seperation,
elevation angular seperation, distance the first sample is from the origin.

> maybe the orientation of the poles ?
> and the origin of the azimuth and altitud angles?

We assume that a pole goes through the center of this ultrasound "wedge."
This application is very specific for 3-D ultrasound captured in
azimuth-elevation(A-E) coordinate systems and is not scalable to
N-dimensions without ambiguity.  A-E is different from conventional polar
coordinates.


> We may need to define SetParameters() and a GetJacobian()
> methods for it.

there is some stuff derived from itkAffineTransform that is not needed, such
as jacobian.  A-E transforms can not be done with matricies.

>
> There are also methods for sampling the input space of the
> transform and getting the images of the sampling points
> at the output space. This can be quite useful but maybe this
> functionality should be implemented in a filter rather than
> a Transform.

I think a filter would be a better idea.  perhaps this filter could be use
the proposed itkTransformBase class, and then people could plug whatever
transform they wanted into this filter.

>
> This transform also have methods for making it work
> Forwards or Backwards, In principle the API of the
> transforms uses : Transform() and BackTransform()
> for this purpouse.
>

yes, there is a flag in itkAzimuthElevationToCartesianTransform to say which
direction (A-E to cartesian, or cartesian to A-E) is forward, and which is
backward.  I think I called them:

  void SetForwardAzimuthElevationToCartesian();
  void SetForwardCartesianToAzimuthElevation();

I know this doesnt make for a standard API, but at the time, I think this
was the only solution (again, without rewriting itkImage)

>
> This class will be fundamental for registering Ultrasound
> images with rectangular grid images like CT or MRI.
>
> We may want to have a 2D and a 3D version (the current
> one is 3D).
>
> In fact the 2D could be implemented as a ND cylindrical
> transform  that maps 2 of the dimension into a circle and
> left the others untouched.  In that way the same class will
> serve to map 2D ultrasond to 2D rectangular-grid images,
> and 2D ultrasound parallel sequences to 3D rectangular-gird
> images.

This sounds like it should be taken care of with a polar coordinate to
cartesian transform class, not A-E to cartesian transform.  A-E is very
specific for 3-D.  polar coordinates can be N-D, right?

>
> The current 3D version could also be generalized to ND by
> mapping 3 of the N dimensions into a sphere leaving the
> other dimensions untouched. That will serve for mapping
> time sequences of 3D ultrasound to time sequences of
> 3D rectangular-grid images (because time will still be
> rectilinear).
>

This would be fine.

>
> Would these changes disrupt the current use of this class ?
>


wilson