[Insight-users] Re: Problem with ImageRegistration8
Luis Ibanez
luis.ibanez at kitware.com
Wed Jul 21 14:36:18 EDT 2004
Hi Robert,
Thanks for pointing this out.
You are right, the Center of the original
transform must be passed to the newly
constructed transform.
We just commited a fix in CVS according
to your suggestion.
Please let us know if you find any other
problem.
Thanks
Luis
------------------------
Atwood, Robert C wrote:
> After spending some time , (with the proverbial supervisor wondering all
> the while ) trying to understand why my modified version of
> ImageRegistration8 did not give as good results as the volview plugin,
> even though I pretty much implemented the same procedure (except you can
> input the starting and ending resolution step),
> I discovered that the diff and result files are actually incorrect.
>
> Fiddling with the step/scale was a bit of a red herring! But good to
> understand better anyways.
>
> I believe that this is because the "TransformType::Pointer transform "
> used for the registration is initialized with the
> CenteredTransformInitializer, whereas the "TransformType::Pointer
> finalTransform" used to rotate the moving image back into the fixed
> image, is not. So the rotation is applied about the origin instead of
> the center as it is during registration.
>
> The plugin contains the line:
> 378 finalTransform->SetCenter(m_Transform->GetCenter());
>
> which should be included after 526 in ImageRegistration8.cxx:
>
> 526 finalTransform->SetParameters( finalParameters );
> 527 finalTransform->SetCenter(transform->GetCenter());
>
>
> thus saving hours of frustration. :-0
>
>
> Robert
>
>
>
>
>
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
> Sent: 20 July 2004 22:39
> To: Atwood, Robert C
> Cc: insight-users at itk.org
> Subject: Re: rigid 3d Registration question (still a newbie, feels like
> )
>
>
>
> 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