Surgical coordinate changes

From IGSTK

Jump to: navigation, search

The DesignChallenges page provides an in-depth discussion of some changes that are required to the way that coordinates are handled by IGSTK. This page describes the changes that must be done to specific IGSTK components, in particular to the Tracker and SpatialObject classes.

Contents

Definitions

Definitions and terminology are of crucial importance. Unless everyone on the project uses the same names to refer to the same ideas, efficient communication will be impossible. Here are the coordinate frames-of-reference that will be used in IGSTK:

Tracker Coordinate Frames

  1. Global Frame (gf) Coordinates(gfc) or Global Coordinates. Raw coordinates as returned directly from the actual tracking system, before applying the reference or applying any tool calibration corrections. These coordinates are useful for verifying that all tools are within range of the tracking system, but they are not useful for the actual surgical guidance. For that, Reference Frame coordinates should be used.
  2. Reference Frame (rf) Coordinates(rfc) or Reference Coordinates. Coordinates with respect to the Tracker's reference. These are the coordinates reported by the Tracker component, and they can be generically referred to as "Tracker Coordinates".
  3. Calibrated Tool Frame (ctf) Coordinates (ctfc) or Calibrated Coordinates. This is the coordinate system relative to the tool itself, with (0,0,0) at the tool tip and with the (x,y,z) axes aligned with the tool. Within this frame of reference, the tool is stationary by definition. This frame of reference is often used for visualization, where the tool tip is at the center of the screen and the patient anatomy moves relative to the screen.
  4. Tool Uncalibrated Frame (utf) Coordinates (utfc) or Uncalibrated Coordinates. This is a frame of reference that is stationary with respect to the tool, but the orientation and origin of the frame are not calibrated with respect to the tool. This coordinate system should not be exposed through the IGSTK public interface, the Tool-Tip Frame is the one that should always be used. A tool calibration must be performed so that the IGSTK TrackerTool objects can convert utf coordinates to ctf coordinates.

When the Tracker component reports a Transform for a tool, it is reporting the coordinate transformation rf_TT_tt. This is the transformation between the tool tip frame and the reference frame, and it describes the position of the tool tip, and the orientation of the tool, with respect to the reference.

Do you mean the TrackerTool is reporting here David, the calibration will be in the tool from now Frankl. Yes, the tool will store the calibration so that it can report ctf coordinates.

Data Coordinate Frames

  1. Volume Frame (vf): This is the coordinate system of the image data of interest, whether it be CT, MR, Ultrasound, etc. The volume coordinates are aligned with the volume. Each volume should have a Volume Transform (VT) that can be used to convert from Tracker Reference Frame Coordinates to Volume Frame Coordinates.

Changes to IGSTK Components

In order to change the way IGSTK handles coordinate systems, the Tracker and SpatialObject classes will have to be changed. Some changes might also be needed for the Representations.

Changes to the Tracker component

In the current Tracker design, the tracker reports tool positions directly in the Volume Frame. This will change! In the next revision of the Tracker design, the Tracker will report tool positions in the Reference Frame.

The Tracker::SetPatientTransform() method will be removed.

Furthermore, the Tracker::SetToolCalibrationTransform() with be removed from the Tracker object, and put into the TrackerTool object instead.

== Changes to the SpatialObject class =+

The spatial objects receive transforms from the tracker tools, and will be responsible for applying any volume transforms that are necessary. The volume transforms will convert from tracker coordinates to volume coordinates. Can someone with more experience with spatial objects expand on this?

  • Current implementation (added by Julien Jomier)
    • IGSTK::SpatialObjects are currently using only the ObjectToWorldTransform from the ITK::SpatialObject class.
    • ITK::SpatialObjects can store more transforms:
  1. IndexToObject: Defined by origin and spacing of the image
  2. ObjectToNode: Internal Transform not applied to children of the object
  3. NodeToParentNode: Transform defining the relationship to the parent object
  4. ObjectToWorld = SUM(NodeToParentNodeTransform)+ObjectToNode
  • If necessary IGSTK can use the transforms above. However, it might be easier to manage the history, etc.. directly in the IGSTK::SpatialObject class

ImageSpatialObjects need to store two things: Frankl

  1. The current Image Transform (IT): if_IT_rf (P_if = if_IT_rf*P_rf)
  2. The history/log of all updates that lead up to the current IT (especially important for pre.op.data, not that important for intra.op.data)
  • Scenario
    • Pre.op.:
      • All volumes (IT) refers to "DICOM space" after read into the system
      • After a V2V reg. is run between all pre.op. volumes, all volumes refers to (IT) the DICOM space of the master volume (=patient space)
    • Intra. op.:
      • After a Pas. reg. is run all volumes refers to tracker referance space (rf)
      • After a pre(MR)-intra(US) V2V reg. is run all pre. op must be updated
    • Post. op.:

Proposed Class Modifications

(by Luis, Andinet and Julien)

  • Creating a FrameObject ( The functionality of this class will be abstracting a coordinate system )
    • new class ReferenceFrameObject derives from AxesObject (DONE)
    • new class WorldReferenceFrameObject derives from ReferenceFrameObject (with the SetTransform() private since you cannot set the main transform of the WorldReferenceFrame) (DONE)
    • All ReferenceFrameObject will have a transform associated with them except the WorldReferenceFrame. (DONE)
  • In igstk::Transform ( Introduce the notion of coordinate system into IGSTK transform similar to validity time and error measure)
    • SetReferenceFrameObject() method will be added to specify a transform with respect to any coordinate system
    • By default (if no reference frame is specified), the transform is assumed with respect to the WorldReferenceFrameObject.
    • IT TURNED OUT THAT THIS WAS UNNECESSARY. Given that now, all SpatialObject will have a parent, that parent defines the coordinate reference system. Each SpatialObject will have a transform relative to that parent coordinate system. Therefore the Transform themselves do not need to refer to a coordinate system.
  • In the igstk::SpatialObject
    • Child-parent hierarchy will be established similar to ITK spatial object
    • SetTransform() method will set ObjectToParent transform instead of ObjectToWorldTransform.
    • If ReferenceFrameObject is set in the transform, then the ObjectToParent transform will be computed using the ReferenceFrameObject and the already created spatialobject hierarchy transform information.


  • Additional stuff:
    • It would be nice to make the AxesRepresentationObject available to any SpatialObjects (for debugging purposes especially) by creating a new representation class
    • Implement a test program:
  1. Create a WorldReferenceFrameObject
  2. Create a Tracker which internally has an ivar of type ReferenceFrameObject (DONE)
  3. Create a TracketTool which internally has an ivar of type ReferenceFrameObject which is a child of TrackerReferenceFrameObject. (DONE)
Retrieved from "http://public.kitware.com/IGSTKWIKI/index.php/Surgical_coordinate_changes"
Personal tools
TOOLBOX
LANGUAGES