Difference between revisions of "Documentation/Labs/Slicer5-roadmap"

From Slicer Wiki
Jump to: navigation, search
Tag: 2017 source edit
 
(57 intermediate revisions by 5 users not shown)
Line 2: Line 2:
 
application, the API, or the code in a way that was not possible in the past seven or so years.
 
application, the API, or the code in a way that was not possible in the past seven or so years.
  
This page collects community suggestions related to the transition plan for Slicer 4.10 and major changes for Slicer 5.0.
+
This page collects community suggestions related to the transition plan for Slicer 4.10 and major changes for Slicer 5.x
  
 
Related forum post: https://discourse.slicer.org/t/slicer-5-0-deprecation-discussion-wiki/2377
 
Related forum post: https://discourse.slicer.org/t/slicer-5-0-deprecation-discussion-wiki/2377
  
== Overall Goals ==
+
==Overall Goals==
  
* Improve user experience
+
*Improve user experience
** More logical interface
+
**More logical interface
** Perform most common tasks easily
+
**Perform most common tasks easily
** Easier to discover advanced features
+
**Easier to discover advanced features
* Defining core and extensions
+
**Improve asynchronous behavior (like loading data in a background thread)
** Move some extensions to core (Sequences, DICOMPlugins...)
+
*Defining core and extensions
** Move some core to extensions (SimpleITK, Editor...)
+
**Core functionality is:
* Simplify maintenance
+
***DICOM and other format I/O, Subject management
** Remove legacy code that adds more complexity than value
+
***Visualization 2D/3D/4D
** Deprecate support for older build options and platforms (old libs, old compilers, etc)
+
***Segmentation
** Simplify documentation creation and use
+
***Transforms and Registration
** Streamline the build and release process
+
***Annotations and Markups
** Use unmodified upstream libraries
+
***Programmability and Extensibility
* Developer experience
+
**Move some extensions to core (Sequences, DICOMPlugins...)
** Improve API / Scripting documentation organization / search engine optimization
+
**Move some core to extensions (SimpleITK, Editor...)
** Simplify/accelerate build process on all platforms (options to use prebuilt sdk for example)
+
*Simplify maintenance
** Use standard packages (Qt, Python, VTK, ITK)
+
**Remove legacy code that adds more complexity than value
 +
**Deprecate support for older build options and platforms (old libs, old compilers, etc)
 +
**Simplify documentation creation and use
 +
**Streamline the build and release process
 +
**Use unmodified upstream libraries
 +
*Developer experience
 +
**Improve API / Scripting documentation organization / search engine optimization
 +
**Simplify/accelerate build process on all platforms (options to use prebuilt sdk for example)
 +
**Use standard packages (Qt, Python, VTK, ITK)
  
== Specific Change Proposals ==
+
<hr />
  
=== Python3 ===
+
==Specific Change Proposals==
 +
 
 +
===Slicer 5.0: Backward incompatible changes===
 +
 
 +
====Third-party library updates====
 +
 
 +
