[Insight-users] Re: rigid 3d Registration question (still a newbie, feels like )

Luis Ibanez luis.ibanez at kitware.com
Tue Jul 20 17:39:10 EDT 2004


Hi Robert

ITK does not have an explicit representation for
units of length.

In practice, your registration assumes that the
units of length are the ones in which you are
reporting the pixel spacing of your images.

If you have images from microscopy and your pixel
spacing is 5 microns, then you want to create
scales that will render the numerical values of
rotations (measured in radians) to be similar
to the translations (measured in microns).


PLEASE

    READ THE CHAPTER ON IMAGE REGISTRATION
         FROM THE SOFTWARE GUIDE.

   http://www.itk.org/ItkSoftwareGuide.pdf

Many of the issues you are asking about are
described in detail on that chapter. E.g. the
fact that the fixed and moving images may
have different pixel spacings, origins and
number of pixels. The criteria for computing
the scaling factors are also described in
that chapter.



    Regards,


      Luis



-------------------------
Atwood, Robert C wrote:

> Thanks,Luis
>  I am beginning to understand --  it should proportional to the ratio of
> the expected translation to the expected rotation (in radians) ?  ie if
> my voxels (as is more likey the case) are 1 micron , I still want to use
> 1/1732  not 1/(10 * 10^-3 * sqrt(3)) =  57, right! 
> 
> However , do the units get ratioed internally in the transformer and
> passed to the optimizer? Ie.  if the spacing is 5 microns, and I use
> microns as the base unit, I should use 1/(10*500*sqrt(3)) = 1/8660 to
> achieve exactly the same effect ? 
> 
> ie if I use spacing = {5,5,5} and import my data by:
> 
>    importFilter->SetSpacing( spacing ); 
> 
> surrounded by similar code as in the import filter example in the
> software guide, then the scaling should be different that if spacing =
> {1,1,1} for the same datafile?
> 
> Also , supposing that the two images are of different, but known, scales
> which may be set as above, does the transformer in the optimizer use
> this when transforming, or must the images be rescaled beforehand? 
> 
> Thanks again
> 
> Robert
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez at kitware.com] 
> Sent: 20 July 2004 21:59
> To: Atwood, Robert C
> Cc: insight-users at itk.org
> Subject: Re: rigid 3d Registration question (still a newbie, feels like
> )
> 
> 
> 
> Robert,
> 
> 
> The recommendation for the scaling of translation parameters versus
> rotation parameter is to use a factor proportional to the diagonal
> length of the image.
> 
> For your case the, you have 100 pixels with 1 mm / pixel, therefore the
> physical extent of your image is
> 
>         100mm  X  100mm  X 100mm
> 
> The diagonal the image bounding box is
> 
>           sqrt(3) * 100 mm
> 
> which is about
> 
>               173.2
> 
> and extra factor of 10X is usually useful, so you should probably try a
> factor of
> 
> 
>      1.0 / ( 10 x 173.2 )  =  1.0 / 1732.0
> 
> You could use this same factor for the three components
> of the translation or you could estimate independent
> factor for each component in the way it is done in the
> VolView plugin.
> 
> Note that this factors are not expected to be computed precisely. Their
> purpose is simply to bring the rotational and translational parameters
> to a similar numerical scale.
> 
> By default, they are quite disproportionate since rotation
> are in radians, therefore in a range about -1:1, while translations are
> in millimeters, and for an image of 100mm you probably can expect
> translations as large as 50mm.
> 
> 
> The difference between Offset and Translation is relevant
> only for the "Centered" transforms.  For example, for the
> case of the CenteredAffineTransform the full transformation
> is given by
> 
> 
>            P' = R x ( P - C ) + ( C + T )
> 
> where
> 
>    C  is the Center of rotation
>    P  is the point to be transformed
>    P' is the transformed point
>    T  is the translation.
> 
> 
> This equation can be rewritten as
> 
>         P' =   R x P     +     [ C + T - R X C ]
> 
> and we call Offset the expression
> 
>       Offset = [ C + T - R X C ]
> 
> so the transformation is
> 
>        P'  =  R x P  + Offset
> 
> So, the relationship between Translation and offset is
> 
> 
>       Offset =  [ I - R ] x C    +    T
> 
> 
> In practice, if you are using Centered transform, you should not care
> about the Offset. Instead make sure that you provide appropriate values
> for the Center of Rotation and the Translation. The Offset is computed
> from these two and the rotation matrix.
> 
> 
> 
> Note that the step length is also a critical value.
> There is no magic recipe for selecting one. You probably
> want to start experimenting with a small value (e.g. 0.01)
> and plot the metric evaluations during the registration process.  If you
> observe that the metric values are fairly monotonic, that means that you
> can safely increment the step length. Such an increment has the
> advantage of reducing the time required to reach an extrema of the cost
> function
> (the image metric in this case).   You could restart the
> registration with larger values of the step length, as long
> as you don't observe a noisy and/or erratic behavior on the Metric
> values.
> 
> Step length issues are discussed in the course material
> from the "Image Registration Techniques" course at RPI.
> 
>    http://www.cs.rpi.edu/courses/spring04/imagereg/
> 
> for example in lecture 9:
> 
> http://www.cs.rpi.edu/courses/spring04/imagereg/lecture09.ppt
> 
> 
> Regards,
> 
> 
> 
>      Luis
> 
> 
> 
> -----------------------
> Atwood, Robert C wrote:
> 
> 
>>Dear Luis and the list:
>>As a start at trying my 3d registration, I have looked into example 
>>ImageRegistrationExample8 and the vvITKImageRegistration plugin. I 
>>have found that for my test examples, the volview plugin works better,
> 
> 
>>so I was looking into the differences in implementation. I already 
>>applied the
>>
>>itkNormalizedCorrelationImageToImageMetric
>>
>>instead of the one originally in Example8.
>>
>> 
>>
>>In the following lines, the scales and StepLenght parameters are set, 
>>how did you decide upon these values ?
>>If I have a volume where each voxel is 1 unit and the entire volume is
>>100x100x100, is the value of optimizerScales[3] equal to 1/1000 or
> 
> 1/10
> 
>>? 
>>
>>Also, I am unclear about what the difference between the 'Offset' as 
>>in
>>transform->GetOffset() and the 'Translation' as in versor rigid 3d
>>transform parameters [3][4][5] ?
>>
>>
>>Thanks!
>>Robert
>>
>>
>>
>>in vvITKImageRegistration.cxx
>>    316   optimizerScales[0] = 1.0;
>>    317   optimizerScales[1] = 1.0;
>>    318   optimizerScales[2] = 1.0;
>>    319   optimizerScales[3] = 1.0/
>>    320 
>>(10.0*info->InputVolumeSpacing[0]*info->InputVolumeDimensions[0]);
>>    321   optimizerScales[4] = 1.0/
>>    322 
>>(10.0*info->InputVolumeSpacing[1]*info->InputVolumeDimensions[1]);
>>    323   optimizerScales[5] = 1.0/
>>    324 
>>(10.0*info->InputVolumeSpacing[2]*info->InputVolumeDimensions[2]);
>>    325   m_Optimizer->SetScales(optimizerScales);
>>    326
>>    327   m_Optimizer->SetMaximumStepLength(1.0);
>>    328   m_Optimizer->SetMinimumStepLength(0.01);
>>    329
>>
>>
>> In ImageRegistration8.cxx some different values are used:
>>
>>
>>     332   typedef OptimizerType::ScalesType
> 
> OptimizerScalesType;
> 
>>    333   OptimizerScalesType optimizerScales(
>>transform->GetNumberOfParameters()         );
>>    334   const double translationScale = 1.0 / 1000.0;
>>    335
>>    336   optimizerScales[0] = 1.0;
>>    337   optimizerScales[1] = 1.0;
>>    338   optimizerScales[2] = 1.0;
>>    339   optimizerScales[3] = translationScale;
>>    340   optimizerScales[4] = translationScale;
>>    341   optimizerScales[5] = translationScale;
>>    342
>>    343   optimizer->SetScales( optimizerScales );
>>    344
>>    345   optimizer->SetMaximumStepLength( 1.000  );
>>    346   optimizer->SetMinimumStepLength( 0.001 );
>>    347
>>
>>
> 
> 
> 
> 
> 





More information about the Insight-users mailing list