[Insight-developers] Image::TransformPhysicalPointToIndex

[Luis Ibanez]

Sorry, I missed the point in the previous mail.


  GetPhysicalToIndexTransform() and
  GetIndexToPhysicalTransfrom() are non const


I was making reference to TransformPhysicalPointToIndex()...



What Lydia proposed seem to be the only way out.
That is: Just return the pointer without any checking nor
any attempt for rebuild the Transform.

Otherwise we will have to declare RebuildTransfrom() "const"
and that's not quite right. A Transform change must indicate
a change in the image and must also trigger Modified() in
order force any filter using the image as input to be recomputed.

Sorry about the confusion.

    Luis


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

Luis Ibanez wrote:

>
> 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
>>
>
>
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>