Difference between revisions of "2016 Winter Project Week/Breakout Session/What's Planned for Slicer Core"

From NAMIC Wiki
Jump to: navigation, search
Line 9: Line 9:
 
=Organization=
 
=Organization=
 
* Moving diffusion to extension
 
* Moving diffusion to extension
* Moving EMSegmenter to extension (very large, with lots of data; it would significantly reduce the Slicer installation package size)
+
* Moving EMSegmenter to extension: very large, with lots of data; it would significantly reduce the Slicer installation package size
* Endoscopy, PET SUV (small modules, they are just too specific to be included in the core)
+
* Move BRAINS, SimpleITK, OpenIGTLinkIF to extension: frequently used modules but they are quite large, also by having them in extensions they could be updated without the need to create a new Slicer release
* OpenIGTLinkIF?
+
* Moving Endoscopy, PET SUV, various filters to extensions: small modules, they are just too specific to be included in the core
 
* ...other things to extensions?
 
* ...other things to extensions?
 
* revise DICOM plugins organization - if the data is not recognized by installed plugins, there is no way for the user to know what extension to install to handle the dataset
 
* revise DICOM plugins organization - if the data is not recognized by installed plugins, there is no way for the user to know what extension to install to handle the dataset
 +
 +
Other suggestions:
 +
* Keep official version of tier I extensions in GitHub in the Slicer organization so that any Slicer core developer can fix and update them easily.
 +
* Move orphan extensions (that developers cannot maintain anymore) to GitHub under Slicer organization's ownership so that they can be kept in a working condition
  
 
=Key requests from the community=
 
=Key requests from the community=

Revision as of 17:56, 15 December 2015

Home < 2016 Winter Project Week < Breakout Session < What's Planned for Slicer Core

Introduction

Maintenance needed for core libraries

  • VTK7 (rapid changes coming to VTK due to maintenance grant)
  • Python: conda (and?)or cmake/wheels?
  • Qt5: improvements, plus 4.8 may eventually stop supporting new systems

Organization

  • Moving diffusion to extension
  • Moving EMSegmenter to extension: very large, with lots of data; it would significantly reduce the Slicer installation package size
  • Move BRAINS, SimpleITK, OpenIGTLinkIF to extension: frequently used modules but they are quite large, also by having them in extensions they could be updated without the need to create a new Slicer release
  • Moving Endoscopy, PET SUV, various filters to extensions: small modules, they are just too specific to be included in the core
  • ...other things to extensions?
  • revise DICOM plugins organization - if the data is not recognized by installed plugins, there is no way for the user to know what extension to install to handle the dataset

Other suggestions:

  • Keep official version of tier I extensions in GitHub in the Slicer organization so that any Slicer core developer can fix and update them easily.
  • Move orphan extensions (that developers cannot maintain anymore) to GitHub under Slicer organization's ownership so that they can be kept in a working condition

Key requests from the community

  • faster startup time (particularly mac)
  • Less confusing UI
    • Every module should be display an initial subset of the functionality (as minimal as possible) and a closed "Advanced" tab that contains everything else.
    • cursor modes? http://www.na-mic.org/Bug/view.php?id=2419
  • Add orientation information to vtkImageData (request for VTK, not just Slicer but all VTK-based medical image computing groups suffer a lot because of this)
  • Make it easy to add custom slice and 3D widgets (for various custom quantification, segmentation, planning, targeting, etc. tasks - currently we can observe markup points and create custom models for visualization, but the method is very fragile and many things are missing, for example, no way to detect if the user clicks on a markup, no way to limit number of markups or restrict them to be placed on a certain surface, etc.)
  • Modern, integrated revision control, issue tracking, dashboard, code review, documentation, etc. toolset
  • Simplify data import/export/saving/loading (single-click save to database, direct data loading by drag-and-drop - by inspection of file contents instead of just checking file extension and asking the user how the data should be interpreted, automatic loading of just imported DICOM data, etc.)
  • (add your favorites here...)

Some short-term but high-priority issues:

  • GPU-based volume rendering (due to problem in VTK)
  • Faster nightly builds (extensions appear in the extension manager too late for nightly builds)

Documentation and support

  • improved integration of Slicer YouTube channel? What to do about China?
  • documentation page usage statistics to rank relevance of modules?
  • discuss alternatives to mailing list?
    • example from ITCR community (discussed at the ITCR Training and Outrech call, provided here from the meeting minutes by Andrey Fedorov)
      • https://support.bioconductor.org/
      • Bioconductor migrated their mailing list content to Biostars-based support forum site (modeled on stack overflow). Biostars is free and open source. Community core members were somewhat reluctant. Email list remains for technical/dev forum and support site is used for users. Email list is more like a back and forth dialogue. In contrast the support site has less back and forth. It’s made it easier for people to ask less knowledgeable questions.
      • Bioconductor recognizes individuals for their contributions to the support site.
      • Another factor in favor of the support site is that there is incentive nd motivation to contribute (upvotes, counts of # of responses, etc)

Roadmaps

  • Steve Pieper: Chronicle, ctkjs, CommonGL
  • JC Fillion-Robin: Girder, Anaconda, Factory machines
  • Andras Lasso: Sequences
  • Csaba Pinter: Segmentations
  • Mike Halle: Slicer webinfrastructure and github
  • Andrey Fedorov: DICOM objects for interoperability
    • focus areas: segmentations, enhanced multiframe (single-file MR series, parametric maps), volumetric measurement structured reports
    • approach
      • developer API in DCMTK
      • reusable command-line converters for extension developers
      • user-level domain-specific applications
    • open question for discussion: should this functionality be in the core or extension