[Insight-developers] Image::TransformPhysicalPointToIndex

[Luis Ibanez]

Lydia,

These changes have already been done.

bool TransformPhysicalPointToContinuousIndex() is now const
and no Transform is instantiated inside. That was necesary in order
to support Generic transforms in images.

Only the Image constructor is instantiating an AffineTransform and
plugging it into the generic Transform pointer.  We are however
checking the Tranform pointer for NULL and throwing an exception
in case they are.

Images requiring other Transform has to derive from itk::Image and
instantiate the corresponding  xxTranforms in their constructors.

They also have to overload      "RebuildTransform()" in order
to initialize the transform with the actual origin and spacing in any
way that could make sense for the particular transform.

  Luis


==============================================

Lydia Ng wrote:

>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
>