EngineeringRetreat2010

Back to Events

Goals: Develop clarity and a plan for this year's work; establish broader strategic vision for the next four NAMIC years.

Logistics

• When: November 17-18 (Wednesday and Thursday). Start time: noon Wednesday, end time: early afternoon Thursday
• Where: Boston SPL, 1249 Facility
• Who: Engineering Core leaders and key personnel
• Hotel: Boston Marriott Cambridge, Two Cambridge Center, 50 Broadway, Cambridge, Massachusetts 02142, Phone: 1-617-494-6600

Agenda

• Review of current commitments and planned activities
  • EngineeringRetreat2010/Kitware
  • GE - Overview of renewal [ppt] [pdf]
  • Isomics
  • St. Louis
  • UCSD
• Review of wishlist from the DBP's
• Discussion of short term goals
• Discussion of long term goals

Attendees

1. Steve Pieper
2. Will Schroeder
3. Stephen Aylward
4. Jim Miller
5. Ron Kikinis
6. Alex Yarmarkovich
7. Jeff Grethe (18th only - 17th @ Neuroscience/Committee meeting)

Notes (currently in rough form)

• Slicer the platform for anybody viewing and analyzing medical imaging data
• Strategizing about long-term NAMIC goals and funding
  • The role and importance of long-term, international collaboration
  • Long-term governance including consortium, MOU, etc. (federalist model, alternatives)
  • The role of DBP: continued engagement vs. periodic cycling (developing solution pipelines)
  • Long term scaling, maintenance, support
    • Development team and simultaneous support team
    • Push everything out of the core into modules (thereby distributing support, etc.)
  • 510k support for scoped, viewing station
