[Insight-users] Intensity-based 2D-3D registration problems

[Jian Wu]

Hi, Damiaan,
There should be no problem with line 1564. This reason for corrections I 
made from line 731-738 is that the coordinate of the point 
"m_CurrentRayPositionInMM" should be w.r.t. the center of rotation instead 
of that w.r.t. the origin. Because of this mistake, the DRRs generated using 
old codes were off-centered. This can be verified by running the application 
using a synthetic 3D cube image generated in the orginal code:

DigitallyReconstructedRadiograph1.cxx

with the input parameters as

-v -res 2 2 -o CubeDRR.img

After above corrections you should get a DRR with the cube located in the 
center (It should be like that for given geometry.). The screen output would 
be:

Output image: CubeDRR.img

Input ImageRegion (0129FD8C)
  Dimension: 3
  Index: [0, 0, 0]
  Size: [61, 61, 61]
  Resolution: [3, 3, 3]
  Origin: [0, 0, 0]

Image size: 61, 61, 61
   resolution: 3, 3, 3
   origin: 91.5, 91.5, 91.5
   center: 91.5, 91.5, 91.5
Transform: CenteredEuler3DTransform (0178BA48)
  RTTI typeinfo:   class itk::CenteredEuler3DTransform<double>
  Reference Count: 2
  Modified Time: 26
  Debug: Off
  Observers:
    none
  Matrix:
    1 0 0
    0 1 0
    0 0 1
  Offset: [0, 0, 0]
  Center: [91.5, 91.5, 91.5]
  Translation: [0, 0, 0]
  Inverse:
    1 0 0
    0 1 0
    0 0 1
  Singular: 0
  Euler's angles: AngleX=0 AngleY=0 AngleZ=0
  m_ComputeZYX = 1

Focal Point: 91.5, 91.5, -108.5
RayCastInterpolateImageFunction (0178BEE0)
  RTTI typeinfo:   class itk::RayCastInterpolateImageFunction<class 
itk::Image<short,3>,double>
  Reference Count: 1
  Modified Time: 29
  Debug: Off
  Observers:
    none
  InputImage: 00000000
  StartIndex: [0, 0, 0]
  EndIndex: [0, 0, 0]
  StartContinuousIndex: [0, 0, 0]
  EndContinuousIndex: [0, 0, 0]
  Threshold: 0
  FocalPoint: [91.5, 91.5, -108.5]
  Transform: 0178BA48
  Interpolator: 00000000
Output image size: 501, 501, 1
Output image spacing: 2, 2, 1
Output image origin: -408.5, -408.5, 291.5
Writing image: CubeDRR.img

Please try it and let me know if you can get the identical results.

Jian Wu


>From: "D.F.Habets" <dhabets at imaging.robarts.ca>
>To: Jian Wu <eewujian at hotmail.com>
>Subject: Re: [Insight-users] Intensity-based 2D-3D registration problems
>Date: Mon, 27 Mar 2006 14:32:39 -0500 (EST)
>
>Thanks for the reply Jian.
>
>    I haven't made much progress with that function yet, but I have looked 
>at itkRayCastInterpolateImageFunction more critically and I have a 
>question:
>
>>>>=======================================================================
>>>>File Name: itkRayCastInterpolateImageFunction.txx
>>>>Revision: 1.18
>>>>Line Number: 731-738
>>>>Original:
>>>>m_CurrentRayPositionInMM[0] =
>>>>   RayPosn[0] + 0.5*m_VoxelDimensionInX*(double)m_NumberOfVoxelsInX;
>>>>
>>>>m_CurrentRayPositionInMM[1] =
>>>>   RayPosn[1] + 0.5*m_VoxelDimensionInY*(double)m_NumberOfVoxelsInY;
>>>>
>>>>m_CurrentRayPositionInMM[2] =
>>>>RayPosn[2] + 0.5*m_VoxelDimensionInZ*(double)m_NumberOfVoxelsInZ;
>>>>Replaced by:
>>>>m_CurrentRayPositionInMM[0] = RayPosn[0];
>>>>
>>>>m_CurrentRayPositionInMM[1] = RayPosn[1];
>>>>
>>>>m_CurrentRayPositionInMM[2] = RayPosn[2];
>>>>=======================================================================
>
>
>What is the rationale for the above change? I think they aim to center the 
>volume around the origin, so that might be right.
>
>However, I noticed something I found surprising:
>
>line 1564:
>
>OutputPointType transformedFocalPoint
>     = m_Transform->TransformPoint( m_FocalPoint );
>
>   DirectionType direction = transformedFocalPoint - point;
>
>---
>
>I'm not sure why they're changing the focal point according to the 
>rotation/translation. I would have expected the focal point to be fixed?
>
>This causes the following (to me, counterintuitive) situation:
>
>- T = 0,0,100, R = 0,0,90
>
>Shows the correct image, rotated over Z and translated over Z
>
>- T = 0,0,100, R = 0,90,90
>
>Results in the correct rotation, however, the translation appears as if 
>it's done over X. This is because the focal point was rotated, yet the 
>translation follows the world coordinates.
>
>Not sure if that makes sense? Any ideas why that would have been done like 
>that? By applying the R and then T to the focal spot, the T are no longer 
>independent of the rotations and I would have expected that...
>
>Thanks,
>Damiaan