R2 I5 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.


** DG NOTE: All requirements that are not marked as complete have been copied to Iteration 6 page: R2_I6_REQ


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. [RA 7/14/05] Loading of 2D and 3D DICOM data is supported.
  2. [RA 7/14/05] Loading of CT, MR, Fluoroscopy, and Ultrasound DICOM data is supported.
  3. [RA 7/14/05] Saving of rendered images and movies 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 color of specific regions of a mesh or a tube and might use a lookup table.
  6. [RA 6/30/05] Two types of viewing will be supported: 2D viewing and 3D viewing.
  7. [RA 6/30/05] Any number of 2D or 3D views may be placed in an application.
  8. [RA 6/30/05] 2D views of 2D and 3D images will support W/L, pan, zoom, and annotation.
  9. [RA 6/30/05] 2D views of 3D images will support axial, sagittal, coronal, and oblique reformats.
  10. [RA 6/30/05] 2D views of 2D images will support nearest neighbor and bilinear interpolation.
  11. [RA 6/30/05] 2D views of segmentation objects will show the intersected contours when available.
  12. [RA 7/14/05] 2D views of segmentation objects will show the segmentation masks when available.
  13. [RA 6/30/05] 3D views of 2D and 3D images will support perspective and parallel rendering.
  14. [RA 6/30/05] 3D views of 3D images will support axial, sagittal, coronal, and oblique reformats.
  15. [RA 6/30/05] 3D views of 3D images will support volume visualization methods including (MIP, volume rendering, and volume rendering with shading).
  16. [RA 6/30/05] 3D views of geometric objects will be displayed as either a surface, a wireframe, or collection of points.
  17. [RA 7/14/05] Constraints will be placed on all viewing parameters (camera location, zoom, etc.).
  18. [RA 7/14/05] Two types of annotation will be supported: 2D overlay and 3D embedded.
  19. [RA 7/14/05] 2D overlay annotation of images in 2D or 3D views will support display of patient information (name, patient ID, ?age?,).
  20. [RA 7/14/05] 2D overlay annotation of images in 2D or 3D views will support display of RAS orientation.
  21. [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.
  22. [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.)
  23. [RA 7/14/05] 2D overlay annotation of images in 2D or 3D views will support the display of a scale bar.
  24. [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).
  25. [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.
  26. [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.
  27. [RA 6/30/05] All parameters for viewing objects can be saved to a file and loaded (including W/L presets).
  28. [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).

Image I/O Design Requirements Ready by 07/21/05.

Viewer Design Requirements Ready by 07/21/05.

Spatial Object & Spatial Object Representation Design Requirements Ready by 07/21/05.

Logger Requirements

  1. [HS 7/05/05] Log messages from VTK must be redirected to itk::Logger. (Accepted 7/7/05, REQ 05.07.05)
  2. [HS 7/05/05] Printing log messages on FLTK windows must be supported. (Accepted 7/7/05, REQ 05.07.06)
  3. [HS 7/06/05] Printing class names for DEBUG messages by igstkLogMacro and igstkLogMacroStatic should be done.

Tracker Requirements

  1. [DG 6/9/05] The transforms that the tracker component provides for the spatial objects need to be in patient coordinates. To accomplish this, it must be necessary to provide the tracker component with a "patient transform" that will be applied to the raw transforms provided by the tracking device to convert them to the chosen patient coordinate system. (Accepted 6/23/05, REQ 06.01.06 (Style Guideline)
  2. [DG 6/9/05] The tracker component should allow a reference tool to be set, so that all other tools will be tracked relative to the reference tool. (Accepted 6/23/05, REQ 06.01.07 (Style Guideline)
  3. [BB 6/16/05] The tracker component should provide identification information for each tool that is tracked. This information must be sufficient such that it is possible to determine whether it is valid to use a particular tool as a reference. (Accepted, 6/23/05, REQ 06.02.17 (Style Guideline))
  4. [DG 6/9/05] Derived classes should have a SetCommunication() method whenever possible, but the Communication component should not be part of the base class. It should be a requirement that the Aurora and Polaris trackers have a Communication component. (Rejected 6/23/05, too similar to an existing requirement)
  5. [DG 6/9/05] The tracker component will support, as a minimum, the Aurora and Polaris devices. (Accepted 6/23/05, REQ 06.01.08 (Design Guideline))

Communication Requirements

  1. [DG 6/9/05] Communication component need to be able to communicate binary data as well as ascii data (Accepted 6/23/05, REQ 05.06.02 (Style Guideline))
  2. [DG 6/9/05] Communication component needs to be able to support "Canonical" and "Non-Canonical" communication. "Canonical" communication means that replies are terminated by special characters (e.g. a carriage return) while Non-Canonical communication means that the data record size must be known ahead of time. (Accepted 6/23/05, REQ 05.06.03 (Style Guideline)
  3. [DG 6/9/05] Communication component must report a timeout event rather than simply freezing when communication is broken. (Accepted 6/23/05, REQ 05.06.04 (Style Guideline))
  4. [DG 7/14/05] Communication component should be able to replay previous communication sessions for testing purposes (Accepted 7/21/05, REQ 05.06.05).

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.

Tracker

  1. Tracker base design is complete, but a few design items remain:
    1. Events are needed, in particular events to notify the application when a tracking device failure occurs
    2. State machine needs small modifications regarding resetting and closing the tracker
  2. Proper Polaris support. The current AuroraTracker class will work with the Polaris, but separate Tracker classes will be required to take full advantage of the features of each device.

Communication

  1. Simulate serial communication for testing purposes (we've needed this all along, and this is a good time to implement it)
    1. Create a SerialCommunicationSimulator class. The class itself will be fairly simple, since all the simulation data will exist as a text file. The text file will consist of interleaved command/reply blocks.
    2. The existing SerialCommunication class will need to be modified so that it can produce these testing files while talking to an actual device, so that a real tracker session can later be used as simulation data
  2. Communication classes still need a work-over, which Hee-su has been doing

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