Difference between revisions of "EngineeringRetreat2010"

From NAMIC Wiki
Jump to: navigation, search
m (Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/")
 
(67 intermediate revisions by 8 users not shown)
Line 11: Line 11:
 
=Agenda=
 
=Agenda=
 
*Review of current commitments and planned activities
 
*Review of current commitments and planned activities
**Kitware
+
**[[EngineeringRetreat2010/Kitware]]
**GE
+
**GE - Overview of renewal [[Media:Engineering retreat 11-17-2010 - GE.ppt | [ppt]]] [[Media:Engineering retreat 11-17-2010 - GE.pdf | [pdf]]]
**Isomics
+
**[[EngineeringRetreat2010/Isomics|Isomics]]
 
**St. Louis
 
**St. Louis
 
**UCSD
 
**UCSD
 
+
*Review of wishlist from the DBP's
 
*Discussion of short term goals
 
*Discussion of short term goals
 
*Discussion of long term goals
 
*Discussion of long term goals
 +
 +
=Attendees=
 +
#Steve Pieper
 +
#Will Schroeder
 +
#Stephen Aylward
 +
#Jim Miller
 +
#Ron Kikinis
 +
#Alex Yarmarkovich
 +
#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 ([[Media:Engineering retreat 11-17-2010 - GE.ppt|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.
 +
** Using CLI in workflow wizard
 +
*** Need to make the wizard easier to use
 +
**** One type of wizard is a "documentation guide" that directs the user what to do
 +
**** Next level is a more formal wizard that controls the GUI
 +
*** Creating workflows by scripting / recording GUI interaction
 +
*** Defining workflow at a high level sequence of steps
 +
*** Controlling "next" / "previous" in workflow; controlling display (after operations); controlling connection/auto update with interactors/widgets.
 +
* Return to DBP review and discussion
 +
** Utah
 +
*** added some extra content related to interaction and histograms
 +
*** An issue was raised: what about storing state in the CLI
 +
** Iowa
 +
*** SEM for MRML
 +
*** Starting Slicer faster (loading modules is most of the delay, put in separate thread)
 +
**** Slite (Slicer Lite)
 +
*** One interesting discussion point: dealing with spatial/temporal scale (e.g., medical image combined with histological image). How to deal with units, GUI, interaction and rendering.
 +
*** Consistent with Engineering Core plans (refer to wiki for further details)
 +
** UCLA
 +
*** File formats
 +
*** DICOM to NRRD converter is the way to go in some cases
 +
** MGH (revisited)
 +
*** Adaptive radiotherapy: adjust plan as tumors shrink? Answer: not something we want to change. Maybe change is swelling occurs.
 +
*** Improved segmentation and visualization tools
 +
*** Monitoring secondary effects post-treatment (e.g., lobe shrinkage)
  
 
=Strategy=
 
=Strategy=
Line 35: Line 90:
 
* Assign owners for each bullet item on this list
 
* Assign owners for each bullet item on this list
 
===Slicer 3===
 
===Slicer 3===
*stabilize and [http://www.slicer.org/slicerWiki/index.php/Slicer3:3.6_Final_Issues debug Slicer 3.6]
+
*stabilize and [https://www.slicer.org/wiki/Slicer3:3.6_Final_Issues debug Slicer 3.6]
 
*stabilize and document extensions and the process leading to them: My code is on NITRC. Now what?
 
*stabilize and document extensions and the process leading to them: My code is on NITRC. Now what?
  
Line 52: Line 107:
 
* [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:SceneModule Scene module]: A new module to organize scenes and scenesnapshots  
 
* [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:SceneModule Scene module]: A new module to organize scenes and scenesnapshots  
 
* Update Wiki pages:
 
* Update Wiki pages:
** [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:CMAKESuperbuild CMAKE superbuild with support for extensions] (Service Core)
+
** [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:CMAKESuperbuild CMAKE superbuild with support for extensions and extension dashboards] (Service Core)
 
** [http://wiki.slicer.org/slicerWiki/index.php/Slicer4 Slicer4]
 
** [http://wiki.slicer.org/slicerWiki/index.php/Slicer4 Slicer4]
 
** [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:Developers Slicer4:Developers]
 
** [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:Developers Slicer4:Developers]
Line 60: Line 115:
 
=== Requests from the DBPs ===
 
=== Requests from the DBPs ===
 
==== Utah ====
 
==== Utah ====
 +
* need some extend support for DICOM I/O (ITK V.4 may take care of this)
 +
* Deformable image registration (example applications exist in both clinical image management and in experiments)  .)
 +
* Tools for image registration, in general, is a big need that we have.  Again, examples exist for both clinical and experimental data.
 +
* 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
 +
*** Placing fudicials, guides, constraints, walls, sources, sinks, etc.
 +
* "Show me a histogram, let me pick a range from the histogram" and provide means for histogram processing to suggest thresholds.
 +
 
==== Iowa ====
 
==== Iowa ====
 +
See [http://www.na-mic.org/Wiki/index.php/DBP3:Iowa 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 [http://wiki.na-mic.org/Wiki/index.php/EngineeringRetreat2010#Longer_Term_Goals 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 [https://www.slicer.org/wiki/Modules:Editor-Documentation-3.6 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 [http://www.kitware.com/blog/home/post/49 ITKv4] (once released?), [http://commontk.org CTK], [http://nipy.sourceforge.net/software/projects/ NiPy], and other like-minded projects.
 +
 
==== UCLA ====
 
==== UCLA ====
 
* [http://trackvis.org/docs/?subsect=fileformat trackvis file format interoperability]
 
* [http://trackvis.org/docs/?subsect=fileformat trackvis file format interoperability]
Line 67: Line 174:
  
 
==== MGH ====
 
==== 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 ==
 
== Longer Term Goals ==
Line 84: Line 222:
 
** Mac - .dmg into application folder
 
** Mac - .dmg into application folder
 
* Creation of a [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:DisplayModule Display Module]
 
* Creation of a [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:DisplayModule Display Module]
* Make plans for a new and improved [http://www.slicer.org/slicerWiki/index.php/Modules:Editor-Documentation-3.6 Editor] for slicer4
+
* Make plans for a new and improved [https://www.slicer.org/wiki/Modules:Editor-Documentation-3.6 Editor] for slicer4
 
** Grow Cuts, RSS and fast Marching with volume cropping, integral volume rendering, (limited) GPU acceleration
 
** 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
 
* 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
Line 124: Line 262:
 
*http://wiki.slicer.org/slicerWiki/index.php/Slicer4
 
*http://wiki.slicer.org/slicerWiki/index.php/Slicer4
 
*http://wiki.slicer.org/slicerWiki/index.php/Slicer4:Developers
 
*http://wiki.slicer.org/slicerWiki/index.php/Slicer4:Developers
 
=Attendees=
 
#Steve Pieper
 
#Will Schroeder
 
#Stephen Aylward
 
#Jim Miller
 
#Ron Kikinis
 
#Alex Yarmarkovich
 
#Jeff Grethe (18th only - 17th @ Neuroscience/Committee meeting)
 

Latest revision as of 17:37, 10 July 2017

Home < 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

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.
    • Using CLI in workflow wizard
      • Need to make the wizard easier to use
        • One type of wizard is a "documentation guide" that directs the user what to do
        • Next level is a more formal wizard that controls the GUI
      • Creating workflows by scripting / recording GUI interaction
      • Defining workflow at a high level sequence of steps
      • Controlling "next" / "previous" in workflow; controlling display (after operations); controlling connection/auto update with interactors/widgets.
  • Return to DBP review and discussion
    • Utah
      • added some extra content related to interaction and histograms
      • An issue was raised: what about storing state in the CLI
    • Iowa
      • SEM for MRML
      • Starting Slicer faster (loading modules is most of the delay, put in separate thread)
        • Slite (Slicer Lite)
      • One interesting discussion point: dealing with spatial/temporal scale (e.g., medical image combined with histological image). How to deal with units, GUI, interaction and rendering.
      • Consistent with Engineering Core plans (refer to wiki for further details)
    • UCLA
      • File formats
      • DICOM to NRRD converter is the way to go in some cases
    • MGH (revisited)
      • Adaptive radiotherapy: adjust plan as tumors shrink? Answer: not something we want to change. Maybe change is swelling occurs.
      • Improved segmentation and visualization tools
      • Monitoring secondary effects post-treatment (e.g., lobe shrinkage)

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:
  • 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

  • need some extend support for DICOM I/O (ITK V.4 may take care of this)
  • Deformable image registration (example applications exist in both clinical image management and in experiments) .)
  • Tools for image registration, in general, is a big need that we have. Again, examples exist for both clinical and experimental data.
  • 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
      • Placing fudicials, guides, constraints, walls, sources, sinks, etc.
  • "Show me a histogram, let me pick a range from the histogram" and provide means for histogram processing to suggest thresholds.

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

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
  • 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