View source for Documentation/Nightly/Developers/FAQ/General

<noinclude>{{documentation/versioncheck}}</noinclude>
<noinclude>__TOC__
={{#titleparts: {{PAGENAME}} | | -1 }}=</noinclude><includeonly>
='''Developer FAQ: {{{1}}}'''=
</includeonly>

== What is Slicer ? ==

{{:Documentation/{{documentation/version}}/Developers/Slicer}}

== How can I get help debugging my code? ==

You can post questions to the [[Help|developer mailing list]].  

Please consider:
* Review the mailing list archives for similar questions
* If you ask a coding question, try to use a [http://sscce.org/ Short Self-Contained Correct Example]
* It's a friendly community but people are busy so if you get a terse response don't take it personally :-)

== How to setup for Git development ? ==
See [[Documentation/{{documentation/version}}/Developers/DevelopmentWithGit#Slicer Setup | Slicer Setup ]]

== How to contribute a patch ? ==
{{:Documentation/{{documentation/version}}/Developers/Tutorials/ContributePatch}}


== What is our bug / feature request workflow ? ==

{{:Documentation/{{documentation/version}}/Developers/IssueWorkflow}}


== How to schedule a Developer Hangout ? ==
See instruction [[Developer_Meetings/OrganizerInstruction|here]]


== Should core feature be implemented in C++ or Python ? ==

There is no one-size-fits-all answer to this.  There are many examples of "core' features of Slicer implemented using a variety of programming languages and techniques.

* MRML and most Logic operations are in C++, implemented as VTK subclasses
* the Application and most GUI functionality is in C++, implemented as QWidget subclasses
* most bundled modules are implemented as "loadable" modules, combining VTK and Qt parent classes
* many important modules bundled with Slicer are implemented as python scripted modules (LabelStatistics, ExtensionWizard...) or with hybrid C++ and Python solutions (Editor, DICOM, DataProbe...)
* other "core" features rely on JavaScript and web technologies (Charts, SceneViews, Extension Manager....)

The implementation choice depends heavily on the use case and the best judgement of the people who commit to maintain the code.  If you are contributing an extension that you will maintain, you have a lot of flexibility.  If you are hoping to pass off your code to others and you expect them to maintain it, then you should carefully follow the example of similar code that is already being maintained so that your code will be a pleasure to work with and not a misfit that causes trouble.


Original comment from Andras Lasso copied from [https://github.com/Slicer/Slicer/pull/373#issuecomment-146894971 PR#373] discussion.


There are many reasons for implementing Slicer core in C++, we just list here few reasons:

* C++ rigor and extensive compile-time checks increases the chance of catching errors earlier. C++ enforces many things that in Python are managed by good programming practices (that are not enforced and in general not followed by Slicer developers).

* C++ memory management is much more explicit, which is more difficult to learn than Python, but allows much better efficiency (you can prevent memory fragmentation, optimize memory reallocations, etc), which is useful for code that may run hundreds of times per second (this code does).

* There are lots of good examples of solid, fast C++ displayable managers. Python displayable managers are more at the experimental level.

* Accessibility of Python classes from C++ modules is cumbersome. Accessibility of C++ classes is very convenient from both Python and C++ modules.

* Some projects don't use Python and don't want to use it (Python brings in huge amount of additional code, which is a problem if you want to minimize the amount of code that goes through regulatory approval)

* Profiling and optimization of mixed C++/Python code is very difficult (both C++ and Python profilers treat the "other side" as black hole). Since all the rest of the Slicer core is implemented in C++ (with a few small exceptions), it is much easier to implement this in C++, too.


That said, we love Python programming, do it extensively, but implementing Slicer core features in Python has just too many disadvantages.

== How to convert between ITK images and Slicer scalar volume nodes? ==

See discussion and relevant links at http://slicer-devel.65872.n3.nabble.com/Converting-ITK-image-to-Slicer-ScalarVolumeNode-td4035458.html

Steve Pieper's suggested architecture for using ITK code to process Slicer MRML data is as follows:

1) develop an ITK pipeline that implements the desired behavior

2) wrap the pipeline in a high level pure C++ ITK class that exposes the key inputs, output, parameters, and events

3) write a thin CLI wrapper around (2) using the Slicer Execution mode

4a) use the CLI in Slicer as-is

4b) write a scripted module that presents a higher level interface and calls the CLI

4c) if you need more interactivity, write a vtkITK wrapper around (2) that exposes the high level ITK class aspects using VTK conventions; expose this via a scripted or loadable module.

A nice thing about this approach is that (1) through (3) are all highly reusable in different contexts both in and out of Slicer.

Also this path, steps (1) through (4b) all the data types and orientation mappings between itk::Image and vtkMRMLScalarVolumeNode are handled automatically with existing mechanisms.  Since the CLI is built as a shared library by default there is no file system overhead, just a few memcpys which is not much different than using the ITK pipeline directly.

Another option is to implement the pipeline in SimpleITK, but adding custom C++ code into the SimpleITK is more complex and I don't think it's even possible to do this as an extension, whereas the path described above is completely compatible with our extension process.

Note that the use case for the code that Raul points to is the opposite case, using a VTK class inside of an ITK pipeline.  In this case ITKVtkGlue is very appropriate.  The IJKToRAS transforms are not relevant since vtkImageData class does not support orientation and all the operations need to be performed in pixel space.

If CLI route is not suitable for some reason, helper classes are available in SlicerRT that do conversion between itkImage and vtkMRMLScalarVolumeNode initializing IJKtoRAS matrix, see https://github.com/SlicerRt/SlicerRT/blob/master/SlicerRtCommon/SlicerRtCommon.h

== What is the difference between Slicer Plot and Chart ? ==

Slicer has two plotting infrastructures: Plot and Chart. The first is a pure C++ environment built on the top of VTKPlots [https://www.slicer.org/wiki/Documentation/Nightly/Developers/Plots]. 
The second is developed in C++ as well (MRML, Widgets) and it wraps and uses a JavaScript library, jqPlot, for the rendering [https://www.slicer.org/wiki/Documentation/Nightly/Developers/Charts].  

<br>
Although the two infrastructures may look similar and duplicate of each other, there have both major advantages (which it makes worth to bundle Slicer with both): 
* Charts have more capabilities for bar plots (categorical, etc.) and the rendering is of better quality (i.e., ready for publication).
* Plots are connected with vtkTables and therefore with the Table Module [https://www.slicer.org/wiki/Documentation/Nightly/Modules/Tables]. In Addition, Plots have more interactive capabilities (e.g., data selection, click and drag) and show faster performance for N (number of points) > 10^5 (i.e., useful for data exploration).