Difference between revisions of "EngineeringRetreat2010"
From NAMIC Wiki
Line 211: | Line 211: | ||
* Strategizing about long-term NAMIC goals and funding | * Strategizing about long-term NAMIC goals and funding | ||
** The role and importance of long-term, international collaboration | ** The role and importance of long-term, international collaboration | ||
− | * | + | ** Long-term governance including consortium, MOU, etc. |
Revision as of 17:19, 17 November 2010
Home < EngineeringRetreat2010Back to Events
Goals: Develop clarity and a plan for this year's work; establish broader strategic vision for the next four NAMIC years.
Contents
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
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
- 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
- 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
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)
- Strategizing about long-term NAMIC goals and funding
- The role and importance of long-term, international collaboration
- Long-term governance including consortium, MOU, etc.