Slicer3:Editor

Slicer3:Editor

This page contains design notes. See this page for documentation of the current release version.

More info at Slicer3:EditorUsabilitySessions

Goals

The Slicer3 Editor module needs to support manual definition of anatomical ROIs ("tracing") and a set of tools for manipulating existing ROIs.

Features

Currently envisioned features include:

• Create label map from Scalar Volume template
  • match dimensions, pixel sizes
  • allow 'oversample' mode (higher resolution label map than source volume)
  • automatically set slice view bg/lb planes for editing

• Painting
  • Circular brush applied to label plane
    • Variable radius (measured in screen space units)
    • Painting in arbitrary slice orientations
  • Optional 'threshold paint'
    • Use intensity information from bg to mask application of paint on a per-pixel basis (independent of bg/lb resolution differences)
  • "Eyedropper" Mode
    • Picks up the label number from the point where the interaction started and uses that for the brush stroke
    • Useful for editing an existing label map

• Voodoo
  • Wand tool
    • Select point inside object, group all pixels connected to seed that are within X intensity units of the seed point (itkConnectedThreshold could be used).
  • Level tracing
    • Select point on boundary of object, trace the level curve of the intensity of the seed point
  • +/- gestures
    • Select points inside and outside the object, construct segmentation from the positive and negative sets

• Drawing (Polygon based)
  • Freehand: points added down as the mouse moves
  • Point Based: each click adds a point
  • Individual points editable with select/drag operations
  • Label pixels that will be set when apply operation is performed are visible as feedback during the painting stage
    • polygons draw at screen space for user feedback
    • rasterization takes place at the resolution of the label map
  • Should support self-intersecting polygons with correct 'even/odd' rasterization rules (perhaps this isn't strictly needed, but I believe users will be confused and frustrated if this isn't handled correctly.)
  • Ideally all drawing should be done at floating point vertex boundaries and then discretized to label map resolution when applied. If no approprated rendering tool is found, this constraint could be relaxed to require that vertex locations are at integer pixel locations in label map space.

• Splines (to be added in 2007, not part of first slicer3 release)
  • Layered on top of polygon support (relies on polygon rasterizing infrastructure)
  • 'Modern' direct manipulation interface required for editing

• Math Morphology
  • Erode, Dilate, Closure, etc
  • Could be in separate Module (using ITK, command line module)

• Island Operations
  • Save Island, Change Island, Identify Islands
  • Could be in separate Module (using ITK, command line module)

• Level Set Operations
  • Region Growing
  • Could be in separate Module (using ITK, command line module)

• Volume Math, Volume Logic
  • Would be great to support arbitrary math/logic expressions per-pixel
  • Could be in separate Module (using ITK, command line module)
  • Could rely on unu (bundled with slicer already)
  • Matlab interface for people needing more sophisticated operations

• Undo / AutoSave
  • Ideally the editor will have full undo. Since the MRML scene code supports this it should be possible to set up.
  • The vtkSlicePaint class includes an ExtractImage and a ReplaceImage option which allows the storage of the pixels under the brush stroke to be saved so they can be restored later in an undo operations. This has not been exposed on the interface.
  • Some users have requested that an auto save (say, every minute) would be more useful to them than undo. They would like to be able to easily review the history of their editing and if needed revert to an earlier version. Since compressed label maps are small, this shouldn't be a disk space issue (or even a performance issue if it can be done in a thread). Since this auto save feature is much easier to implement it may be the preferred method for the first Slicer3 releases.

User Feedback

Sessions to gather user feedback from users of Slicer2's editor and gather recommendations for the Slicer3's editor have begun: Notes from editor usability sessions

Implementation Options

Most of the operations are being implemented with stock or custom VTK C++ classes (vtkSlicePaint). Current GUI is based on the ScriptedModule infrastructure and uses a set of incrTcl classes to implement the interactive event management. For Slicer 3.0 we will stick with the incrTcl code but expect to migrate much or all of the functionality to native VTK C++ using the Widget framework as it matures (as of VTK 5.x fall 2006 slicer needed features beyond the supported set).

Many of the features described above are addressed nicely by existing VTK or ITK code and can be applied directly. Finding a good solution for polygon rasterization has proven more difficult and is address in the a dedicated page on rasterizing.

Plan

A prototype version of the Paint-based editor has been in Slicer3 alpha since summer of 2006 and has been tested by end users (the threshold paint feature being particularly popular).

Draw based operations will be implmented in November/December 2006 for inclusion with the Slicer3 release in January.

Other operations (morphology, island, math, logic) tools are still being evaluated and my not be added until later releases.

Issues

As a highly interactive module the user interface details are essential for allowing users to productively use the tool for long periods of time. We fully expect to continue iterating on the implementation and design of the Editor over the next several years.