• Review of Core 1b Proposal Plan (Jim's Slides)
• Greg Sharp reviewed his requirements
• Discussion of what Slicer "core" means
  • Transition into core: what is the process?
    • Control of access to the core via git / gerrit / other processes (e.g., code review using Gerrit)
  • Slicer core "bundled" with other capabilities (e.g., neuroscience core)
  • How to test Slicer? CLI is covered, GUI is not there yet
  • Supported: Core + any bundled algorithms
  • Different categories of algorithms? in editor
    • Extensions that add an "effect" to editor
    • Adaptive GUI that changes based on data type, workflow, etc.

Strategy

• Slicer 3.6.x is in maintenance mode.
  • Use it as a target for plug-in development
• New major development efforts are targeted at Slicer 4.
  • Intention to stabilize by AHM 2011
• Communication with "Customers" is a top priority.
  • For developers: stabilize the Slicer environment. Slicer has been a moving target for too long.
  • For end-users: simplify the user interface, streamline and simplify common workflows
  • Support the development of solutions
  • We are not in the "early adopter game" for new tools for developers for the next two years

Short term goals

• Targeted for AHM
• Assign owners for each bullet item on this list

Slicer 3

• stabilize and debug Slicer 3.6
• stabilize and document extensions and the process leading to them: My code is on NITRC. Now what?

Slicer 4

• Rons number 1: Augment scenes and scenesnapshots (see also its counterpart, the Image Database UI)
  • Thumbnails: user selectable toggle: 3d viewer (default), whole frame, red slice viewer, ability to replace thumbnails
  • Annotation: User-provided description of scenesnapshot/scene (Daniel Haehn)
• Rons number 2: Make load/save easier to understand for new users.
  • Single interface to all data sources based on QSlicerVolumesIODialog.
  • Plan and implement minimalist UI design for load
• Rons number 3: Review Slicer3 bug tracker for issues and feature requests - in UI, particular widgets, command line modules, improved transforms/registration... (Steve)
• Rons number 4: Keep Slicer4 Qt port on schedule (JF, JC)
• Rons number 5: VTK widgets roadmap. See here for the minutes of the recent vtk widgets retreat (Will)
• Implement and package up module templates for developers of interactive modules to get a jump on consistent UXP.(wjp)
• Refine design of slice viewer's control panel to make more compact and quiet. (wjp)
• Scene module: A new module to organize scenes and scenesnapshots
• Update Wiki pages:
  • CMAKE superbuild with support for extensions and extension dashboards (Service Core)
  • Slicer4
  • Slicer4:Developers
• Create a XML Schema for .mrml to check if a mrml document is 'well-formed' and 'valid'. Automatic generated (error free) parser can then be used for accessing/editing mrml files.
• Bug patches from Slicer 3.6 to Slicer 4

Requests from the DBPs

Utah

• DICOM I/O (ITK V.4 may take care of this)
• Deformable image registration (example application CARMA basic deformable registration algorithms.
• Tools for image registration, in general, is a big need that we have.
• GUI support for "steerable" segmentation methods like level-set methods, active contours, etc. (e.g. GA Tech's work on left atrium segmentation).
  • Workflow
  • Interaction widgets

Iowa

See Engineering Action Plan

• Create formal schema for SEM so that xml can be validated.
• Move SEM so that stand alone apps can easily use it
• Improve documentation of how to make SEM compliant programs work under windows with shared libraries.
• Document the many un-documented/partially documented attributes in SEM.
• Make slicer start faster
• When slicer3 is started in a directory, make a quick way to view the data from the current working directory.
• CMake options to download testing data from a URL. (Midas, Xnat, etc.)
• Support (and documentation) for workflows or wizards that can be made up of any number of other modules and that provide help / guidance on usage.
• Slicer compatibility with Sun Grid Engine
• Fiber profile measurement/visualization within Slicer
• CSV files as part of Slicer standards (Paths, variables, group associations, etc)
• A distributed batch processing pipeline that pulls data from and reports data to XNAT while distributing jobs across a cluster
• Refactor DicomToNrrdConverter

Would also like to second these long term goals that are listed further down:

• Identify standard workflows and allow CLI modules to declare which workflows they should be run within
• Reduce list of available modules when a user declares a field-of-interest (e.g., microscopy researchers should not be shown MRI-specific modules)
• Review all Slicer modules and determine which should be distribute with Slicer and which should be switched to being downloadable
  • Determine support policies for Slicer-included modules versus downloadable modules
  • Determine testing, documentation, review, and platform requirements to be a Slicer-included module
• extended save: save to local and remote destinations. Make plans for logic components, DB transaction, and UI design.
• Organizing multiple data sets from one subject: time series, image fusion etc.
• Make plans for a new and improved Editor for slicer4
  • Grow Cuts, RSS and fast Marching with volume cropping, integral volume rendering, (limited) GPU acceleration
• Investigate use of a binary mask used with volume rendering to specify non-rectilinear ROIs, to display segmentation results, and to display effects of interactive editing
• Define a "Core" Slicer that can be distributed with InsightApplications repository of ITKv4
  • Review Slicer application framework to support modularization and customization
  • Two audiences:
    • Create new GUI infrastructure where a simple Interface is created for each application area, e.g. one GUI for Radiologists reading brain MRI, another one for torso CT, ...
    • Simple, Extensible Platform for Developers (for custom apps/interfaces).
• Switch to GIT deferred. Reconsider after the first stable release of Slicer 4.
• Switch to client/server dashboards and take advantage of its benefits
  • Each night binaries copied from client machines to Dashboard page/database that manages them
  • Ensures Dashboards, builds, releases using common tags/svn#s
  • Ensures available binaries include last-successful build, last-release build, and last-nights build.
  • Dashboard specifies what should be build on what clients ("CDash@home" or "Client/Server CDash")
• Support scenes containing data that spans multiple scales in time and space
  • visualize, indicate correspondence and support interactions with a scene in which the data differ by orders of magnitude and change over time
• Interactive/iterative command-line modules (e.g., tied to a vtkWidget)
• Batch processing (IPython) examples
  • includes an algorithm validation framework
• Interact with ITKv4 (once released?), CTK, NiPy, and other like-minded projects.

UCLA

• trackvis file format interoperability
• NIfTI DWI file format interoperability
• LONI MiND Framework

MGH

• See planning document: http://wiki.na-mic.org/Wiki/index.php/DBP3:MGH

Big things we definitely need help with:

• Support for overlapping structures
• Improved support for extensions
• Isodose lines for RT dose

Big things we can probably do on our own:

• MRML node for demographics
• MRML node for (generic) deformable transforms
• Better DICOM support

Smaller items

• Pushing our CMake module bug fixes upstream
• Graphics glitches with image blending
• UI for structure names, colors
• Multiple refresh bugs
• Window/level slider issues
• Image reload button

Wishlist

• Display DVH in Slicer
• ITK iterator performance (needs benchmark)
• Margin tools
• Structure boolean operations
• DICOM Network I/O
• Vector field visualization
• Unevely spaced CT
• Dose comparison tools (difference, DTA, gamma index)
• Contour interpolation in editor
• Landmark markup tool

Longer Term Goals

• Identify standard workflows and allow CLI modules to declare which workflows they should be run within
  • Perhaps parallel's effort to associate CLI modules with Widgets
• Reduce list of available modules when a user declares a field-of-interest (e.g., microscopy researchers should not be shown MRI-specific modules)
• Simplify how tests are written for loadable modules
• Review all Slicer modules and determine which should be distribute with Slicer and which should be switched to being downloadable
  • Determine support policies for Slicer-included modules versus downloadable modules
  • Determine testing, documentation, review, and platform requirements to be a Slicer-included module
• DICOM read and write (local and remote) via CTK
• extended save: save to local and remote destinations. Make plans for logic components, DB transaction, and UI design.
• Organizing multiple data sets from one subject: time series, image fusion etc.
• Packaging/Superbuild fixes
  • Package for linux
  • Windows - clean registry on uninstall
  • Mac - .dmg into application folder
• Creation of a Display Module
• Make plans for a new and improved Editor for slicer4
  • Grow Cuts, RSS and fast Marching with volume cropping, integral volume rendering, (limited) GPU acceleration
• Investigate use of a binary mask used with volume rendering to specify non-rectilinear ROIs, to display segmentation results, and to display effects of interactive editing
• Define a "Core" Slicer that can be distributed with InsightApplications repository of ITKv4
  • Review Slicer application framework to support modularization and customization
  • Two audiences:
    • Create new GUI infrastructure where a simple Interface is created for each application area, e.g. one GUI for Radiologists reading brain MRI, another one for torso CT, ...
    • Simple, Extensible Platform for Developers (for custom apps/interfaces).
• Switch to GIT deferred. Reconsider after the first stable release of Slicer 4.
• Switch to client/server dashboards and take advantage of its benefits
  • Each night binaries copied from client machines to Dashboard page/database that manages them
  • Ensures Dashboards, builds, releases using common tags/svn#s
  • Ensures available binaries include last-successful build, last-release build, and last-nights build.
  • Dashboard specifies what should be build on what clients ("CDash@home" or "Client/Server CDash")
• GUI Testing
  • There is now an open-source method for automated testing of Qt-based applications: http://www.paraview.org/Wiki/Testing_design
• Support scenes containing data that spans multiple scales in time and space
  • visualize, indicate correspondence and support interactions with a scene in which the data differ by orders of magnitude and change over time
• Infrastructure that supports simultaneous GPU-based volume rendering and GPU-based interactive segmentation methods (vtkWidgets)
• Guidelines and examples for GPU-based algorithms
• Interactive/iterative command-line modules (e.g., tied to a vtkWidget)
• Determine an alternative to Mantis/bug-tracking. We have over 495 bugs.
• Batch processing (IPython) examples
  • includes an algorithm validation framework
• Interact with ITKv4 (once released?), CTK, NiPy, and other like-minded projects.
• Consider ITKv4 module management tools being developed (after they have been released as stable release)
  • Documentation prior to code development
  • Module-specific dashboards
  • forum-style commentaries on modules
• Improve support of Windows platform
  • Simplify compilation of Slicer on Windows Machines
  • Increase speed and stability of Slicer on Windows Machines
• Change release policy: A Slicer release version must not use/depend on ITK Review. If we do not make this modification then we cannot release Slicer as Debian package anymore.
• Command line module logic redesign
  • DOM objects in shared memory
  • WriteCLI in all mrml nodes

See also

• http://wiki.slicer.org/slicerWiki/index.php/Slicer4
• http://wiki.slicer.org/slicerWiki/index.php/Slicer4:Developers