[Insight-developers] Better Point Casting

[Lydia Ng]

> I'm having trouble finding  a good differenciation between
> an itkPoint and an itkContinuousIndex. It looks like a Point
> could be used everywhere a ContinuousIndex is being used.
>=20
> It is just a distinction of the reference system ?

The distinction is comes in when we try to access an image.
An itk::Point takes into account the image's spacing and origin=20
(i.e. in patient or geometric coordinates) while a
itk::ContinuousIndex does not take into account the spacing and origin
and refers to a non-integer position in image/grid coordinates.

This difference was agreed upon last time the interpolators
were refactored. The was a request to interpolate an image both in
geometric coordinates and grid coordinates.

- Lydia


> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> Sent: Wednesday, February 20, 2002 7:02 AM
> To: Miller, James V (CRD)
> Cc: Lydia Ng; insight-developers@public.kitware.com
> Subject: Re: [Insight-developers] Better Point Casting
>=20
>=20
>=20
> Miller, James V (CRD) wrote:
>=20
> > I was thinking it might be nice to have CastFrom() on other=20
> objects as=20
> > well.
> > In particular: Index, Offset, Size, ContinuousIndex, ...
>=20
>=20
> Totally agree with that, we have a lot of for() loops here
> and there for doing this (as you already noted).
>=20
> Should we restrict the number of combination to those that
> make sense ? =20
>=20
> We could just add a limited liability function:
>=20
>      template < arraytype A, arraytype B >
>      void
>      CastAtYourOwnRisk( const arraytype & A, arraytype & B );
>=20
> templated function (not belonging to any class) relying on the
> types to have defined: { ValueType, Dimension and operator[] }.
> ...trust the users and hope for the best....!
>=20
>=20
> I would rather not allow casting Points to Vectors because
> that blurrs the distintion between both concepts and removes
> all the interest in having both classes we could just have
> itkArrays in that case. Same thing goes for the distinction
> between Index and Size for example.
>=20
> >
> > Should this be a class member or a separate function?
>=20
> It looks like separate functions will provide more flexibility.
> Maybe putting all of then in an    itkCasting.h      file ?
>=20
> >
> > When I want to use the Radius of a Neighborhood as the
> > Center of an EllipsoidSpatialFunction, I need to create a
> > Point and copy the radius:
>=20
> Isn't this a missuse of the concepts ?
> Why would you like to use a radius as a center ?
> I can see the need for using an Index as a Point and vice-versa;
> the same relation seems to work for Size and Vector.
> In general trying to cast:  Index to Size or Point to Vector
> should be an indication that something wrong is going on.
>=20
> >
> > If we use functions outside of the class, we could avoid
> > templated member functions.
>=20
> This seems to be the best option.
> It will be a matter of selecting what combinations of casting
> should be allowed.
>=20
>=20
> I'm having trouble finding  a good differenciation between
> an itkPoint and an itkContinuousIndex. It looks like a Point
> could be used everywhere a ContinuousIndex is being used.
>=20
> It is just a distinction of the reference system ?
>=20
>=20
> Luis
>=20
>=20
>=20
>=20