[Insight-developers] Image::TransformPhysicalPointToIndex

[Stephen R. Aylward]

I think we should do most (if not all) default constructions in the
image constructor.  That includes the default affine transformation.  
Waiting for the first call is a neat trick, but hardly ever worth the
extra overhead placed on subsequent calls (to see if construction has
occured) or on object destruction (granted, smart pointers help,
but...).

Just my 2 cents....

s

Lydia Ng wrote:
> 
> 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.
> My initial thought was to get the PhysicalToIndexTransform
> and do the transform and rounding inside my metric: eg
> 
>   typename MovingImageType::TransformPointer imageTransform =
>    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
> 
> > -----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
> >
> >
> > I just checked and there already is code that does the bounds
> > checking.  It
> > seems likely that many coordinates might land outside of the
> > dataspace even
> > with truncation, and that is why the bounds checking is still
> > in place.
> > Rounding might introduce a few, but probably insignificant, amoutn of
> > additional pixels landing out of bounds.  I think the
> > benefits of nearest
> > neighbor might outweight the few additional pixels landing
> > out of bounds.
> > Would there be a performance hit with going to rounding?
> > That would be my
> > only concern.
> >
> > wilson
> >
> >
> > ----- 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
> >
> >
> > > 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
> > valid pixel (it
> > > may be outside the image).
> > >
> > > I think the default behavior should truncate and perhaps
> > 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 = 0 ; i < VImageDimension ; i++)
> > >       {
> > >       index[i] = static_cast<long>(inputPoint[i]);
> > >       }
> > >
> > > Any objection if that the truncation is change
> > > to vnl_math_rnd instead? ie.
> > >
> > >     for (unsigned int i = 0 ; i < VImageDimension ; i++)
> > >       {
> > >       index[i] = 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
> > >
> >
> >
> _______________________________________________
> 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