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

Revision as of 15:18, 14 December 2015 by Kikinis (talk | contribs) (Key requests from the community)

Jump to: navigation, search
Home < 2016 Winter Project Week < Breakout Session < What's Planned for Slicer Core


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


  • Moving diffusion to extension
  • 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)
  • OpenIGTLinkIF?
  • ...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

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)


  • 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