R2 I6 REQ

From IGSTK

Jump to: navigation, search

Iteration Requirements

Requirements listed at the top of the page will be reviewed at the beginning of each weekly tcon. Please put your initials and a date next to your entry.


General Requirements

  1. [DG 9/22/05] All state transitions of the IGSTK components must be logged by the state machine. (REQ 05.04.02)

Error Handling Functional Requirements

There are no existing IGSTK requirements for error handling. The following could be used as a starting point. The first two are toolkit-level requirement, and the others are application-level requirement.

  1. [DG 8/12/05] All Input/Output errors, whether related to the file system, the network, or any connected devices, must be detected.
  2. [DG 8/12/05] All situations where required data is missing or unusable must be detected, for example, bad tracker data or image/point data for which an attempted registration fails.
  3. * [DG 8/12/05] When a recoverable error occurs, the user must be informed and given instructions on how to remedy the error.
  4. * [DG 8/12/05] When a recoverable error occurs, the user must be given the option of declaring it to be unrecoverable, via a mechanism similar to a "Retry/Fail" dialog box.
  5. * [DG 8/12/05] When a nonrecoverable error occurs, the user must be informed and the component that sufferred the error must become unavailable.

An asterisk * marks a design guideline that has not been finalized for this iteration.

Spatial Object Requirements

  1. [JJ 6/27/05] Results of segmentation algorithms, i.e group of 3D points (x,y,z) and their connectivity, should be represented as an internal mesh structure.
  2. [JJ 6/27/05] Segmentations of tubular structures should be represented as an internal TubeObject.
  3. [JJ 6/27/05] 3-dimensional image volumes should be stored as a modality specific internal image structure.
  4. [JJ 6/27/05] We should be able to save/load image volume from disk and transfer the data to the specific internal structure.
  5. [JJ 6/27/05] We should be able to save/load meshs from disk and transfer the data to the specific internal structure.
  6. [JJ 6/27/05] We should be able to save/load tubes from disk and transfer the data to the specific internal structure.

Image I/O Functional Requirements

  1. [AE 09/08/05] Reading of CT DICOM dataset is supported.
  2. [AE 09/08/05] Reading of MR DICOM dataset is supported.
  3. *[AE 09/08/05] Reading of Fluoroscopy dataset supported.
  4. *[AE 09/08/05] Reading of Ultrasound DICOM dataset is supported.
  5. *[AE 7/14/05] Saving of rendered images and movies generation is supported.

Viewing Functional Requirements - Consolidated

  1. [RA 6/30/05] Viewing of geometric objects, 2D image objects, and 3D image objects is supported.
  2. [RA 6/30/05] Geometric objects will include basic geometry (line, plane, cone, cylinder, ellipse…) and segmentation results (mesh, tube, etc.).
  3. [RA 6/30/05] Any object can change position, orientation, and content dynamically (4D) and any view showing that object must represent that objects current state.
  4. [RA 7/14/05] The rendering parameters of any geometric object can be changed including visibility, global color, and light interaction properties.
  5. [JJ 6/27/05] We should be able to set the data values associated with regions of a mesh or a tube object.
  6. [DG 9/08/05] We will be able to associate a lookup table to color a mesh or a tube. We will support the use of a color table to map data values to colors
  7. [RA 6/30/05] Two types of viewing will be supported: 2D viewing and 3D viewing.
  8. [RA 6/30/05] Any number of 2D or 3D views may be placed in an application.
  9. [RA 6/30/05] 2D views of 2D and 3D images will support pan and zoom operations.
  10. [DG 9/15/05] A specific window/level will be associated with each image displayed.
  11. [RA 6/30/05] 2D views of 3D images will support axial, sagittal, coronal, and oblique reformats.
  12. [RA 6/30/05] 2D views of 2D images will support nearest neighbor and bilinear interpolation.
  13. *[RA 6/30/05] 2D views of segmentation objects will show the intersected contours when available.
  14. *[RA 7/14/05] 2D views of segmentation objects will show the segmentation masks when available.
  15. [RA 6/30/05] 3D views of 2D and 3D images will support perspective and parallel rendering.
  16. [RA 9/15/05] 3D views of 2D and 3D images will support rotation and flight of the camera.
  17. [RA 6/30/05] 3D views of 3D images will support axial, sagittal, coronal, and oblique reformats.
  18. [RA 6/30/05] 3D views of 3D images will support volume visualization methods including (MIP, volume rendering, and volume rendering with shading).
  19. [RA 6/30/05] 3D views of geometric objects will be displayed as either a surface, a wireframe, or collection of points.
  20. [RA 7/14/05] Constraints will be placed on all viewing parameters (camera location, zoom, etc.).
  21. [RA 7/14/05] Two types of annotation will be supported: 2D overlay and 3D embedded.
  22. [RA 7/14/05] 2D overlay annotation of images in 2D or 3D views will support display of patient information (name, patient ID, ?age?,).
  23. [RA 7/14/05] 2D overlay annotation of images in 2D or 3D views will support display of RAS orientation.
  24. [RA 7/14/05] 2D overlay annotation of images in 2D or 3D views will support display of exam, series, image, and study date information.
  25. [RA 7/14/05] 2D overlay annotation of images in 2D or 3D views will support the display of scan specific information as appropriate (scanner, resolution, slice thickness, etc.)
  26. *[RA 7/14/05] 2D overlay annotation of images in 2D or 3D views will support the display of a scale bar.
  27. *[RA 7/14/05] 2D overlay annotation of images in 2D or 3D views will support display of dynamic textual data (key info during surgery like dist to target).
  28. *[RA 7/14/05] 3D embedded annotation of images in 3D views will support display of a text box and an arrow that points to a 3D position.
  29. *[RA 7/14/05] All views will support the capture of an image of the current display and support the saving of the image in memory.
  30. *[RA 6/30/05] All parameters for viewing objects can be saved to a file and loaded (including W/L presets).
  31. *[HS 7/05/05] Picking a point from a rendering window(View) and then transforming 2D point coordinates of the picked point to 3D world coordinates should be supported. The points are typically inside the image. (e.g. to set a needle entry and target point for a biopsy).

"*" Indicates that the functionality for the requirement will be added to the toolkit after iteration 6.

Tracker landmark registration requirements

  1. [AE 08/11/05] Ability to register the tracker landmark 3D coordinates in tracker coordinate system to image or patient coordinate system. (Accepted 08/18/05)

Tracker Requirements

  1. [DG 8/11/05] When the tracker is tracking, communication with the device should be done in a separate thread. (Accepted 08/18/05, REQ 06.02.18)
  2. [DG 8/31/05] The toolkit will be able to communicate with the Aurora and Polaris devices using binary data records. (REQ 06.01.09)

Iteration Action Items

This area should describe developer plans for achieving requirements. These take the form of developer actions such as "add Aurora tracking capability to the demo application". This area is more to let other developers know what you are working on so they can understand what areas of the code might be affected in this iteration.

Tracking Action Items

  1. The AuroraTracker amalgamates support for the Polaris and Aurora, but it shouldn't
    1. The AuroraTracker class should support Aurora-specific functionality (multiple tools per port, GPIO, etc)
    2. There should be a PolarisTracker class to support Polaris functionality (passive tools, infrared detection, etc)

Retrieved from "http://public.kitware.com/IGSTKWIKI/index.php/R2_I6_REQ"
Personal tools
TOOLBOX
LANGUAGES