Difference between revisions of "EngineeringRetreat2010"
From NAMIC Wiki
m (Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/") |
|||
(121 intermediate revisions by 13 users not shown) | |||
Line 2: | Line 2: | ||
'''Goals''': Develop clarity and a plan for this year's work; establish broader strategic vision for the next four NAMIC years. | '''Goals''': Develop clarity and a plan for this year's work; establish broader strategic vision for the next four NAMIC years. | ||
+ | |||
=Logistics= | =Logistics= | ||
* When: November 17-18 (Wednesday and Thursday). Start time: noon Wednesday, end time: early afternoon Thursday | * When: November 17-18 (Wednesday and Thursday). Start time: noon Wednesday, end time: early afternoon Thursday | ||
* Where: Boston SPL, 1249 Facility | * Where: Boston SPL, 1249 Facility | ||
* Who: Engineering Core leaders and key personnel | * 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 [[Media:Engineering retreat 11-17-2010 - GE.ppt | [ppt]]] [[Media:Engineering retreat 11-17-2010 - GE.pdf | [pdf]]] | ||
+ | **[[EngineeringRetreat2010/Isomics|Isomics]] | ||
+ | **St. Louis | ||
+ | **UCSD | ||
+ | *Review of wishlist from the DBP's | ||
+ | *Discussion of short 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= | ||
+ | * 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== | ==Short term goals== | ||
− | *Targeted for AHM | + | * Targeted for AHM |
− | *Assign owners for each | + | * Assign owners for each bullet item on this list |
+ | ===Slicer 3=== | ||
+ | *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? | ||
+ | |||
+ | ===Slicer 4=== | ||
* Rons number 1: Augment scenes and scenesnapshots (see also its counterpart, the [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:Download_Data Image Database UI]) | * Rons number 1: Augment scenes and scenesnapshots (see also its counterpart, the [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:Download_Data Image Database UI]) | ||
− | **Thumbnails: user selectable toggle: 3d viewer (default), whole frame, red slice viewer | + | ** Thumbnails: user selectable toggle: 3d viewer (default), whole frame, red slice viewer, ability to replace thumbnails |
− | **Annotation: User-provided description of scenesnapshot/scene | + | ** [[Projects:ARRA:miAnnotation:PriorityList|Annotation]]: User-provided description of scenesnapshot/scene (Daniel Haehn) |
− | + | * Rons number 2: Make load/save easier to understand for new users. | |
− | * Rons number 2: | + | ** Single interface to all data sources based on [http://wiki.slicer.org/slicerWiki/index.php/File:QSlicerVolumesIODialog.png QSlicerVolumesIODialog]. |
− | * Rons number 3: Review [http://www.na-mic.org/Bug/view_all_bug_page.php Slicer3 bug tracker] for issues and feature requests - in particular widgets, command line modules, improved transforms/registration... | + | ** Plan and implement minimalist UI design for load |
− | * Rons number 4: Keep [[Projects:ARRA:SlicerUI|Slicer4 Qt port]] on schedule | + | * Rons number 3: Review [http://www.na-mic.org/Bug/view_all_bug_page.php Slicer3 bug tracker] for issues and feature requests - in UI, particular widgets, command line modules, improved transforms/registration... (Steve) |
− | *Scene | + | * Rons number 4: Keep [[Projects:ARRA:SlicerUI|Slicer4 Qt port]] on schedule (JF, JC) |
− | * | + | * Rons number 5: VTK widgets roadmap. [[WidgetDesign2010|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) | ||
+ | * [http://wiki.slicer.org/slicerWiki/index.php/Slicer4:SceneModule Scene module]: A new module to organize scenes and scenesnapshots | ||
+ | * Update Wiki pages: | ||
+ | ** [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:Developers 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 ==== | ||
+ | * 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 [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 ==== | ||
+ | * [http://trackvis.org/docs/?subsect=fileformat trackvis file format interoperability] | ||
+ | * [http://www.ncbi.nlm.nih.gov/pubmed/20206274 NIfTI DWI file format interoperability] | ||
+ | * [http://mind.loni.ucla.edu/specification/overview/ 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 [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 [ | + | * 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 | + | ** 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 | ||
− | * | + | * 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 | * GUI Testing | ||
** There is now an open-source method for automated testing of Qt-based applications: http://www.paraview.org/Wiki/Testing_design | ** There is now an open-source method for automated testing of Qt-based applications: http://www.paraview.org/Wiki/Testing_design | ||
Line 35: | Line 241: | ||
** visualize, indicate correspondence and support interactions with a scene in which the data differ by orders of magnitude and change over time | ** 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) | * Infrastructure that supports simultaneous GPU-based volume rendering and GPU-based interactive segmentation methods (vtkWidgets) | ||
− | |||
− | |||
− | |||
− | |||
* Guidelines and examples for GPU-based algorithms | * Guidelines and examples for GPU-based algorithms | ||
* Interactive/iterative command-line modules (e.g., tied to a vtkWidget) | * Interactive/iterative command-line modules (e.g., tied to a vtkWidget) | ||
− | |||
* Determine an alternative to Mantis/bug-tracking. We have over 495 bugs. | * Determine an alternative to Mantis/bug-tracking. We have over 495 bugs. | ||
* Batch processing (IPython) examples | * Batch processing (IPython) examples | ||
** includes an algorithm validation framework | ** includes an algorithm validation framework | ||
− | * Interact with [http://www.kitware.com/blog/home/post/49 ITKv4], [http://commontk.org CTK], [http://nipy.sourceforge.net/software/projects/ NiPy], and other like-minded projects. | + | * 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. |
− | * | + | * 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= | =See also= | ||
*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 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Latest revision as of 17:37, 10 July 2017
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
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 (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.
- Need to make the wizard easier to use
- Transition into core: what is the process?
- 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)
- Utah
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
- 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