2011 Project Week Breakout Session: Slicer4

Back to agenda

Summer Project Week Breakout Session: Slicer4 Module Usability

9am-11am, Tuesday June 21, 2011, Star room.

Attendees:

All Slicer4 developers.

Reference Material:

• Slicer4

Preliminary Agenda:

Purpose: Review of existing slicer4 functionality and user interface with an eye towards creating a consistent and pleasant user experience with a logical grouping of functions to accomplish standard tasks.

UI

• Review of features and next steps with the idea that developers and users can vote on priorities for development effort
  • Main application GUI: compare Slicer 3 and Slicer 4
    • Reorganizing panels above both the slice viewers and 3d viewers for consistent look and feel.
  • Review keybindings and mouse behavior on different platforms
    • Compare Slicer 3 and Slicer 4
    • Identify inconsistencies
    • How to handle Mac trackpad, multitouch I/O, single button mouse
  • I/O
    • Load/Save: Default is the scene only, which includes sceneviews. Everything else is exposed by opening an advanced panel. This will require Slicer to make some assumptions at save time, such as what format to use for data to be saved. How do we maintain dicom header information so that it survives a round trip?
    • Import/Export: to and from Dicom, other data formats
  • Module template: Help, Acknowledgements, location of I/O panel, behavior of "frames" such as auto-stretch.
  • Current List of Core modules: should they stay or should they move into other categories? Add new ones? Order?
    • Annotation Module (xx)
    • Color Module (xx)
    • Data Module (xx)
    • Interactive Editor (Steve Pieper)
    • Sceneviews (xx)
    • Slice Controls Module: Should present controls for: Slice viewers, compare viewers, 3D viewers: rename to Layout controler?
    • Slicer Welcome Module: update?
    • Volume Rendering Module: I/O should have same user experience as I/O in Slice viewers
    • Volumes Module (xx)
    • Transforms Module (xx)

Infrastructure discussions

• instrumenting dimensions for sliders, seeds etc.: Slicer users have data with a wide range of dimensions. E.g. Mouse DTI versus Human DTI: need different defaults. This is currently not working well.
• Remote IO options (save/restore of slicer data and scenes via DICOM, Midas, wiki...): Use a zip ball with a Dicom header and some thumbnails?
• Performance enhancements/bottlenecks
  • relevant mantis report: http://www.na-mic.org/Bug/view.php?id=1139
• Documentation
• Enhancements to module functionality
  • command line modules (slicer execution model)
  • extensions
  • python scripting
• Embedding slicer4 packages in standard python interpreter
• Support for new datatypes?
  • Icon associated with each datatype
  • I/O registration in qSlicer[Core]IOManager
  • Official module for each node type "Edit properties..." (current hack)

DTI needs different defaults than human DTI, for instance.

• web/mobile deployment options?
  • motivating use-case scenarios?
  • Is this just a "cool thing", a me too, or a critical path capability?
• other ideas or requests?

General Slicer4 TODO items for discussion among developers

• Porting remaining SWidgets (Crosshairs, Model/Slice Intersections, Reformat Widget...)
• Removing slicer3 legacy code from slicer4 repository
• What modules from the core should become extensions?
  • Move all command line modules outside the core as extension? this would greatly reduce the package size and compile time, unclutter menus. What is the impact on ease of installation for end users?