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

From NAMIC Wiki
Jump to: navigation, search
m (Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/")
 
(13 intermediate revisions by 3 users not shown)
Line 4: Line 4:
 
=Maintenance needed for core libraries=
 
=Maintenance needed for core libraries=
 
* VTK7 (rapid changes coming to VTK due to maintenance grant)
 
* VTK7 (rapid changes coming to VTK due to maintenance grant)
* Python: [http://wiki.slicer.org/slicerWiki/index.php/Documentation/Labs/SlicerCondaIntegration conda] (and?)or cmake/wheels?
+
** Experimental support for OpenGL2 has been added
 +
** Slicer specific VTK changes are being upstreamed
 +
* Python: conda (and?)or cmake/wheels?
 +
** miniconda: http://wiki.slicer.org/slicerWiki/index.php/Documentation/Labs/SlicerCondaIntegration
 +
** cmake/wheels: Next week, kick off meeting for project aiming at improving Integration of CMake based project in the Scientific Python Ecosystem. We also have support of core Python packaging authority members. 
 +
** note: for Python 3.5, the Python.org, Anaconda, and Gohlke package builds have converged to MSVC 2015 ([https://groups.google.com/a/continuum.io/d/msg/anaconda/cTz7cVPQkKM/4ydIH0szAgAJ discussion])
 +
** note2: See also http://stevedower.id.au/blog/building-for-python-3-5/  
 
* Qt5: improvements, plus 4.8 may eventually stop supporting new systems
 
* Qt5: improvements, plus 4.8 may eventually stop supporting new systems
 
* support for latest WebKit
 
* support for latest WebKit
Line 11: Line 17:
 
* 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.
 
* 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?
 
** 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 [http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/DeprecatedModules Documentation/Labs/DeprecatedModules]
+
* Move modules to extension - See also [https://www.slicer.org/wiki/Documentation/Labs/DeprecatedModules Documentation/Labs/DeprecatedModules]
** Moving diffusion to extension
+
** Moving diffusion to extension (in progress: [https://github.com/SlicerDMRI/SlicerDMRI/tree/remaster5 SlicerDMRI] as [https://github.com/ihnorton/Slicer/tree/remove_dmri Slicer remote module])
 
** 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
 
** 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
 
** 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
Line 24: Line 30:
  
 
=Key requests from the community=
 
=Key requests from the community=
* faster startup time (particularly mac). See http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/StartupTimeImprovement
+
* faster startup time (particularly mac). See https://www.slicer.org/wiki/Documentation/Labs/StartupTimeImprovement
 
* Less confusing UI
 
* 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.
 
** 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
 
** cursor modes? http://www.na-mic.org/Bug/view.php?id=2419
 
** Slicer logo steals a lot of precious space - can we move it to the tools buttons toolbar? http://www.na-mic.org/Bug/view.php?id=3797
 
** Slicer logo steals a lot of precious space - can we move it to the tools buttons toolbar? http://www.na-mic.org/Bug/view.php?id=3797
* 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). See [https://github.com/SlicerRt/SlicerRT/blob/master/SegmentationCore/vtkOrientedImageData.h vtkOrientedImageData class] and [https://github.com/SlicerRt/SlicerRT/blob/master/SegmentationCore/vtkOrientedImageDataResample.h related utility]
+
* 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).
 +
** See [https://github.com/SlicerRt/SlicerRT/blob/master/SegmentationCore/vtkOrientedImageData.h vtkOrientedImageData class] and [https://github.com/SlicerRt/SlicerRT/blob/master/SegmentationCore/vtkOrientedImageDataResample.h related utility]
 +
** https://www.slicer.org/wiki/Documentation/Labs/VTK-Orientation
 
* 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.)
 
* 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
 
* Modern, integrated revision control, issue tracking, dashboard, code review, documentation, etc. toolset
Line 37: Line 45:
 
Some short-term but high-priority issues:
 
Some short-term but high-priority issues:
 
* GPU-based volume rendering (due to problem in VTK)
 
* 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)
 
* 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
 
Documentation and support
Line 49: Line 61:
 
*** Bioconductor recognizes individuals for their contributions to the support site.
 
*** 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 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/)
  
 
* improve outreach and visibility by being more "google friendly" ? http://www.na-mic.org/Bug/view.php?id=3938  Ron: how about China?
 
* improve outreach and visibility by being more "google friendly" ? http://www.na-mic.org/Bug/view.php?id=3938  Ron: how about China?
Line 54: Line 67:
 
=Roadmaps=
 
=Roadmaps=
 
*Steve Pieper: Chronicle, ctkjs, CommonGL
 
*Steve Pieper: Chronicle, ctkjs, CommonGL
*JC Fillion-Robin: [http://girder.readthedocs.org/en/latest/ Girder], Anaconda, Factory machines
+
*JC Fillion-Robin: [https://github.com/thewtex/SlicerDocker Docker], IPython support, VTK, [http://girder.readthedocs.org/en/latest/ Girder], Anaconda, Factory machines
*Andras Lasso: [http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Extensions/Sequences Sequences]
+
*Andras Lasso: [https://www.slicer.org/wiki/Documentation/Nightly/Extensions/Sequences Sequences]
*Csaba Pinter: [http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Modules/Segmentations Segmentations]
+
*Csaba Pinter: [https://www.slicer.org/wiki/Documentation/Nightly/Modules/Segmentations Segmentations]
 
*Mike Halle: Slicer webinfrastructure and github
 
*Mike Halle: Slicer webinfrastructure and github
 
*Andrey Fedorov: DICOM objects for interoperability
 
*Andrey Fedorov: DICOM objects for interoperability
Line 65: Line 78:
 
*** user-level domain-specific applications
 
*** user-level domain-specific applications
 
** open question for discussion: should this functionality be in the core or extension
 
** 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

Latest revision as of 16:58, 10 July 2017

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)
    • 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