Difference between revisions of "EngineeringRetreat2010"

From NAMIC Wiki
Jump to: navigation, search
Line 216: Line 216:
 
*** Development team and simultaneous support team
 
*** Development team and simultaneous support team
 
*** Push everything out of the core into modules (thereby distributing support, etc.)
 
*** Push everything out of the core into modules (thereby distributing support, etc.)
 +
** 510k support for scoped viewing station

Revision as of 19:07, 17 November 2010

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

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

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

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)

  • 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
Retrieved from "https://www.na-mic.org/w/index.php?title=EngineeringRetreat2010&oldid=61234"