[Insight-users] Transformation in ModelToImageRegistration example

Tue Apr 18 12:10:24 EDT 2006

Hello,

Thanks for that explanation.

Well that certainly makes things confusing. I understand what is  
occurring now, it's just inconsistent with what I was presuming were  
reasonably well defined and consistent terms. I think it's extremely  
poor practice to spend pages defining the "Direction of the Transform  
Mapping" for the registration and then abuse it this way. I do see  
how this direction of transformation is more useful. Why the Image is  
labeled fixed and the SpacialObject is labeled moving and this is a  
ImageToSpatialObject I just don't understand.

As per your suggestion I began looking at the  
PointSetToImageRegistration. This seems to be better. First the  
documentation clearly states the direction of the transformations  
using precise mathematical terminology as opposed to "SpacialObjects  
being mapped" (generically involed is said transformation),  "uses  
the coordinate system of the Fixed image" (meaning less),  or "will  
map the Moving SpatialObject on top of the Fixed Image" (using to  
would have said something, but not on top of). That was just my  
interpretation of that documentation, but I also get a different  
meaning when I run into the term "Vector Space", then most. Second,  
the labeling of the "fixed" item (avoiding the term object) and the  
"moving" item is consistent with my understanding from the book.

Thanks,
Brad

On Apr 18, 2006, at 10:30 AM, Luis Ibanez wrote:

>
> Hi Bradley,
>
> Thanks for pointing this out.
>
> The conversion between index and point has been fixed
> for using the image method TransformIndexToPhysicalPoint.
>
> You may have to update your CVS checkout of ITK in order
> to get these fixes.
>
>
>
> As you pointed out, this example is taking some shorcuts.
> The metrics in the SetSpatialObjectMethods samples the
> spatial object using the grid of the image. This is not
> the best way of getting a pointset for representing the
> spatial object, and as you indicated, it only works because
> the example is set up in such a way that the images and
> the spatial object are originally aligned. The misalignment
> is introduced later on, just before running the registration
> algorithm.
>
> A more realistic way of using the Spatial Objects to sample
> them in order to generate a PointSet, then use the PointSet
> toImage registration method.
>
> What creates ambiguity in the case of the ModelToImage registration
> is that the concept of what is Fixed and what is Moving has been
> reversed.
>
> In the rest of ITK the registration framework defines the Fixed
> object as the source of points to be mapped into the space of the
> Moving object. In the exceptional case of the ImageToSpatial object
> registration, the SpatialObject is considered to be the moving
> element even though it is the source of points to be mapped.
> In this context the transform that is being optimized here is the
> one that maps points from the SpatialObject into the Image.
>
> This choice was mostly driven by the fact that applications using
> SpatialObjects has a large visualization component and tend to use
> the transform resulting from the registration as the transfrom to
> pass to vtkActors that will display the Spatial Object representation
> in the appropriate location of space on top of the image.
>
>
>
> In general it is more eficient to chose the "Moving" object as
> the one that can easily be sampled by points, and the "Fixed"
> object as the one that can be used as a source of points.
>
>
>   Please let us know if you have further questions.
>
>
>     Thanks
>
>
>       Luis
>
>
>
> ------------------------
> Karthik Krishnan wrote:
>> Looks like a bug to me too.
>> The example seems to swap index and physical points and won't work  
>> for images with spacing not equal to 1. (for instance if you say  
>> imageFilter->SetSpacing(..)) and it seems to swap the notion of  
>> Fixed and moving image.
>> Bradley Lowekamp wrote:
>>> Hello all,
>>>
>>> I am confused by the transformations going on in the example  
>>> ModelToImageRegistration.cxx with regards to the custom Metric.  
>>> Here are some highlights of the code:
>>>
>>> In SetMovingSpacialObject():
>>>       ...
>>>       typedef itk::ImageRegionConstIteratorWithIndex<TFixedImage>  
>>> myIteratorType;
>>>       myIteratorType it(this->m_FixedImage,this->m_FixedImage- 
>>> >GetBufferedRegion());
>>>       itk::Point<double,2> point;
>>>       while(!it.IsAtEnd())
>>>         {
>>>         for(unsigned int i=0;i<Self::ObjectDimension;i++)
>>>           {
>>>           point[i]=it.GetIndex()[i];
>>>           }
>>>
>>>         if(this->m_MovingSpatialObject->IsInside(point,99999))
>>>           {
>>>           m_PointList.push_back(point);
>>>           }
>>>         ++it;
>>> ....
>>> In GetValue():
>>>        ...
>>>        PointListType::const_iterator it = m_PointList.begin();
>>>        ...
>>>        while(it != m_PointList.end())
>>>         {
>>>         PointType transformedPoint = this->m_Transform- 
>>> >TransformPoint(*it);
>>>         this->m_FixedImage->TransformPhysicalPointToIndex 
>>> (transformedPoint,index);
>>>         ...
>>>
>>> I have been reading and rereading the relevant sections in the  
>>> ITK software guide book, especially the "Direction of the  
>>> Transform Mapping". I believe I understand the usage and  
>>> direction of the transformations is the registration process.  
>>> Perhaps this is a poor example, which takes some short cuts. But  
>>> this is my understanding of this code:
>>>
>>> The created m_PointList contains a points in "image grid" space.  
>>> (Slightly ambiguous as to which since the two are already aligned).
>>>
>>> Then the m_Transform is applied. This transform maps points from  
>>> physical space of the fixed image to the physical space of the  
>>> moving model according to the definition of said transform. (We  
>>> can overlook the lack of image grid to physical space  
>>> transformation since it is the identity in both cases.) So  
>>> "transformedPoint" ought to be in the physical space of the  
>>> moving model.
>>>
>>> Last the fixed image's physical to image grid index transform is  
>>> applied. So "transformedPoint" must be in fixed image's physical  
>>> space.
>>>
>>> So this is a contradiction, and I am confused. What am I missing  
>>> here?
>>>
>>> Sorry for the repost. I am hoping that this one doesn't get  
>>> hijacked too :)
>>>
>>> Thanks,
>>> Brad
>>>
>>>
>>>
>>> ========================================================
>>>
>>> Bradley Lowekamp Management Systems Designers Contractor for
>>>
>>> Office of High Performance Computing and Communications
>>>
>>> National Library of Medicine
>>> blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> ----
>>>
>>> _______________________________________________
>>> Insight-users mailing list
>>> Insight-users at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users