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

[Luis Ibanez]

Hi mastersofwar,


        "Glimpsing at the Source, leaves no doubt".



A) Yes, the focal lenght is applied along the Z direction:

    See:

    IntensityBased2D3DRegistration.cxx:721:

         origin2D[2] = origin3D[2] + focalLength/2.;

    IntensityBased2D3DRegistration.cxx:923:

         focalPoint[2] = origin3D[2] - focalLength/2.;




B) The Transform is specified in such a way that points
    from the coordinate system of the 2D plane are converted
    to the 3D coordinate system of the 3D moving image.



C) Movement is relative indeed. I'm not aware of specific
    implementations in which the source of the projection is
    rotated, but don't see a reason why this couldn't be done
    that way.


D) Restricting the amount of rotation to what your physical
    hardware (C-Arm) can actually support, makes a lot of sense.

    Note however that this still doesn't account for the initial
    position of the patient in the table. The C-Arm may be restricted
    to 20 degrees rotations, but the patient in the table can still
    be rotated by (almost) any angle.


I'll strongly recommend to have a big diagram of the coordinate
systems of the table, the C-Arm and the patient drawn in a piece
of paper beside the screen of your computer.

See for example:
http://www.itk.org/Wiki/Proposals:Orientation#DICOM_LPS_Orientation_-_Lower_Limb_Graphical_Example
http://www.itk.org/Wiki/Proposals:Orientation#DICOM_LPS_Orientation_-_Full_Body_Graphical_Example
http://www.itk.org/Wiki/Proposals:Orientation#DICOM_LPS_Differences_in_Visualization_presented_to_Radiologist_and_NeuroSurgeons





    Regards,



       Luis


------------------------------
mastersofwar at yahoo.com wrote:
> Dear Luis,
> 
> I need confirmation from you regarding the implementation of the 2D/3D registration code before I proceed with simualtion studies.
> 
> As far as I can determine, the focal length is along the Z-axis. The 6 D.O.F are with respect to the volume. 
> 
> Since I am dealing with ultrasound volume, I can perturb the three translation and 3 rotations. 
> 
> It seems to me that if i apply a rpotation in the x direction (rx value), its the same as rotation the entire source for the projection. Has this been modeled this way?  
> 
> In essence, what i am trying to say is that since I have a C-arm with a limited amount of rotation, say 20 degrees cone angle, it suffices to apply rotations of up to 20 degrees to the rx parameter in the 2D/3D registration code you provide?
> 
> any assistance in this is appreciated
> 
> 
> 
> 
> 
> Luis Ibanez wrote:
> 
>>
>>Hi Pafal,
>>
>>
>>1) The 3D/2D registration is currently performed only between
>>    one 3D dataset and one 2D dataset.
>>
>>    If you take your 3 independent 2D datasets, you could compute
>>    the pose of the 3D dataset with respect to each individual
>>    2D dataset.
>>
>>
>>2) Yes you can initialize the transformation to identity,
>>    but that is not necessarily a good idea, specially if
>>    the actual final transform is too far from identity.
>>
>>    That is, you should rather initialize the transform with
>>    a value that is close to the real pose.
>>
>>
>>3) This example has several independent command line executables.
>>    You don't have to run them in sequence. What the readme file
>>    is describing, is a procedure for performing a self-validation
>>    experiment. That is, you take a 3D image, produce its DRR as
>>    a 2D image, and then feed that 2D image in the 2D/3D registration,
>>    and should get as outcome the same transform parameters that you
>>    used during the DRR generation.
>>
>>    In a real problem, you would skip the DRR independent generation.
>>
>>
>>4) The commands shown in the README.txt file are "almost" copy/pasted
>>    from real commands as typed in a Linux machine.  You could convert
>>    them to a batch file (for your platform) with a bit of retouching.
>>
>>
>>
>>   Regards,
>>
>>
>>      Luis
>>
>>
>>
>>---------------
>>pafal wrote:
>>
>>>I have searched the forums for IntensityBased2D3DRegistration and as of
>>>yet I
>>>have not come with a concrete response to my question.
>>>
>>>By sifting through the IntensityBased2D3DRegistration.cxx code in great
>>>detail, I gather the pipeline is as follows:
>>>
>>>a) read 3D volume
>>>b) raycast the 3D volume into a DRR image
>>>c) similarity metric between DRR image and user input 2D image
>>>d) optimizwe transforms.
>>>
>>>
>>>Questions:
>>>
>>>1- if I have three 2D images, can I use these images to estimate the pose
>>>(6
>>>d.o.f) of the volume, or is this .cxx file only valid for a single 2D
>>>image
>>>to 3D volume registration?
>>>
>>>2- Is it possible initializing the transforms to identity, just like in
>>>the
>>>3D/3D registration examples and hope that the algorithm will optimize the
>>>transforms close to their true values?
>>>
>>>3- I'm confused with the Readme.txt file. The pipeline is to first
>>>execute
>>>GenerateProjection by projecting brainweb165a10f17.mha and saving into
>>>projection.mhd. 
>>>
>>>Then we take  projection.mhd  and compare it with our own 2D image by
>>>calling IntensityBased2D3DRegistration??
>>>
>>>
>>>4- Are the command lines in Readme.txt copy pasted into batch files?
>>>
>>>
>>>
>>>any insight on this would be monumental for me.
>>>
>>>thank you 
>>>
>>>regards
>>>
>>>P.
>>
>>_______________________________________________
>>Insight-users mailing list
>>Insight-users at itk.org
>>http://www.itk.org/mailman/listinfo/insight-users
>>
>>
> 
> Quoted from: 
> http://www.nabble.com/2D-3D-Intensity-based-registration-tp20015713p20245896.html
> 
>