Talk:Surgical coordinate changes

From IGSTK

Tracker Coordinate Frames

• Support Tracker Coordinate Frames statement.
• Track class may need to add interface to read Reference Frame (rf) transform. Because sometimes we need to map some points to the Reference Frame(rf). However, now once you Set Reference to Track class. All the tools' transform will respect to the Reference Frame. It is impossible to get the Reference transform again.
• The way I use is to Add GetToolRawTransform() function to get the Reference transform.

Data Coordinate Frames

• The difference between Volume Frame (v) and Patient Frame (p) is not too obvious. Both of them seems like based on image.
• Just recommend maybe use Track Frame(respect to Reference Frame) substitute the Patient Frame will be better.
• Patient transform is the transform between The Track Frame and Volume Frame

Changes to the Tracker component

• Support to remove the Tracker::SetPatientTransform() form Tracker class.
• However the point is where should we put it? I suggest we should follow ITK's way to build one Registration Base Class(can include various registration algorithm). This class is special used to identify the Patient transform which can map the Tracker Frame to Patient Frame. This new feature will make registration method more flexible. My next step (Item 4) to implement Multi-DOFs dynamic reference will require it.

Contents 1 Proposed Class Modifications 1.1 Graphical Description 1.1.1 First Case 1.1.2 Second Case 1.1.3 Third Case

Proposed Class Modifications

Questions from Patrick

1. Why do we inherite ReferenceFrameObject from AxesObject? Most of the time, we just need it to store a transform, don't need have any geometric representation
   • This is mainly for visualization purpose (debugging). We are taking advantage of the geometrical representation framework in the spatial objects to be able to visualize the reference system along with the rest of the aggregated scene. This functionality is basically similar to the feature available in, for example, Paraview or other visualization applications (VolView) to display the selected coordinate system orientation Andinet 09:58, 17 July 2007 (EDT)
2. It will be nice to have a figure to demonstrate the classes collaboration
3. I am not sure how the transform will be updated in the hierarchical tree
   • 
   • The WorldFrameObject is similar to the concept of the itkSceneSpatialObject Aylward 12:32pm, 17 July 2007 (EDT)
4. It's not very clear to me why we need a special ReferenceFrameObject, while the SpatialObject is capable of performing all the tasks needed
   • This is related to your first question. Again the main motivation is visualization Andinet 11:46, 17 July 2007 (EDT)
5. How do we set the ReferenceFrameObject at places like Tracker where transform originates, and how do we change the reference frame after registration process, how do we make sure the transform composition is done in the same reference frame?
   • A ReferenecFrameObject will be attached to the tracker reference coordinate. Hence, all the transforms that originate from the tracker will be with respect to that the ReferenceFrameObject (similar to igstkTA in the figure). When the spatial object gets connected to the rest of the hierarchy with the transform reported by the tracker, the transform composition will be computed as explained in the figure. Andinet 11:50, 17 July 2007 (EDT)

• Thank you for proposing these changes (SpatialObject, etc). Frank
• It would be wrong to say that I understand the proposed changes 100%.
• Making it hard to fully understand the practical consequences for using such a coordinate framework (in my head images (and other spatial objects), coordinate systems, transforms and the algorithms are starting to float together.
• In order to make this clearer and ease the communication would it be possible to "apply" the proposed framework on the following concrete scenario, i.e. how will the spatial objects look inside (contained transforms relation to coordinate systems), what transforms are created and how are they applied:
  • Pre.Op:
    • Image data available: one CT and one MR, from both images an anatomical structure have been crated and given a triangle representation (segmentation performed in external application (one of the things that can be done outside the IGS app. and saved in seperate files)
    • Read in CT and MR, as well as the two surface models (e.g. two image spatial obj.created: CT-ISO and MR-ISO, their Image/Volume transform (IT) contains .... relative to ... coordinate system, etc.)
    • Register CT (and consequently SurfObjCT) to MR
  • Intra.Op:
    • Register MR (and consequently CT / SurfObjCT) to (Patient) reference system (PRS) of the tracker.
    • Acquire and reconstruct US1 (i.e. acquire a ultrasound volume in the PRF of the tracker)
    • Update MR (and consequently CT) using US1 (for the purpose of brain shift compensation for example).
    • Acquire and reconstruct US2.
    • Update MR (and consequently CT) using US2
  • Pre.Op:
    • Image data available: one MR-post
    • Register MR (and consequently CT) as well as US2 to MR-post

To illustrate how we think, I have copied the following sentences from something I have written before: Basically, registration is needed in the following steps of the patient treatment process:

• To register all available pre-operative image information to a common frame of reference (e.g. the DICOM coordinate system of the master volume) for optimal pre-operative planning and surgical simulation (PreOpReg)
• To register all the pre-operative data (i.e. the master volume) to the patient reference frame / tracking system for intra-operative planning, navigation and control based on pre-operative image data (PasReg).
• To update the position and orientation of all pre-operative data (i.e. the master volume) to match the current patient anatomy using intra-operative image information if available (e.g. ultrasound or MR) to compensating for things like respiration, pulsation and surgical manipulation in order to make high quality images acquired before surgery (e.g. fMRI and DTI) useful also during the operation (IntraOpReg).
• To register all pre- and (usually the last) intra-operative data acquired, to post-operative image data, if available, for surgical control and evaluation after the intervention (PostOpReg).

Graphical Description

First Case

Second Case

Third Case