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

From NAMIC Wiki
Jump to: navigation, search
Home < Breakout Session: What's Planned for Slicer Core

Introduction

Maintenance needed for core libraries

  • VTK7 (rapid changes coming to VTK due to maintenance grant)
    • Experimental support for OpenGL2 has been added
    • Slicer specific VTK changes are being upstreamed
  • Python: conda (and?)or cmake/wheels?
  • Qt5: improvements, plus 4.8 may eventually stop supporting new systems
  • support for latest WebKit

Organization

  • Establish a mechanism to install multiple extension packages by default. Ron: I frequently download Slicer nightly build. Having to manually install the 10 packages that I need routinely is a pain. This will be a disincentive for me to download the nightly.
    • would it be possible instead to recognize previous settings on the first launch of the new nightly, and ask user if s/he wants to re-install all or selection of the extensions installed before the update?
  • Move modules to extension - See also Documentation/Labs/DeprecatedModules
    • Moving diffusion to extension (in progress: SlicerDMRI as Slicer remote module)
    • 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. See #2779

Key requests from the community

  • faster startup time (particularly mac). See https://www.slicer.org/wiki/Documentation/Labs/StartupTimeImprovement
  • Less confusing UI
  • 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)
    • Experimental support for OpenGL2 has been added to Slicer
  • Faster nightly builds (extensions appear in the extension manager too late for nightly builds)
    • plan: As part of Slicer radiomics, buy a dedicated windows machine.
    • Note: Work to (1) build ppa/homebrew/chololatey packages of dependencies and (2) migrate to "modern CMake" is still needed
    • Note 2: Dockerized build of Slicer based on CentOS should be available any day.

Documentation and support

  • improved integration of Slicer YouTube channel?
  • 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)
    • (another datapoint: NiPy moved user discussion to https://neurostars.org/)

Roadmaps

  • Steve Pieper: Chronicle, ctkjs, CommonGL
  • JC Fillion-Robin: Docker, IPython support, VTK, 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

Feedback from Extension Developers

  • Python Infrastructure
    • support for wide range of modules (scikit-learn, scipy, dipy...)
    • miniconda based installation
  • Robust and scalable factory machines
  • Slicelets
    • make modules usable in no-main-window mode
    • performance for real-time applications
  • OpenCV as part of the core
  • Common database for storing trial data
  • Newer upstream packages (vtk 7, qt5, py3k...)
  • improved web site infrastructure
  • move non-core code to extensions
    • diffusion
    • EM Segment
    • endoscopy
Retrieved from "https://www.na-mic.org/w/index.php?title=2016_Winter_Project_Week/Breakout_Session/What%27s_Planned_for_Slicer_Core&oldid=97044"