CustusX  15.4.0-beta
An IGT application
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
Coordinate Systems

Overview

This page describes the CustusX way of handling coordinate systems. A basic knowledge of linear algebra and geometry is assumed. A coordinate system can also be called a space or frame. Space will be preferred here.

A space always has an ID. It is defined in terms of one other space, called its parent space. The origin and coordinate axes of the space is defined in the parent space. The origin and coordinate axes are concatenated into a 4x4 affine matrix. Spaces that are connected through a chain of references are connected. Otherwise they are unconnected and need a registration in order to be connected.

Notation

A point or vector p in space q are denoted

p_q

Space q has a parent space r. The affine matrix, or transform, M relating the two spaces are denoted

q_M_r (sometimes simply qMr)

q_M_r is defined such that a point p_r in the parent space premultiplied with q_M_r yields the same point p_q represented in space q:

p_q = q_M_r * p_r

The multiplication here is done using homogenous coordinates, where a point is [x,y,z,1] and a vector is [x,y,z,0].

Implementation

Points and vectors are implemented using cx::Vector3D. cx::Vector3D only contains [x,y,z], thus it is context-dependent if it is a vector or point, and also which space it is defined in.

Transformations (the matrix qMr) are implemented using cx::Transform3D. The internal representation is a 4x4 matrix. cx::Transform3D contains helper methods vec(cx::Vector3D) and coord(cx::Vector3D) that transforms the vector or point, respectively.

The class CoordinateSystemHelpers provides some nice utility functions.

Specific Spaces

ssc_coordinate_systems.png
Major Coordinate systems

The figure and table shows the most important spaces in CustusX. Some spaces have a subscript; This means that there are several of them.

Name ID Description
reference r The basic space that connects everything. Has no parent space.
patient reference pr A physical space, usually the reference tool. When rMpr is defined, the system is said to be patient registered, meaning image spaces are connected to the navigation tools.
data i d_i Each Data (Image or Mesh or other) has an associated space d_i. In simple cases, it has the reference space as its parent space, but it might also have another data space as parent space. This gives the ability to describe a tree of data spaces. The transform rMd_i is always stored in Data, regardless of the value of the parent space.
slice k s_k During slicing (for display in a 2D View) a space s is defined. The xy-plane of this space is the slice plane. It is defined with r as the parent space.
tool j t_j Each Tool has a space t that defines its position. The origin is usually the tool tip, this may vary for ultrasound probes.
tool offset j to_j Tools can have a virtual offset along its local z axis. The space thus translated is denoted to.
sensor j s_j Tools usually have a tracking sensor attached that communicates with the tracking system. The local sensor space is denoted s. The transform sMt is the Tool calibration. (Yes, we have two spaces called s. We have to live with that, but they are seldom seen in the same spot)

The following figure shows a case where some Data has a parent space different from the reference space. One MR volume exists, and some vascular structures are segmented out from that volume and imported as a separate Data object (a Mesh). For consistency, the new Data have the MR as the parent frame.

The CT volume is imported separately, but is at some point image-registered to the MR volume. In the process, the parent frame is changed to the MR volume.

ssc_coords_data.png
Example of data spaces with parent space different from the reference space.