[Insight-users] Transformation in ModelToImageRegistration example

Luis Ibanez luis.ibanez at kitware.com
Mon Apr 24 21:24:14 EDT 2006


Hi Bradley,

In order to address the need for more examples on the front of
Model to Image registration, a new example has been committed
to the CVS repository.

You will find it under:


         Insight/
             Examples/
                  Registration/
                     ModelToImageRegistration2.cxx


This example follows the approach of rasterizing a SpatialObject,
generate from its mask a distance function in the form of a narrow
band, and then generate a point set out of that narrow band.

The resulting collection of points (with pixel values) is the model
to be registered agains the moving image.  The PointSetToImage
registration class is used for the final registration.

The example is illustrated for fitting a BoxSpatial object to the
image

           Insight/Testing/Data/Input/cake_easy.png.

some parameter finetuning would be needed for applying it to
more realistic images.


If you have a chance, please give it a try to this example, and
let us know if you find any problems,



    Thanks


       Luis



------------------------
Bradley Lowekamp wrote:
> 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
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 
> 



More information about the Insight-users mailing list