*Update to latest VTK: may fix issues in rendering (Virtual Reality Qt widget, [https://discourse.slicer.org/t/setting-of-markerstyle-does-not-work/9073/6 plot line markers])
 +
*Update to latest Qt: May fix [https://discourse.slicer.org/t/extension-wizard-file-open-dialogs-hang-ui-for-several-seconds/7881/9 Qt temporary hang] on startup and when showing file dialog
 +
 
 +
====Python3====
  
 
Switch to Python3 and use the same compiler as official Python distribution. This would allow installation of any Python package inside Slicer's Python environment.
 
Switch to Python3 and use the same compiler as official Python distribution. This would allow installation of any Python package inside Slicer's Python environment.
  
=== Slicer 5.0: Backward incompatible changes ===
+
Tasks:
  
==== SceneViews ====
+
*Update of CTK: Build system, CTK Python console and [https://github.com/commontk/CTK/blob/master/CMake/ctkWrapPythonQt.py ctkWrapPythonQt.py] - '''DONE''' {{done}}
 +
*Update [https://github.com/Slicer/Slicer/blob/master/SuperBuild/External_python.cmake External_python.cmake] - '''DONE''' {{done}}
 +
*Update of "C++ to python bridge" classes ([https://github.com/Slicer/Slicer/blob/master/Base/QTCore/qSlicerScriptedUtils_p.h qSlicerScriptedUtils_p.h], [https://github.com/Slicer/Slicer/blob/master/Base/QTGUI/qSlicerScriptedLoadableModule.h qSlicerScriptedLoadableModule.h], [https://github.com/Slicer/Slicer/blob/master/Base/QTGUI/qSlicerScriptedFileDialog.h qSlicerScriptedFileDialog.h], [https://github.com/Slicer/Slicer/blob/master/Base/QTGUI/qSlicerScriptedLoadableModuleWidget.h qSlicerScriptedLoadableModuleWidget.h], [https://github.com/Slicer/Slicer/blob/master/Base/QTCore/qSlicerScriptedFileWriter.h qSlicerScriptedFileWriter.h], ...) - '''DONE''' {{done}}
 +
*Update of install rules and macos fixup - '''DONE''' {{done}}
 +
*Update of python scripts to be compliant with python 3 - '''DONE''' {{done}}
  
The scene views feature does not work well for a long time now, and there is no consensus about what should be the scope it supports.
+
Some of the issues discovered after integration of Python 3:
 
 
Suggestion:
 
* Do not save the state of all nodes: Support only display, view and hierarchy nodes.
 
* Make SceneViews as stable as possible for these cases and remove support for data notes etc.
 
* If a node is removed, update associated scene views
 
  
==== Undo/Redo ====
+
*Fix iomodule.c build error with VS2017. See https://github.com/Slicer/Slicer/pull/1118#issuecomment-482436689. Fixed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=28138 r28138] - '''DONE''' {{done}}
Similarly to SceneViews, it is a great feature but in time it started breaking.
+
*Fix crash in Debug build. See https://github.com/lassoan/Slicer/tree/python-startup-hang-in-debug-mode. Fixed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=28141 r28141] - '''DONE''' {{done}}
Need to decide if we want to keep it, and if yes fix it.
+
*<tt>restart()</tt> Python function does not work. Fixed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=28143 r28143] - '''DONE''' {{done}}
  
Potential fix (currently being tested by Kyle Sunderland and Andras Lasso): Add an "undo enabled" flag to vtkMRMLNode, disable it by default, only enable it for nodes that undo/redo has tested to work correctly. Preliminary tests show that the feature largely works, but there are complications with undo/redo of node add/remove actions and node references.
+
References:
  
==== Removal of Charts based infrastructure ====
+
*discourse post: https://discourse.slicer.org/t/updating-slicer-to-work-with-python-3/4662/14
 +
*GitHub PR: https://github.com/Slicer/Slicer/pull/1118
  
With Slicer 5.0, the idea is to remove the [[Documentation/Nightly/Developers/Charts|Charts]] infrastructure based on jqPlot, and only keep
 
the [[Documentation/Nightly/Developers/Plots|Plots]] infrastructure based on VTK Charts.
 
  
==== Revisit MRML Copy API ====
+
====Revisit MRML Copy API====
  
 
Copy method does not perform complete deep-copy in some classes. For Sequences, we need both DeepCopy (for node modifications) and ShallowCopy (for fast replay possible).
 
Copy method does not perform complete deep-copy in some classes. For Sequences, we need both DeepCopy (for node modifications) and ShallowCopy (for fast replay possible).
Line 62: Line 77:
 
See also https://issues.slicer.org/view.php?id=2608.
 
See also https://issues.slicer.org/view.php?id=2608.
  
=== Remove deprecated modules and/or Migrate to extension ===
+
Assign to Andras Lasso. - '''DONE''' {{done}}
 +
 
 +
====Coordinate system in files====
 +
 
 +
To be consistent with the rest of the world: Save models and markups in LPS coordinate system by default. If no coordinate system is specified in input file, assume LPS. See https://issues.slicer.org/view.php?id=4445
 +
 
 +
====Acquisition transform====
 +
 
 +
Enable acquisition transform by default, to show correct loading of tilted gantry images. It has proven to work well.  See https://github.com/Slicer/Slicer/commit/b7650af3c27f34fc894bfdd587f2a4c02ba62a8b
 +
 
 +
====Model Hierarchies====
 +
 
 +
Remove Model Hierarchy feature and make sure that Subject Hierarchy covers all use cases.  This will impact ModelMaker, which should be converted to a simpler version that only returns models and not semantics.  Need to check extensions, especially SlicerDMRI, for any dependencies on Model Hierarchy. - '''DONE''' {{done}}
  
==== Editor ====
+
====Extension description file format====
 +
 
 +
Transition from [[Documentation/Nightly/Developers/Extensions/DescriptionFile|`.s4ext` text file]] to a json or yaml.
 +
 
 +
===Remove deprecated modules and/or Migrate to extension===
 +
 
 +
====Editor====
 
The module already directs users to Segment Editor, which provides all the functionality of Editor and more, and
 
The module already directs users to Segment Editor, which provides all the functionality of Editor and more, and
 
is the successor module that will be improved and maintained. Removing it would decrease confusion of both old
 
is the successor module that will be improved and maintained. Removing it would decrease confusion of both old
 
and new Slicer users
 
and new Slicer users
  
* Potentially the hack about modules with names ending with the string "Lib" can also be removed after the Editor module will not require it. It is [http://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/Base/QTCore/qSlicerUtils.cxx?r1=26891&r2=26890&pathrev=26891 around here].
+
*Potentially the hack about modules with names ending with the string "Lib" can also be removed after the Editor module will not require it. It is [http://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/Base/QTCore/qSlicerUtils.cxx?r1=26891&r2=26890&pathrev=26891 around here].
  
* '''Make Editor hidden in 4.10, advertise its removal (some extensions still use it), then remove it in 5.0'''. Remove it from toolbar, move Editor to legacy category in 4.10
+
*'''Make Editor hidden in 4.10, advertise its removal (some extensions still use it), then remove it in 5.0'''. Remove it from toolbar, move Editor to legacy category in 4.10
  
* Investigate if the module could easily be moved to an extension
+
*Investigate if the module could easily be moved to an extension
  
==== VectorToScalarVolume ====
+
====VectorToScalarVolume====
  
 
The plan would be to improve the Volume module so that vector volume could be converted to scalar volume, similarly to scalar to labelmap conversion option. Then, this module could be removed.
 
The plan would be to improve the Volume module so that vector volume could be converted to scalar volume, similarly to scalar to labelmap conversion option. Then, this module could be removed.
  
==== Unused module code ====
+
====Unused module code====
  
* <s>MultiVolumeRendering: A [https://github.com/Slicer/Slicer/tree/master/Modules/Loadable/MultiVolumeRendering module] that was effectively not developed since 2012, and is not currently compiled with Slicer.</s> - Removed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27087 r27087]
+
*<s>MultiVolumeRendering: A [https://github.com/Slicer/Slicer/tree/master/Modules/Loadable/MultiVolumeRendering module] that was effectively not developed since 2012, and is not currently compiled with Slicer.</s> - Removed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27087 r27087]
* <s>Measurements: Same argument as MultiVolumeRendering</s> - Removed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27087 r27087]
+
*<s>Measurements: Same argument as MultiVolumeRendering</s> - Removed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27087 r27087]
* <s>AtlasCreator Loadable module logic</s> - Removed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27088 r27088]
+
*<s>AtlasCreator Loadable module logic</s> - Removed in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27088 r27088]
  
==== CLI modules====
+
====CLI modules====
  
* Model to Label Map: Has too many limitations and bugs (cannot handle concave structures, can cause Slicer to hang or crash, etc.), and is not maintained any more. It might be better to remove it than to fix it, especially that there is an algorithm for the same thing in Slicer that works much better
+
*Model to Label Map: Has too many limitations and bugs (cannot handle concave structures, can cause Slicer to hang or crash, etc.), and is not maintained any more. It might be better to remove it than to fix it, especially that there is an algorithm for the same thing in Slicer that works much better
** The model node to labelmap node conversion feature could be added as a subject hierarchy plugin, if the route via segmentation node is not convenient enough
+
**The model node to labelmap node conversion feature could be added as a subject hierarchy plugin, if the route via segmentation node is not convenient enough
  
* Review CLI modules
+
*Review CLI modules
** BlobDetection
+
**BlobDetection
** ConnectedComponent
+
**ConnectedComponent
** GrayscaleModelMaker, ModelMaker: The modules are too different to combine them. Each have specific use cases.
+
**GrayscaleModelMaker, ModelMaker: The modules are too different to combine them. Each have specific use cases.
** DiffusionTensorTest, ROITest, TestGridTransformRegistration: Already excluded from package by specifying <tt>NO_INSTALL</tt>
+
**DiffusionTensorTest, ROITest, TestGridTransformRegistration: Already excluded from package by specifying <tt>NO_INSTALL</tt>
** Resample Scalar Volume: Resample Scalar/Vector/DWI Volume module (which Crop Volume uses as well) can do everything it does already, except for four extra interpolation options. Probably can be removed
+
**Resample Scalar Volume: Resample Scalar/Vector/DWI Volume module (which Crop Volume uses as well) can do everything it does already, except for four extra interpolation options. Probably can be removed
  
==== Migrate to extension ====
+
====Migrate to extension====
  
 
Existing [https://github.com/Slicer/Slicer/blob/master/Modules/Scripted/DMRIInstall/DMRIInstall.py DMRIInstall] scripted module will be re-factored and moved into a <tt>Modules/Scripted/InstallSuggestions</tt> directory.
 
Existing [https://github.com/Slicer/Slicer/blob/master/Modules/Scripted/DMRIInstall/DMRIInstall.py DMRIInstall] scripted module will be re-factored and moved into a <tt>Modules/Scripted/InstallSuggestions</tt> directory.
Line 103: Line 136:
 
Then, after transitioning them to extension, the following module will be added to the "InstallSuggestions" so that the user knows how to install them:
 
Then, after transitioning them to extension, the following module will be added to the "InstallSuggestions" so that the user knows how to install them:
  
* BRAINSTools (also add SlicerElastix to the suggestions)
+
*BRAINSTools (also add SlicerElastix to the suggestions)
* SimpleITK: Only used in the editor
+
*SimpleITK: Only used in the editor
* EMSegment: already disabled in Slicer-4.10, so it may be completely removed from build scripts instead of moving it to an extension
+
*EMSegment: already disabled in Slicer-4.10, so it may be completely removed from build scripts instead of moving it to an extension
 +
 
 +
Notes:
 +
 
 +
*2018-12-13: Jc: Following discussion with Ron, we need to make sure to have at least one non-rigid registration method and one ICP based method (e.g Landmark Registration) available in the main distribution.
 +
 
 +
====PETStandardUptakeValueComputation====
 +
 
 +
Remove PETStandardUptakeValueComputation from Slicer core, as a more advanced version of this is available in an extension: https://github.com/QIICR/Slicer-PETDICOMExtension. See details here: https://github.com/Slicer/Slicer/pull/1068#issuecomment-450905887
  
=== Coding Style===
+
===Coding Style===
  
==== Slicer 5.0: Indentation of curly braces ====
+
====Slicer 5.0: Indentation of curly braces====
 
In Slicer the curly braces have a two-space indentation everywhere within functions. As this was inherited from VTK, but VTK changed its convention to align the braces with the statements (if etc.), it could make sense to make the change in Slicer too. This is considered a major change because it affects almost all cxx files.
 
In Slicer the curly braces have a two-space indentation everywhere within functions. As this was inherited from VTK, but VTK changed its convention to align the braces with the statements (if etc.), it could make sense to make the change in Slicer too. This is considered a major change because it affects almost all cxx files.
  
==== Simpler VTK smart pointer usage ====
+
====Simpler VTK smart pointer usage====
 
Use <code>vtkNew<type> var;</code> instead of <code>vtkSmartPointer<type> var = vtkSmartPointer<type>::New();</code> and remove now unnecessary <code>.GetPointer()</code> calls.
 
Use <code>vtkNew<type> var;</code> instead of <code>vtkSmartPointer<type> var = vtkSmartPointer<type>::New();</code> and remove now unnecessary <code>.GetPointer()</code> calls.
  
=== Miscellaneous ===
+
===Usability===
  
==== Tcl codes ====
+
====Volume Rendering Activation Method====
 +
 
 +
We have had lots of issues with people finding the eye icon.
 +
 
 +
===Miscellaneous===
 +
 
 +
====Tcl codes====
 
<s>Most of the TCL code seems to be a heritage from Slicer3. Can they be removed?</s> - Done in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27091 r27091]
 
<s>Most of the TCL code seems to be a heritage from Slicer3. Can they be removed?</s> - Done in [http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27091 r27091]
  
==== Remove self-test modules from the All modules list ====
+
====Remove self-test modules from the All modules list====
Users already find the all modules list very long, and as the self tests are for developers only (and can be found in the modules list under the Testing category), they could be removed from the list.
+
Users already find the all modules list very long, and as the self tests are for developers only (and can be found in the modules list under the Testing category), they could be removed from the list.  Make sure they are available in Developer mode.
  
==== Remove BTX/ETX pairs ====
+
====Remove BTX/ETX pairs====
 
Once VTK7 is no longer supported, the old way for disabling python wrapping is no longer needed. According to my tests (Csaba), wrapping works fine in all of those cases, so the new way (#ifndef __VTK_WRAP__) is not needed either.
 
Once VTK7 is no longer supported, the old way for disabling python wrapping is no longer needed. According to my tests (Csaba), wrapping works fine in all of those cases, so the new way (#ifndef __VTK_WRAP__) is not needed either.
  
== Additional proposed changes to be discussed ==
+
===Slicer 5.2: Backward incompatible changes===
 +
 
 +
====Build System Simplification====
 +
 
 +
*Pick the most recent reasonable CMake version and remove any complexities in the build system are only there to work around limitations of old CMake versions.
 +
 
 +
*Consider any ways to streamline/simplify the configure and build process, even it if may require changing extensions.
 +
 
 +
*Look for ways to minimize the effect of long directory path-related build issues.  Currently on mac and windows we are pushing the limit of path length unless very short paths are used (e.g. /s5 or d:\s5).  Reorganizing the build tree might give us more headroom.
 +
 
 +
====Remove remote data support from MRML====
 +
 
 +
MRML theoretically supports downloading files through http, but this feature has not seen much use. This will not likely to change in the future because there is a wide range of data access and authentication protocols, which would not be practical at MRML level.
 +
 
 +
It would be better to remove remote data support from MRML to simplify data storage. We can keep useful utility classes, such as cache manager for keeping track of local temporary files (downloaded using SampleData or other modules that download significant amount of temporary data).
 +
 
 +
See also https://discourse.slicer.org/t/improving-testing-data-management-for-self-test/5014/4.
 +
 
 +
====Improve layout manager====
 +
 
 +
*Support multiple displays: Currently, it is very hard to leverage multiple displays (need to stretch the Slicer window over multiple screens and align splitter manually to the screen boundary). Allow defining single-display and multi-display layouts. Single-display layouts could be selected for each display independently, while multi-monitor layouts would set views on several displays at once. Keeping a single layout manager (and enhance it with to allow creation of multiple widgets) would make it easier to maintain backward compatibility for existing modules.
 +
*View layout IDs: View layout IDs are currently integer values, which makes it difficult to ensure that modules always choose unique IDs. We should switch to using string IDs. String IDs can may be prefixed with modulename+"." as we do it for singleton tags and node attributes. We may remain somewhat backward compatible by having SetLayoutID(int) method that maps known layout integer IDs to the new string IDs. See discussion here: https://github.com/Slicer/Slicer/pull/1061#discussion_r241825827
 +
 
 +
====SceneViews====
 +
 
 +
The scene views feature does not work well for a long time now, and there is no consensus about what should be the scope it supports.
 +
 
 +
Suggestion:
 +
 
 +
*Do not save the state of all nodes: Support only display, view and hierarchy nodes.
 +
*Make SceneViews as stable as possible for these cases and remove support for data notes etc.
 +
*If a node is removed, update associated scene views
 +
 
 +
Notes:
 +
 
 +
*2018-12-13: Jc: Following discussion with Ron, we should keep the SceneView functionality. All data should be associated with the "master" view, and scene view should be different combination of viewing parameters (layout, camera, visibility, etc ...). A mrb to consider for testing is the [http://slicer.kitware.com/midas3/slicerdatastore/view?itemId=126553&layout=layout LungSegments_scene.mrb]
 +
*Another suggestion from Sonia is that SceneViews could be read-only for certain classes of nodes.  It's not clear how that would be implemented, but it could address the instability problems while enabling the use of SceneViews for training.
 +
 
 +
====Undo/Redo====
 +
Similarly to SceneViews, it is a great feature but in time it started breaking.
 +
Need to decide if we want to keep it, and if yes fix it.
 +
 
 +
Potential fix (currently being tested by Kyle Sunderland and Andras Lasso): Add an "undo enabled" flag to vtkMRMLNode, disable it by default, only enable it for nodes that undo/redo has tested to work correctly. Preliminary tests show that the feature largely works, but there are complications with undo/redo of node add/remove actions and node references.
 +
 
 +
Notes:
 +
 
 +
*2018-12-13: Jc: Following discussion with Ron, would be nice to also have undo/redo for camera settings, field of view, etc ... within a given view. It is easy to inadvertently modify settings ... (e.g when trying to pan using a trackpad with shift+left click but inadvertently using only left click)
 +
 
 +
====Removal of Charts based infrastructure====
 +
 
 +
With Slicer 5.0, the idea is to remove the [[Documentation/Nightly/Developers/Charts|Charts]] infrastructure based on jqPlot, and only keep
 +
the [https://slicer.readthedocs.io/en/latest/user_guide/modules/plots.html Plots] infrastructure based on VTK Charts.
 +
Ron's request: enable anti-aliasing (MSAA or FXAA) and use less subtle default colors (https://www.slicer.org/wiki/Slicer4:2012_GenericChartColors) to improve appearance.
 +
 
 +
==Additional proposed changes to be discussed==
  
- Bundle IPython package in Slicer installer
+
*Bundle IPython package in Slicer installer - Slicer Jupyter extension has been added, do we need more?
- [https://discourse.slicer.org/t/add-slicer-nightly-to-homebrew-macos/811 Install using brew]
+
**Do we want history across sessions?
 +
**Quick access to script repository
 +
*[https://discourse.slicer.org/t/add-slicer-nightly-to-homebrew-macos/811 Install using brew]
 +
*Add opt-in collection of usage statistics for various features (e.g. could be triggered when a module is entered).
 +
*Enable geometry correction by default (e.g. gantry tilt as [https://discourse.slicer.org/t/actual-size-of-stl-models/5005/21 discussed here]).
 +
*Remove legacy 1.0 pydicom and only bundle latest (see https://pydicom.github.io/pydicom/stable/transition_to_pydicom1.html#).  Import name changed from 'dicom' to 'pydicom' (See also: https://github.com/Slicer/Slicer/pull/1231)
 +
*Remove DICOM Networking (DIMSE) code https://discourse.slicer.org/t/dicom-retrieve-on-windows-10-there-is-no-service-listening-dicom-communications-no-telnet-connection-to-ports
 +
*Update the logo along [https://discourse.slicer.org/t/slicer-module-panel-icon-in-dark-mode/8353/3 as discussed here].

Latest revision as of 22:19, 17 April 2022

Home < Documentation < Labs < Slicer5-roadmap

The major version number upgrade to 5 provides an opportunity to make changes that affect the application, the API, or the code in a way that was not possible in the past seven or so years.

This page collects community suggestions related to the transition plan for Slicer 4.10 and major changes for Slicer 5.x

Related forum post: https://discourse.slicer.org/t/slicer-5-0-deprecation-discussion-wiki/2377

Overall Goals

  • Improve user experience
    • More logical interface
    • Perform most common tasks easily
    • Easier to discover advanced features
    • Improve asynchronous behavior (like loading data in a background thread)
  • Defining core and extensions
    • Core functionality is:
      • DICOM and other format I/O, Subject management
      • Visualization 2D/3D/4D
      • Segmentation
      • Transforms and Registration
      • Annotations and Markups
      • Programmability and Extensibility
    • Move some extensions to core (Sequences, DICOMPlugins...)
    • Move some core to extensions (SimpleITK, Editor...)
  • Simplify maintenance
    • Remove legacy code that adds more complexity than value
    • Deprecate support for older build options and platforms (old libs, old compilers, etc)
    • Simplify documentation creation and use
    • Streamline the build and release process
    • Use unmodified upstream libraries
  • Developer experience
    • Improve API / Scripting documentation organization / search engine optimization
    • Simplify/accelerate build process on all platforms (options to use prebuilt sdk for example)
    • Use standard packages (Qt, Python, VTK, ITK)

Specific Change Proposals

Slicer 5.0: Backward incompatible changes

Third-party library updates

  • Update to latest VTK: may fix issues in rendering (Virtual Reality Qt widget, plot line markers)
  • Update to latest Qt: May fix Qt temporary hang on startup and when showing file dialog

Python3

Switch to Python3 and use the same compiler as official Python distribution. This would allow installation of any Python package inside Slicer's Python environment.

Tasks:

Some of the issues discovered after integration of Python 3:

References:


Revisit MRML Copy API

Copy method does not perform complete deep-copy in some classes. For Sequences, we need both DeepCopy (for node modifications) and ShallowCopy (for fast replay possible).

There are also too many variants of node copy methods, which makes it difficult to use them correctly.

See also https://issues.slicer.org/view.php?id=2608.

Assign to Andras Lasso. - DONE Check.svg

Coordinate system in files

To be consistent with the rest of the world: Save models and markups in LPS coordinate system by default. If no coordinate system is specified in input file, assume LPS. See https://issues.slicer.org/view.php?id=4445

Acquisition transform

Enable acquisition transform by default, to show correct loading of tilted gantry images. It has proven to work well. See https://github.com/Slicer/Slicer/commit/b7650af3c27f34fc894bfdd587f2a4c02ba62a8b

Model Hierarchies

Remove Model Hierarchy feature and make sure that Subject Hierarchy covers all use cases. This will impact ModelMaker, which should be converted to a simpler version that only returns models and not semantics. Need to check extensions, especially SlicerDMRI, for any dependencies on Model Hierarchy. - DONE Check.svg

Extension description file format

Transition from `.s4ext` text file to a json or yaml.

Remove deprecated modules and/or Migrate to extension

Editor

The module already directs users to Segment Editor, which provides all the functionality of Editor and more, and is the successor module that will be improved and maintained. Removing it would decrease confusion of both old and new Slicer users

  • Potentially the hack about modules with names ending with the string "Lib" can also be removed after the Editor module will not require it. It is around here.
  • Make Editor hidden in 4.10, advertise its removal (some extensions still use it), then remove it in 5.0. Remove it from toolbar, move Editor to legacy category in 4.10
  • Investigate if the module could easily be moved to an extension

VectorToScalarVolume

The plan would be to improve the Volume module so that vector volume could be converted to scalar volume, similarly to scalar to labelmap conversion option. Then, this module could be removed.

Unused module code

  • MultiVolumeRendering: A module that was effectively not developed since 2012, and is not currently compiled with Slicer. - Removed in r27087
  • Measurements: Same argument as MultiVolumeRendering - Removed in r27087
  • AtlasCreator Loadable module logic - Removed in r27088

CLI modules

  • Model to Label Map: Has too many limitations and bugs (cannot handle concave structures, can cause Slicer to hang or crash, etc.), and is not maintained any more. It might be better to remove it than to fix it, especially that there is an algorithm for the same thing in Slicer that works much better
    • The model node to labelmap node conversion feature could be added as a subject hierarchy plugin, if the route via segmentation node is not convenient enough
  • Review CLI modules
    • BlobDetection
    • ConnectedComponent
    • GrayscaleModelMaker, ModelMaker: The modules are too different to combine them. Each have specific use cases.
    • DiffusionTensorTest, ROITest, TestGridTransformRegistration: Already excluded from package by specifying NO_INSTALL
    • Resample Scalar Volume: Resample Scalar/Vector/DWI Volume module (which Crop Volume uses as well) can do everything it does already, except for four extra interpolation options. Probably can be removed

Migrate to extension

Existing DMRIInstall scripted module will be re-factored and moved into a Modules/Scripted/InstallSuggestions directory.

Then, after transitioning them to extension, the following module will be added to the "InstallSuggestions" so that the user knows how to install them:

  • BRAINSTools (also add SlicerElastix to the suggestions)
  • SimpleITK: Only used in the editor
  • EMSegment: already disabled in Slicer-4.10, so it may be completely removed from build scripts instead of moving it to an extension

Notes:

  • 2018-12-13: Jc: Following discussion with Ron, we need to make sure to have at least one non-rigid registration method and one ICP based method (e.g Landmark Registration) available in the main distribution.

PETStandardUptakeValueComputation

Remove PETStandardUptakeValueComputation from Slicer core, as a more advanced version of this is available in an extension: https://github.com/QIICR/Slicer-PETDICOMExtension. See details here: https://github.com/Slicer/Slicer/pull/1068#issuecomment-450905887

Coding Style

Slicer 5.0: Indentation of curly braces

In Slicer the curly braces have a two-space indentation everywhere within functions. As this was inherited from VTK, but VTK changed its convention to align the braces with the statements (if etc.), it could make sense to make the change in Slicer too. This is considered a major change because it affects almost all cxx files.

Simpler VTK smart pointer usage

Use vtkNew<type> var; instead of vtkSmartPointer<type> var = vtkSmartPointer<type>::New(); and remove now unnecessary .GetPointer() calls.

Usability

Volume Rendering Activation Method

We have had lots of issues with people finding the eye icon.

Miscellaneous

Tcl codes

Most of the TCL code seems to be a heritage from Slicer3. Can they be removed? - Done in r27091

Remove self-test modules from the All modules list

Users already find the all modules list very long, and as the self tests are for developers only (and can be found in the modules list under the Testing category), they could be removed from the list. Make sure they are available in Developer mode.

Remove BTX/ETX pairs

Once VTK7 is no longer supported, the old way for disabling python wrapping is no longer needed. According to my tests (Csaba), wrapping works fine in all of those cases, so the new way (#ifndef __VTK_WRAP__) is not needed either.

Slicer 5.2: Backward incompatible changes

Build System Simplification

  • Pick the most recent reasonable CMake version and remove any complexities in the build system are only there to work around limitations of old CMake versions.
  • Consider any ways to streamline/simplify the configure and build process, even it if may require changing extensions.
  • Look for ways to minimize the effect of long directory path-related build issues. Currently on mac and windows we are pushing the limit of path length unless very short paths are used (e.g. /s5 or d:\s5). Reorganizing the build tree might give us more headroom.

Remove remote data support from MRML

MRML theoretically supports downloading files through http, but this feature has not seen much use. This will not likely to change in the future because there is a wide range of data access and authentication protocols, which would not be practical at MRML level.

It would be better to remove remote data support from MRML to simplify data storage. We can keep useful utility classes, such as cache manager for keeping track of local temporary files (downloaded using SampleData or other modules that download significant amount of temporary data).

See also https://discourse.slicer.org/t/improving-testing-data-management-for-self-test/5014/4.

Improve layout manager

  • Support multiple displays: Currently, it is very hard to leverage multiple displays (need to stretch the Slicer window over multiple screens and align splitter manually to the screen boundary). Allow defining single-display and multi-display layouts. Single-display layouts could be selected for each display independently, while multi-monitor layouts would set views on several displays at once. Keeping a single layout manager (and enhance it with to allow creation of multiple widgets) would make it easier to maintain backward compatibility for existing modules.
  • View layout IDs: View layout IDs are currently integer values, which makes it difficult to ensure that modules always choose unique IDs. We should switch to using string IDs. String IDs can may be prefixed with modulename+"." as we do it for singleton tags and node attributes. We may remain somewhat backward compatible by having SetLayoutID(int) method that maps known layout integer IDs to the new string IDs. See discussion here: https://github.com/Slicer/Slicer/pull/1061#discussion_r241825827

SceneViews

The scene views feature does not work well for a long time now, and there is no consensus about what should be the scope it supports.

Suggestion:

  • Do not save the state of all nodes: Support only display, view and hierarchy nodes.
  • Make SceneViews as stable as possible for these cases and remove support for data notes etc.
  • If a node is removed, update associated scene views

Notes:

  • 2018-12-13: Jc: Following discussion with Ron, we should keep the SceneView functionality. All data should be associated with the "master" view, and scene view should be different combination of viewing parameters (layout, camera, visibility, etc ...). A mrb to consider for testing is the LungSegments_scene.mrb
  • Another suggestion from Sonia is that SceneViews could be read-only for certain classes of nodes. It's not clear how that would be implemented, but it could address the instability problems while enabling the use of SceneViews for training.

Undo/Redo

Similarly to SceneViews, it is a great feature but in time it started breaking. Need to decide if we want to keep it, and if yes fix it.

Potential fix (currently being tested by Kyle Sunderland and Andras Lasso): Add an "undo enabled" flag to vtkMRMLNode, disable it by default, only enable it for nodes that undo/redo has tested to work correctly. Preliminary tests show that the feature largely works, but there are complications with undo/redo of node add/remove actions and node references.

Notes:

  • 2018-12-13: Jc: Following discussion with Ron, would be nice to also have undo/redo for camera settings, field of view, etc ... within a given view. It is easy to inadvertently modify settings ... (e.g when trying to pan using a trackpad with shift+left click but inadvertently using only left click)

Removal of Charts based infrastructure

With Slicer 5.0, the idea is to remove the Charts infrastructure based on jqPlot, and only keep the Plots infrastructure based on VTK Charts. Ron's request: enable anti-aliasing (MSAA or FXAA) and use less subtle default colors (https://www.slicer.org/wiki/Slicer4:2012_GenericChartColors) to improve appearance.

Additional proposed changes to be discussed