Coordinate system redesign
From IGSTK
This page is intended to capture design issues related to coordinate systems in IGSTK.
Contents |
Design goals
- Safety.
- Computational efficiency.
- Reusability & extensibility within IGSTK.
Overview
Graph Representation
- Parent-child specification of graph structure.
- Local transformation specified as part of the parent-child relationship.
- More complex transformations can be derived from the structure of the graph.
- A transformation from coordinate system A to coordinate system B is possible if there is a path in the graph that connects A to B.
- Nodes in the graph have out-degree 1, i.e. they're only connected to their parent.
- Nodes can be a parent to multiple children.
- Nodes do not keep a record of their children.
World Coordinates
- No explicit world coordinate system, all transformations are relative from one coordinate system to another.
- No explicit root node. Roots are nodes without parents. Each tree in the graph has only one root, but the graph structure allows for multiple roots.That is, the coordinate graph may be a forest of trees.
- Roots are not explicitly used in computing transforms. The transform path from one coordinate system to another is found using the "lowest common ancestor" or LCA.
Objects Involved
- High-level objects, such as SpatialObjects, Trackers, TrackerTools, and Views use a coordinate system graph to define spatial relationships.
- Coordinate system API should be (but, is not yet) available through the use of a few macros. See igstkCoordinateSystemInterfaceMacros.h for more details. Once the macros are available, other objects should be able to add the coordinate system API easily, if necessary.
- Each of these high-level objects (SpatialObject, Tracker, View, etc):
- Owns a node in the graph.
- Can be a parent or a child.
- Can be a target of a coordinate system transformation.
- Can instigate a coordinate transformation to another target.
Relevant classes & files
- CoordinateReferenceSystem (Status: Checked in)
- CoordinateReferenceSystemDelegator (Status: Checked in, not in CMakeLists.txt)
- igstkCoordinateSystemInterfaceMacros.h (Status: Checked in)
- SpatialObject (Status: Checked in)
- View (Status: Checked in)
- Tracker (Status: Checked in)
Design Notes
- Maintaining consistent validity between high level objects and coordinate system graph may be difficult.
- Transform class does not have an explicit notion of a target and destination coordinate systems. However, new transform events do. This should allow verification of transform results against requested transformation. An example: Request compute transform from scanner coordinates to tracker coordinates. An event returns with pointers to the scanner and tracker coordinate systems.
Open Issues and Feature Requests for Phase III
- A way to export a coordinate system graph as a diagram. Perhaps in a similar fashion as the state machine diagrams. This would make debugging coordinate system issues much easier.
- Add an example that tests IGSTK from end-to-end, i.e., a tracker moving a spatial object in an image volume.
- Change name of CoordinateReferenceSystem -- may be confusing. (Earlier suggestion from Frank.)
- Will rename CoordinateReferenceSystem as CoordinateSystem.
- Finish cleaning up examples and tests. Ensure that they work with the new coordinate system design.
- Modified ImageSpatialObjectRepresentation on Monday (1/14/08) to take into account the image matrix (translation & direction cosines).
- Problems setting landmark registration transform (see T-con agenda 011508).
RequestSetTransformandParent(identity, trackerTool); .... RequestSetTransformAndParent(landmarkRegistrationTransform, trackerTool);
- Provide a small example showing how to connect a tracker, tracker tool, and landmark registration transform.
- DeckOfCardRobot and NeedleBiopsy examples need to be updated to use new coordinate system API.
- Review use of events (e.g. TransformModified) for consistency with new coordinate system events.
