[Insight-developers] Image::TransformPhysicalPointToIndex

[Lydia Ng]

I am hearing 1 Yes, 1 No and 1 Maybe.
I am going to leave itk::Image alone for the time being.
Perhaps we can discuss it on Friday's tcon.

-----
However, I still need a rounding version for my MI metric.=20
My initial thought was to get the PhysicalToIndexTransform
and do the transform and rounding inside my metric: eg

  typename MovingImageType::TransformPointer imageTransform =3D
   m_MovingImage->GetPhysicalToIndexTransform();

  // then do transform + rounding


However I can't get this to compile because m_MovingImage
is a ConstPointer and GetPhysicalToIndexTransform() is not const.

But GetPhysicalToIndexTransform() can't be made const because
it checks if there is a valid image if not it will make a new
trasform. Note that this also mean that GetPhysicalToIndexTransform
can be used in a multi-threaded situation.


Do people agree that GetPhysicalToIndexTransform() should be made
const and be thread-safe?
If so, I prospose that:
[1] we make GetPhysicalToIndexTransform() const and
return whatever m_PhysicalToIndexTransform is without error checking.
[2] make a default affine transform in the constructor Image()


Comments?

- Lydia=20




> -----Original Message-----
> From: Wilson Chang [mailto:wmcst6+@pitt.edu]
> Sent: Wednesday, February 27, 2002 2:21 PM
> To: Miller, James V (CRD); Lydia Ng;
> insight-developers@public.kitware.com
> Subject: Re: [Insight-developers] Image::TransformPhysicalPointToIndex
>=20
>=20
> I just checked and there already is code that does the bounds=20
> checking.  It
> seems likely that many coordinates might land outside of the=20
> dataspace even
> with truncation, and that is why the bounds checking is still=20
> in place.
> Rounding might introduce a few, but probably insignificant, amoutn of
> additional pixels landing out of bounds.  I think the=20
> benefits of nearest
> neighbor might outweight the few additional pixels landing=20
> out of bounds.
> Would there be a performance hit with going to rounding? =20
> That would be my
> only concern.
>=20
> wilson
>=20
>=20
> ----- Original Message -----
> From: "Miller, James V (CRD)" <millerjv@crd.ge.com>
> To: "'Lydia Ng'" <lng@insightful.com>;
> <insight-developers@public.kitware.com>
> Sent: Wednesday, February 27, 2002 4:56 PM
> Subject: RE: [Insight-developers] Image::TransformPhysicalPointToIndex
>=20
>=20
> > Interesting problem.
> >
> > I understand wanting nearest neighbor type calculation but if the
> transform
> > is changed to round then the index returned may not be a=20
> valid pixel (it
> > may be outside the image).
> >
> > I think the default behavior should truncate and perhaps=20
> another method
> > could round.
> >
> >
> >
> > -----Original Message-----
> > From: Lydia Ng [mailto:lng@insightful.com]
> > Sent: Wednesday, February 27, 2002 4:33 PM
> > To: insight-developers@public.kitware.com
> > Subject: [Insight-developers] Image::TransformPhysicalPointToIndex
> >
> >
> >
> > Currently Image::TransformPhysicalPointToIndex
> > does a truncation to convert the index from
> > continuous space to discrete space. i.e
> >
> >     for (unsigned int i =3D 0 ; i < VImageDimension ; i++)
> >       {
> >       index[i] =3D static_cast<long>(inputPoint[i]);
> >       }
> >
> > Any objection if that the truncation is change
> > to vnl_math_rnd instead? ie.
> >
> >     for (unsigned int i =3D 0 ; i < VImageDimension ; i++)
> >       {
> >       index[i] =3D static_cast<long>( vnl_math_rnd(inputPoint[i]) );
> >       }
> >
> >
> > - Lydia
> >
> >
> >
> > _______________________________________________
> > 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
> >
>=20
>=20