Commontk - User contributions [en]

Documentation/CLI In Context

2015-02-15T06:36:29Z

Hans Meine: mention MeVisLab integration in NA-MIC summer project week 2013

This page lists some example and notes on different integration of CLI modules in different frameworks including CTK (see [[Documentation/Command_Line_Interface]] for a general overview of CLI modules). The first interoperability testing was done during the [http://www.creatis.insa-lyon.fr/Interoperability_workshop third] VPH NoE Imaging workshop hold in Lyon, France on October 22-23, 2012. It will be continued in consecutive hackfests. The aim is to try to plug in CLI modules in CLI compatible frameworks and come up with possible improvement of the CLI standard, advice to CLI module and CLI framework developers.

== Events ==

* [[CTK-Hackfest-Nov-2011|CTK Hackfest]] in Sophia Antipolis, France in November 2011
** Preliminary work to integrate CLI into GIMIAS
* [[CTK-Hackfest-Jul-2012|CTK Hackfest]] in Boston, USA in July 2012
** Preliminary work to integrate CLI into MITK
* [http://www.creatis.insa-lyon.fr/Interoperability_workshop 3rd VPH NoE Imaging workshop] in Lyon, France on October 22-23, 2012
** [[#First_Interoperability_tests|First Interoperability tests]] with CTK, GIMIAS, NiftyView and Slicer
* [[CTK-Hackfest-Dec-2012|CTK Hackfest]] in Bologna, Italy on December, 2012
** Preliminary work to integrate CLI into medInria, MAF3
** Semi-Automatic framework CLI integration tests
* [http://www.na-mic.org/Wiki/index.php/2013_Summer_Project_Week NA-MIC summer project week]
** [http://www.na-mic.org/Wiki/index.php/2013_Summer_Project_Week:CLI_modules_in_MeVisLab Integration of CLI modules into MeVisLab]
* [[CTK-Hackfest-Nov-2013|CTK Hackfest]] in London, UK on November, 2013
** [[#Second_Interoperability_tests|Second Interoperability tests]]: GIMIAS's Command Line Plugins in CTK's Command Line Module Explorer, CTK's Command Line Modules in Taverna Workbench

== First Interoperability tests ==

These first tests mainly concern the integration of niftyreg (registration algorithms from UCL). The different stages of integration are: load, execute and results. Meaning that the CLI module can be loaded. executed and provides the same results as if it was run only from the command line. The problems we encountered were:

* GIMIAS does not support to have a `default` element different that `None` for the output, not sure about the `advanced` option for the `parameters` element
* niftyreg was using `fileExtensions` with stars (`*.nii`) which is not supported by neither GIMIAS nor Slicer (the star is directly used in the file name)
* The default output folder should be set to the user folder and not the running one, otherwise the CLI module can crash because they were denied access to write in that folder (for example `Program Files` under Windows)
* What to do with CLI modules that have dependencies on shared libraries with the platform but of different versions? Platforms should have the option to only use the libraries shipped with the CLI module
* Platforms should align the way they treat data since if two load data differently, the same CLI module could give different results

It would be interesting to create test CLI modules for these integration tests. For example one that exposes all possible types of options, one running a simple algorithm without any dependencies (as niftyreg) and one with dependencies.

Some thoughts on the tested platforms:
* Niftyview has nice controls on the way CLI modules are found and loaded (control on the `XML` validation)
* Slicer has a nice display of the loaded and non loaded CLI modules (appear in red, there could be more explanation why the loading failed)

Test datasets:

The test datasets [https://drive.google.com/file/d/0B3kBRNGHGeP0bGFjZlZNcHJLNEU/edit?usp=sharing source_2down.nii] and [https://drive.google.com/file/d/0B3kBRNGHGeP0N2gzZTVYV2JTX28/edit?usp=sharing target_2down.nii] were obtained from [http://brainweb.bic.mni.mcgill.ca/brainweb BrainWeb] and [http://adni.loni.usc.edu/ ADNI].

Here are the snapshots of niftyreg on the different platforms (collected over many events):

<gallery caption="niftyreg on the different platforms" widths="400px" heights="300px" perrow="3">
Image:Niftyreg-ctk.png|CTK command line module explorer
Image:Niftyreg-slicer.png|3D Slicer
Image:Niftyreg-niftyview.png|NiftyView (based on MITK Workbench)
Image:Niftyreg-gimias.png|GIMIAS
Image:medinria-cli-niftyreg.png|MedInria
Image:Niftyreg-MeVisLab.png|MeVisLab (see [https://www.youtube.com/watch?v=FSCrmiWEcbA screencast])
Image:Niftyreg-MITK-Workbench.png|MITK Workbench
</gallery>

== Second Interoperability tests ==

* GIMIAS's Command Line Plugins in CTK's Command Line Module Explorer

This interoperability test was done under Windows 8. Similar steps can be performed in other platforms.

Typically, GIMIAS's Command Line Plugins (CLPs) are located in folder '''<GIMIAS_install_dir>\commandLinePlugins'''. However, the DLL dependencies of these CLPs are located in '''<GIMIAS_install_dir>'''. This is a problem when attempting to use GIMIAS's CLPs in CTK's Command Line Module Explorer (CLME), as the CLME will fail to load the CLPs.

This can be easily solved by copying GIMIAS's CLPs in a different folder, let's say '''<CLP_folder>''', along with its DLL dependencies (for finding out the DLL dependencies of a CLP, a program such as [http://dependencywalker.com/ Dependency Walker] can be used).

After creating '''<CLP_folder>''' and copying the necessary files in it. Start CTK's CLME, go to menu "Module" and choose "Options". In "Module Settings" go to "Search Paths", and then add '''<CLP_folder>''' to the search paths. Press "OK" and the CLME will scan '''<CLP_folder>''' and load the CLPs.

If the loading process fails, you are probably missing a DLL dependency, close the CLME and go to the cache folder ('''<user_directory>\AppData\Local\CommonTK\CommandLineModuleExplorer\cache''' on MS Windows). Clear the content of that directory, add the additional DLL to '''<CLP_folder>''' and then start the CLME again.

If a CLP shows up in the list with a warning sign, place the mouse on top of the CLP's name and look at the warning message. Most likely the XML that defines the CLP has a compatibility problem with the CLME, which means that is does not adhere to the [http://www.commontk.org/docs/html/ctkCmdLineModule.xsd CTK XML Schema]. See the definition of the Schema, correct the XML of the CLP, clear CLME's cache folder as described in the previous paragraph, and start the CLME again.

After following these steps, you will be able to see and use your CLP in the CLME. '''This means that you can share your GIMIAS's CLP with any CTK user at any time, by just sharing your CLPs executable file and its DLL dependencies'''.

The following image shows GIMIAS's CLPs loaded in CTK's CLME. The "Create a DICOM Series" CLP is selected. The "Settings" dialog is also shown, indicating how to add the CLPs directory to the CLME's search paths. Notice that some CLPs are shown with a warning sign, so their XML definitions has to be corrected.

[[File:GIMIAS_CLPs_on_CTK_CLME.png|400px]]

* CTK's Command Line Modules in Taverna Workbench

[http://www.taverna.org.uk/download/workbench/ Taverna Workbench] is an open source Workflow Management System written in Java. GIMIAS's Command Line Plugins (CLPs) can be used in Taverna Workbench for creating medical imaging workflows composed of several filters. In order to be able to do this, the '''Center Computational Imaging and Simulation Technologies in Biomedicine (CISTIB)''' at the [http://www.shef.ac.uk/ University of Sheffield] has created a Taverna Workbench plugin for GIMIAS.

General instructions on how to install GIMIAS Command-Line Taverna Plugin can be found [https://drive.google.com/file/d/0B3kBRNGHGeP0dE53THFMYjdsdDQ/edit?usp=sharing here].

In this interoperability test, a CTK Command Line Module was created and tested with GIMIAS Command-Line Taverna Plugin. The sample plugin is called '''CopyPlugin'''. It is a simple code to open a VTK ASCII file containing a PolyData, and save the contents of the file on another VTK file. The plugin code can be accessed [https://drive.google.com/file/d/0B3kBRNGHGeP0bVZVWHZkS1NydnM/edit?usp=sharing here].

The result was successful, which means that '''GIMIAS's CLPs and CTK's Command Line Modules can be combined to create processing workflows in Taverna Workbench !!'''.

The following image shows the CopyPlugin running on CTK's Command Line Module Explorer.

[[File:COPYPLUGIN_CTK_CLME.png‎|400px]]

The CopyPlugin Command Line Module Explorer can also be imported into GIMIAS, see the following image

[[File:COPYPLUGIN_CTK_GIMIAS.png|400px]]

The following image shows a simple workflow that includes the CopyPlugin, after being imported using GIMIAS Command-Line Taverna Plugin.

[[File:CTL_CLM_TAVERNA.png|400px]]

GIMIAS's CLPs and CTK's Command Line Modules can be combined into the same Taverna workflow. See the following image where a Marching Cubes GIMIAS's CLP is used along with the CopyPlugin, a CTK Command Line Module.

[[File:GIMIAS_CTK_WORKFLOW.png|400px]]

Documentation/CLI In Context

2015-02-03T12:27:08Z

Hans Meine: add link to screencast for CLI modules in MeVisLab

This page lists some example and notes on different integration of CLI modules in different frameworks including CTK (see [[Documentation/Command_Line_Interface]] for a general overview of CLI modules). The first interoperability testing was done during the [http://www.creatis.insa-lyon.fr/Interoperability_workshop third] VPH NoE Imaging workshop hold in Lyon, France on October 22-23, 2012. It will be continued in consecutive hackfests. The aim is to try to plug in CLI modules in CLI compatible frameworks and come up with possible improvement of the CLI standard, advice to CLI module and CLI framework developers.

== Events ==

* [[CTK-Hackfest-Nov-2011|CTK Hackfest]] in Sophia Antipolis, France in November 2011
** Preliminary work to integrate CLI into GIMIAS
* [[CTK-Hackfest-Jul-2012|CTK Hackfest]] in Boston, USA in July 2012
** Preliminary work to integrate CLI into MITK
* [http://www.creatis.insa-lyon.fr/Interoperability_workshop 3rd VPH NoE Imaging workshop] in Lyon, France on October 22-23, 2012
** [[#First_Interoperability_tests|First Interoperability tests]] with CTK, GIMIAS, NiftyView and Slicer
* [[CTK-Hackfest-Dec-2012|CTK Hackfest]] in Bologna, Italy on December, 2012
** Preliminary work to integrate CLI into medInria, MAF3
** Semi-Automatic framework CLI integration tests
* [[CTK-Hackfest-Nov-2013|CTK Hackfest]] in London, UK on November, 2013
** [[#Second_Interoperability_tests|Second Interoperability tests]]: GIMIAS's Command Line Plugins in CTK's Command Line Module Explorer, CTK's Command Line Modules in Taverna Workbench

== First Interoperability tests ==

These first tests mainly concern the integration of niftyreg (registration algorithms from UCL). The different stages of integration are: load, execute and results. Meaning that the CLI module can be loaded. executed and provides the same results as if it was run only from the command line. The problems we encountered were:

* GIMIAS does not support to have a `default` element different that `None` for the output, not sure about the `advanced` option for the `parameters` element
* niftyreg was using `fileExtensions` with stars (`*.nii`) which is not supported by neither GIMIAS nor Slicer (the star is directly used in the file name)
* The default output folder should be set to the user folder and not the running one, otherwise the CLI module can crash because they were denied access to write in that folder (for example `Program Files` under Windows)
* What to do with CLI modules that have dependencies on shared libraries with the platform but of different versions? Platforms should have the option to only use the libraries shipped with the CLI module
* Platforms should align the way they treat data since if two load data differently, the same CLI module could give different results

It would be interesting to create test CLI modules for these integration tests. For example one that exposes all possible types of options, one running a simple algorithm without any dependencies (as niftyreg) and one with dependencies.

Some thoughts on the tested platforms:
* Niftyview has nice controls on the way CLI modules are found and loaded (control on the `XML` validation)
* Slicer has a nice display of the loaded and non loaded CLI modules (appear in red, there could be more explanation why the loading failed)

Test datasets:

The test datasets [https://drive.google.com/file/d/0B3kBRNGHGeP0bGFjZlZNcHJLNEU/edit?usp=sharing source_2down.nii] and [https://drive.google.com/file/d/0B3kBRNGHGeP0N2gzZTVYV2JTX28/edit?usp=sharing target_2down.nii] were obtained from [http://brainweb.bic.mni.mcgill.ca/brainweb BrainWeb] and [http://adni.loni.usc.edu/ ADNI].

Here are the snapshots of niftyreg on the different platforms:

<gallery caption="niftyreg on the different platforms" widths="400px" heights="300px" perrow="3">
Image:Niftyreg-ctk.png|CTK command line module explorer
Image:Niftyreg-slicer.png|3D Slicer
Image:Niftyreg-niftyview.png|NiftyView (based on MITK Workbench)
Image:Niftyreg-gimias.png|GIMIAS
Image:medinria-cli-niftyreg.png|MedInria
Image:Niftyreg-MeVisLab.png|MeVisLab (see [https://www.youtube.com/watch?v=FSCrmiWEcbA screencast])
Image:Niftyreg-MITK-Workbench.png|MITK Workbench
</gallery>

== Second Interoperability tests ==

* GIMIAS's Command Line Plugins in CTK's Command Line Module Explorer

This interoperability test was done under Windows 8. Similar steps can be performed in other platforms.

Typically, GIMIAS's Command Line Plugins (CLPs) are located in folder '''<GIMIAS_install_dir>\commandLinePlugins'''. However, the DLL dependencies of these CLPs are located in '''<GIMIAS_install_dir>'''. This is a problem when attempting to use GIMIAS's CLPs in CTK's Command Line Module Explorer (CLME), as the CLME will fail to load the CLPs.

This can be easily solved by copying GIMIAS's CLPs in a different folder, let's say '''<CLP_folder>''', along with its DLL dependencies (for finding out the DLL dependencies of a CLP, a program such as [http://dependencywalker.com/ Dependency Walker] can be used).

After creating '''<CLP_folder>''' and copying the necessary files in it. Start CTK's CLME, go to menu "Module" and choose "Options". In "Module Settings" go to "Search Paths", and then add '''<CLP_folder>''' to the search paths. Press "OK" and the CLME will scan '''<CLP_folder>''' and load the CLPs.

If the loading process fails, you are probably missing a DLL dependency, close the CLME and go to the cache folder ('''<user_directory>\AppData\Local\CommonTK\CommandLineModuleExplorer\cache''' on MS Windows). Clear the content of that directory, add the additional DLL to '''<CLP_folder>''' and then start the CLME again.

If a CLP shows up in the list with a warning sign, place the mouse on top of the CLP's name and look at the warning message. Most likely the XML that defines the CLP has a compatibility problem with the CLME, which means that is does not adhere to the [http://www.commontk.org/docs/html/ctkCmdLineModule.xsd CTK XML Schema]. See the definition of the Schema, correct the XML of the CLP, clear CLME's cache folder as described in the previous paragraph, and start the CLME again.

After following these steps, you will be able to see and use your CLP in the CLME. '''This means that you can share your GIMIAS's CLP with any CTK user at any time, by just sharing your CLPs executable file and its DLL dependencies'''.

The following image shows GIMIAS's CLPs loaded in CTK's CLME. The "Create a DICOM Series" CLP is selected. The "Settings" dialog is also shown, indicating how to add the CLPs directory to the CLME's search paths. Notice that some CLPs are shown with a warning sign, so their XML definitions has to be corrected.

[[File:GIMIAS_CLPs_on_CTK_CLME.png|400px]]

* CTK's Command Line Modules in Taverna Workbench

[http://www.taverna.org.uk/download/workbench/ Taverna Workbench] is an open source Workflow Management System written in Java. GIMIAS's Command Line Plugins (CLPs) can be used in Taverna Workbench for creating medical imaging workflows composed of several filters. In order to be able to do this, the '''Center Computational Imaging and Simulation Technologies in Biomedicine (CISTIB)''' at the [http://www.shef.ac.uk/ University of Sheffield] has created a Taverna Workbench plugin for GIMIAS.

General instructions on how to install GIMIAS Command-Line Taverna Plugin can be found [https://drive.google.com/file/d/0B3kBRNGHGeP0dE53THFMYjdsdDQ/edit?usp=sharing here].

In this interoperability test, a CTK Command Line Module was created and tested with GIMIAS Command-Line Taverna Plugin. The sample plugin is called '''CopyPlugin'''. It is a simple code to open a VTK ASCII file containing a PolyData, and save the contents of the file on another VTK file. The plugin code can be accessed [https://drive.google.com/file/d/0B3kBRNGHGeP0bVZVWHZkS1NydnM/edit?usp=sharing here].

The result was successful, which means that '''GIMIAS's CLPs and CTK's Command Line Modules can be combined to create processing workflows in Taverna Workbench !!'''.

The following image shows the CopyPlugin running on CTK's Command Line Module Explorer.

[[File:COPYPLUGIN_CTK_CLME.png‎|400px]]

The CopyPlugin Command Line Module Explorer can also be imported into GIMIAS, see the following image

[[File:COPYPLUGIN_CTK_GIMIAS.png|400px]]

The following image shows a simple workflow that includes the CopyPlugin, after being imported using GIMIAS Command-Line Taverna Plugin.

[[File:CTL_CLM_TAVERNA.png|400px]]

GIMIAS's CLPs and CTK's Command Line Modules can be combined into the same Taverna workflow. See the following image where a Marching Cubes GIMIAS's CLP is used along with the CopyPlugin, a CTK Command Line Module.

[[File:GIMIAS_CTK_WORKFLOW.png|400px]]

Documentation/Command Line Interface

2014-12-26T21:36:07Z

Hans Meine: add links to new bot-generated lists of Slicer extensions that can be filtered by type=cli

== What are CLI modules? ==

"CLI (commandline interface) modules" are standalone tools (for instance, a segmentation algorithm) that offer a commandline interface and a '''--xml''' switch that outputs a ''machine-readable kind of --help'' (XML description of their supported parameters, values, hints, etc.). This makes it possible to use such CLIs as some kind of "plugins" for rich GUI applications that offer visualization and '''automatically generated GUI panels''' for parameter adjustment. Also, the whole data handling is left to the host application (which may e.g. implement a batch processing pipeline, running the CLI systematically on all relevant data for a particular study), and it becomes possible to use the '''same algorithm in various different host applications and contexts''', by agreeing on a common standard for the --xml output.

== CTK Support for CLI Modules ==

CTK provides an API for interfacing with such self-describing command line modules, and the XML schema for the parameter description and most of the supported feature set for a module has been adopted from the Slicer Execution Model (the first host where this idea originated).

The API provided by CTK allows the management, GUI generation, and asynchronous execution of such modules in a toolkit-independent and interoperable way. Application writers can rely on the provided libraries and their API to quickly integrate command line modules into their applications. CTK also comes with an example application, called ctkCommandLineModuleExplorer which can be used to load different kinds of modules, to verify their correctness, to run - and finally inspect their output.

;More information on CTK's support for CLI modules:
: There is [http://www.commontk.org/docs/html/CommandLineModules_Page.html a well-written page in the Doxygen docs] (and a [http://www.commontk.org/docs/html/group__CommandLineModules__Group.html group for the classes]), as well as [[Documentation/CLI Support in CTK|a separate wiki page]].

== Example Applications ==

CLI modules are already supported by a number of host applications, e.g. 3D Slicer, NiftyView / MITK Workbench, GIMIAS, MedInria, MeVisLab, nipype and more. You can see some examples on the [[Documentation/CLI_In_Context|CLI In Context]] page.

== Background Information / Specs ==

Currently, the CLI module standard is documented as [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer's Execution Model]. There is an [https://github.com/commontk/CTK/blob/master/Libs/CommandLineModules/Core/Resources/ctkCmdLineModule.xsd XML schema definition] ([http://www.commontk.org/docs/html/ctkCmdLineModule.xsd auto-generated pretty-printed documentation]) that was created retroactively, and not all existing modules strictly follow the spec. However, one problem is that the schema definition does not facilitate to specify that e.g. the order of author and description elements is irrelevant, so the schema is more strict than the actual implementation in some respects (and less strict in some other).

You are welcome to join the [http://www.commontk.org/index.php/Getting_Started#CTK_mailing_list ctk-developers mailing list] for discussing related questions.

TODO: The standard (Slicer execution model description) should probably be moved to the CTK domain.

== Creating your own CLI modules ==

There is a [https://github.com/Slicer/SlicerExecutionModel "SlicerExecutionModel"] project at GitHub that shall help you with implementing new CLIs, e.g. by offering means to '''automatically parse commandline arguments''' based on the XML spec.

The Slicer documentation also contains instructions on [http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Modules how to extend Slicer via CLI modules] or other means.

If you want to implement a Python-based solution, you might also be interested in [https://github.com/commontk/ctk-cli the code available on GitHub] and [https://pypi.python.org/pypi/ctk-cli the Python Package Index] that was developed as part of the [http://www.na-mic.org/Wiki/index.php/2013_Summer_Project_Week:CLI_modules_in_MeVisLab CLI integration in MeVisLab] during the NA-MIC summer project week 2013.

== Examples of CLI Modules ==

Wherever feasible, Slicer developers are encouraged to encapsulate functionality as CLI modules.
* [https://github.com/Slicer/Slicer/tree/master/Modules/CLI Source code of Slicer's CLI Modules]
* Many [http://slicer.kitware.com/midas3/slicerappstore?os=win&arch=amd64&revision=23777&category=&search=&layout=layout Slicer extensions] provide command line modules (unfortunately, ATM, it is not possible yet to query only CLI modules, but there are now [http://wiki.slicer.org/slicerWiki/index.php/User:UpdateBot/Issue-2843-Consolidated-Extension-List auto-generated lists] that can be [http://wiki.slicer.org/slicerWiki/index.php/User:UpdateBot/Issue-2843-Consolidated-Extension-List/4.4#cli filtered by type=cli]).
* The [http://www.nitrc.org/projects/slicer NITRC.org project for 3D Slicer] lists associations to software packages that interoperate with Slicer, and many of these consist of one or more CLI modules.
* [http://sourceforge.net/projects/niftyreg/ niftyreg] contains registration algorithms (from UCL, hosted on SF.net).

Documentation/Command Line Interface

2014-11-11T10:38:41Z

Hans Meine: link to new ctk_cli package

== What are CLI modules? ==

"CLI (commandline interface) modules" are standalone tools (for instance, a segmentation algorithm) that offer a commandline interface and a '''--xml''' switch that outputs a ''machine-readable kind of --help'' (XML description of their supported parameters, values, hints, etc.). This makes it possible to use such CLIs as some kind of "plugins" for rich GUI applications that offer visualization and '''automatically generated GUI panels''' for parameter adjustment. Also, the whole data handling is left to the host application (which may e.g. implement a batch processing pipeline, running the CLI systematically on all relevant data for a particular study), and it becomes possible to use the '''same algorithm in various different host applications and contexts''', by agreeing on a common standard for the --xml output.

== CTK Support for CLI Modules ==

CTK provides an API for interfacing with such self-describing command line modules, and the XML schema for the parameter description and most of the supported feature set for a module has been adopted from the Slicer Execution Model (the first host where this idea originated).

The API provided by CTK allows the management, GUI generation, and asynchronous execution of such modules in a toolkit-independent and interoperable way. Application writers can rely on the provided libraries and their API to quickly integrate command line modules into their applications. CTK also comes with an example application, called ctkCommandLineModuleExplorer which can be used to load different kinds of modules, to verify their correctness, to run - and finally inspect their output.

;More information on CTK's support for CLI modules:
: There is [http://www.commontk.org/docs/html/CommandLineModules_Page.html a well-written page in the Doxygen docs] (and a [http://www.commontk.org/docs/html/group__CommandLineModules__Group.html group for the classes]), as well as [[Documentation/CLI Support in CTK|a separate wiki page]].

== Example Applications ==

CLI modules are already supported by a number of host applications, e.g. 3D Slicer, NiftyView / MITK Workbench, GIMIAS, MedInria, MeVisLab, nipype and more. You can see some examples on the [[Documentation/CLI_In_Context|CLI In Context]] page.

== Background Information / Specs ==

Currently, the CLI module standard is documented as [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer's Execution Model]. There is an [https://github.com/commontk/CTK/blob/master/Libs/CommandLineModules/Core/Resources/ctkCmdLineModule.xsd XML schema definition] ([http://www.commontk.org/docs/html/ctkCmdLineModule.xsd auto-generated pretty-printed documentation]) that was created retroactively, and not all existing modules strictly follow the spec. However, one problem is that the schema definition does not facilitate to specify that e.g. the order of author and description elements is irrelevant, so the schema is more strict than the actual implementation in some respects (and less strict in some other).

You are welcome to join the [http://www.commontk.org/index.php/Getting_Started#CTK_mailing_list ctk-developers mailing list] for discussing related questions.

TODO: The standard (Slicer execution model description) should probably be moved to the CTK domain.

== Creating your own CLI modules ==

There is a [https://github.com/Slicer/SlicerExecutionModel "SlicerExecutionModel"] project at GitHub that shall help you with implementing new CLIs, e.g. by offering means to '''automatically parse commandline arguments''' based on the XML spec.

The Slicer documentation also contains instructions on [http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Modules how to extend Slicer via CLI modules] or other means.

If you want to implement a Python-based solution, you might also be interested in [https://github.com/commontk/ctk-cli the code available on GitHub] and [https://pypi.python.org/pypi/ctk-cli the Python Package Index] that was developed as part of the [http://www.na-mic.org/Wiki/index.php/2013_Summer_Project_Week:CLI_modules_in_MeVisLab CLI integration in MeVisLab] during the NA-MIC summer project week 2013.

== Examples of CLI Modules ==

Wherever feasible, Slicer developers are encouraged to encapsulate functionality as CLI modules.
* [https://github.com/Slicer/Slicer/tree/master/Modules/CLI Source code of Slicer's CLI Modules]
* Many [http://slicer.kitware.com/midas3/slicerappstore?os=win&arch=amd64&revision=23777&category=&search=&layout=layout Slicer extensions] provide command line modules (unfortunately, ATM, it is not possible yet to query only CLI modules).
* The [http://www.nitrc.org/projects/slicer NITRC.org project for 3D Slicer] lists associations to software packages that interoperate with Slicer, and many of these consist of one or more CLI modules.
* [http://sourceforge.net/projects/niftyreg/ niftyreg] contains registration algorithms (from UCL, hosted on SF.net).

Documentation/Command Line Interface

2014-11-11T10:36:13Z

Hans Meine: mention niftyreg

== What are CLI modules? ==

"CLI (commandline interface) modules" are standalone tools (for instance, a segmentation algorithm) that offer a commandline interface and a '''--xml''' switch that outputs a ''machine-readable kind of --help'' (XML description of their supported parameters, values, hints, etc.). This makes it possible to use such CLIs as some kind of "plugins" for rich GUI applications that offer visualization and '''automatically generated GUI panels''' for parameter adjustment. Also, the whole data handling is left to the host application (which may e.g. implement a batch processing pipeline, running the CLI systematically on all relevant data for a particular study), and it becomes possible to use the '''same algorithm in various different host applications and contexts''', by agreeing on a common standard for the --xml output.

== CTK Support for CLI Modules ==

CTK provides an API for interfacing with such self-describing command line modules, and the XML schema for the parameter description and most of the supported feature set for a module has been adopted from the Slicer Execution Model (the first host where this idea originated).

The API provided by CTK allows the management, GUI generation, and asynchronous execution of such modules in a toolkit-independent and interoperable way. Application writers can rely on the provided libraries and their API to quickly integrate command line modules into their applications. CTK also comes with an example application, called ctkCommandLineModuleExplorer which can be used to load different kinds of modules, to verify their correctness, to run - and finally inspect their output.

;More information on CTK's support for CLI modules:
: There is [http://www.commontk.org/docs/html/CommandLineModules_Page.html a well-written page in the Doxygen docs] (and a [http://www.commontk.org/docs/html/group__CommandLineModules__Group.html group for the classes]), as well as [[Documentation/CLI Support in CTK|a separate wiki page]].

== Example Applications ==

CLI modules are already supported by a number of host applications, e.g. 3D Slicer, NiftyView / MITK Workbench, GIMIAS, MedInria, MeVisLab, nipype and more. You can see some examples on the [[Documentation/CLI_In_Context|CLI In Context]] page.

== Background Information / Specs ==

Currently, the CLI module standard is documented as [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer's Execution Model]. There is an [https://github.com/commontk/CTK/blob/master/Libs/CommandLineModules/Core/Resources/ctkCmdLineModule.xsd XML schema definition] ([http://www.commontk.org/docs/html/ctkCmdLineModule.xsd auto-generated pretty-printed documentation]) that was created retroactively, and not all existing modules strictly follow the spec. However, one problem is that the schema definition does not facilitate to specify that e.g. the order of author and description elements is irrelevant, so the schema is more strict than the actual implementation in some respects (and less strict in some other).

You are welcome to join the [http://www.commontk.org/index.php/Getting_Started#CTK_mailing_list ctk-developers mailing list] for discussing related questions.

TODO: The standard (Slicer execution model description) should probably be moved to the CTK domain.

== Creating your own CLI modules ==

There is a [https://github.com/Slicer/SlicerExecutionModel "SlicerExecutionModel"] project at GitHub that shall help you with implementing new CLIs, e.g. by offering means to '''automatically parse commandline arguments''' based on the XML spec.

The Slicer documentation also contains instructions on [http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Modules how to extend Slicer via CLI modules] or other means.

If you want to implement a Python-based solution, you might also be interested in [https://github.com/hmeine/MeVisLab-CLI/tree/master/Modules/Scripts/python the code available on GitHub] that was developed as part of the [http://www.na-mic.org/Wiki/index.php/2013_Summer_Project_Week:CLI_modules_in_MeVisLab CLI integration in MeVisLab] during the NA-MIC summer project week 2013.

== Examples of CLI Modules ==

Wherever feasible, Slicer developers are encouraged to encapsulate functionality as CLI modules.
* [https://github.com/Slicer/Slicer/tree/master/Modules/CLI Source code of Slicer's CLI Modules]
* Many [http://slicer.kitware.com/midas3/slicerappstore?os=win&arch=amd64&revision=23777&category=&search=&layout=layout Slicer extensions] provide command line modules (unfortunately, ATM, it is not possible yet to query only CLI modules).
* The [http://www.nitrc.org/projects/slicer NITRC.org project for 3D Slicer] lists associations to software packages that interoperate with Slicer, and many of these consist of one or more CLI modules.
* [http://sourceforge.net/projects/niftyreg/ niftyreg] contains registration algorithms (from UCL, hosted on SF.net).

Documentation/Command Line Interface

2014-11-07T09:19:45Z

Hans Meine: /* Examples of CLI Modules */

== What are CLI modules? ==

"CLI (commandline interface) modules" are standalone tools (for instance, a segmentation algorithm) that offer a commandline interface and a '''--xml''' switch that outputs a ''machine-readable kind of --help'' (XML description of their supported parameters, values, hints, etc.). This makes it possible to use such CLIs as some kind of "plugins" for rich GUI applications that offer visualization and '''automatically generated GUI panels''' for parameter adjustment. Also, the whole data handling is left to the host application (which may e.g. implement a batch processing pipeline, running the CLI systematically on all relevant data for a particular study), and it becomes possible to use the '''same algorithm in various different host applications and contexts''', by agreeing on a common standard for the --xml output.

== CTK Support for CLI Modules ==

CTK provides an API for interfacing with such self-describing command line modules, and the XML schema for the parameter description and most of the supported feature set for a module has been adopted from the Slicer Execution Model (the first host where this idea originated).

The API provided by CTK allows the management, GUI generation, and asynchronous execution of such modules in a toolkit-independent and interoperable way. Application writers can rely on the provided libraries and their API to quickly integrate command line modules into their applications. CTK also comes with an example application, called ctkCommandLineModuleExplorer which can be used to load different kinds of modules, to verify their correctness, to run - and finally inspect their output.

;More information on CTK's support for CLI modules:
: There is [http://www.commontk.org/docs/html/CommandLineModules_Page.html a well-written page in the Doxygen docs] (and a [http://www.commontk.org/docs/html/group__CommandLineModules__Group.html group for the classes]), as well as [[Documentation/CLI Support in CTK|a separate wiki page]].

== Example Applications ==

CLI modules are already supported by a number of host applications, e.g. 3D Slicer, NiftyView / MITK Workbench, GIMIAS, MedInria, MeVisLab, nipype and more. You can see some examples on the [[Documentation/CLI_In_Context|CLI In Context]] page.

== Background Information / Specs ==

Currently, the CLI module standard is documented as [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer's Execution Model]. There is an [https://github.com/commontk/CTK/blob/master/Libs/CommandLineModules/Core/Resources/ctkCmdLineModule.xsd XML schema definition] ([http://www.commontk.org/docs/html/ctkCmdLineModule.xsd auto-generated pretty-printed documentation]) that was created retroactively, and not all existing modules strictly follow the spec. However, one problem is that the schema definition does not facilitate to specify that e.g. the order of author and description elements is irrelevant, so the schema is more strict than the actual implementation in some respects (and less strict in some other).

You are welcome to join the [http://www.commontk.org/index.php/Getting_Started#CTK_mailing_list ctk-developers mailing list] for discussing related questions.

TODO: The standard (Slicer execution model description) should probably be moved to the CTK domain.

== Creating your own CLI modules ==

There is a [https://github.com/Slicer/SlicerExecutionModel "SlicerExecutionModel"] project at GitHub that shall help you with implementing new CLIs, e.g. by offering means to '''automatically parse commandline arguments''' based on the XML spec.

The Slicer documentation also contains instructions on [http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Modules how to extend Slicer via CLI modules] or other means.

If you want to implement a Python-based solution, you might also be interested in [https://github.com/hmeine/MeVisLab-CLI/tree/master/Modules/Scripts/python the code available on GitHub] that was developed as part of the [http://www.na-mic.org/Wiki/index.php/2013_Summer_Project_Week:CLI_modules_in_MeVisLab CLI integration in MeVisLab] during the NA-MIC summer project week 2013.

== Examples of CLI Modules ==

Wherever feasible, Slicer developers are encouraged to encapsulate functionality as CLI modules.
* [https://github.com/Slicer/Slicer/tree/master/Modules/CLI Source code of Slicer's CLI Modules]
* Many [http://slicer.kitware.com/midas3/slicerappstore?os=win&arch=amd64&revision=23777&category=&search=&layout=layout Slicer extensions] provide command line modules (unfortunately, ATM, it is not possible yet to query only CLI modules).
* The [http://www.nitrc.org/projects/slicer NITRC.org project for 3D Slicer] lists associations to software packages that interoperate with Slicer, and many of these consist of one or more CLI modules.

Documentation/CLI In Context

2014-11-05T10:58:22Z

Hans Meine:

This page lists some example and notes on different integration of CLI modules in different frameworks including CTK (see [[Documentation/Command_Line_Interface]] for a general overview of CLI modules). The first interoperability testing was done during the [http://www.creatis.insa-lyon.fr/Interoperability_workshop third] VPH NoE Imaging workshop hold in Lyon, France on October 22-23, 2012. It will be continued in consecutive hackfests. The aim is to try to plug in CLI modules in CLI compatible frameworks and come up with possible improvement of the CLI standard, advice to CLI module and CLI framework developers.

== Events ==

* [[CTK-Hackfest-Nov-2011|CTK Hackfest]] in Sophia Antipolis, France in November 2011
** Preliminary work to integrate CLI into GIMIAS
* [[CTK-Hackfest-Jul-2012|CTK Hackfest]] in Boston, USA in July 2012
** Preliminary work to integrate CLI into MITK
* [http://www.creatis.insa-lyon.fr/Interoperability_workshop 3rd VPH NoE Imaging workshop] in Lyon, France on October 22-23, 2012
** [[#First_Interoperability_tests|First Interoperability tests]] with CTK, GIMIAS, NiftyView and Slicer
* [[CTK-Hackfest-Dec-2012|CTK Hackfest]] in Bologna, Italy on December, 2012
** Preliminary work to integrate CLI into medInria, MAF3
** Semi-Automatic framework CLI integration tests
* [[CTK-Hackfest-Nov-2013|CTK Hackfest]] in London, UK on November, 2013
** [[#Second_Interoperability_tests|Second Interoperability tests]]: GIMIAS's Command Line Plugins in CTK's Command Line Module Explorer, CTK's Command Line Modules in Taverna Workbench

== First Interoperability tests ==

These first tests mainly concern the integration of niftyreg (registration algorithms from UCL). The different stages of integration are: load, execute and results. Meaning that the CLI module can be loaded. executed and provides the same results as if it was run only from the command line. The problems we encountered were:

* GIMIAS does not support to have a `default` element different that `None` for the output, not sure about the `advanced` option for the `parameters` element
* niftyreg was using `fileExtensions` with stars (`*.nii`) which is not supported by neither GIMIAS nor Slicer (the star is directly used in the file name)
* The default output folder should be set to the user folder and not the running one, otherwise the CLI module can crash because they were denied access to write in that folder (for example `Program Files` under Windows)
* What to do with CLI modules that have dependencies on shared libraries with the platform but of different versions? Platforms should have the option to only use the libraries shipped with the CLI module
* Platforms should align the way they treat data since if two load data differently, the same CLI module could give different results

It would be interesting to create test CLI modules for these integration tests. For example one that exposes all possible types of options, one running a simple algorithm without any dependencies (as niftyreg) and one with dependencies.

Some thoughts on the tested platforms:
* Niftyview has nice controls on the way CLI modules are found and loaded (control on the `XML` validation)
* Slicer has a nice display of the loaded and non loaded CLI modules (appear in red, there could be more explanation why the loading failed)

Test datasets:

The test datasets [https://drive.google.com/file/d/0B3kBRNGHGeP0bGFjZlZNcHJLNEU/edit?usp=sharing source_2down.nii] and [https://drive.google.com/file/d/0B3kBRNGHGeP0N2gzZTVYV2JTX28/edit?usp=sharing target_2down.nii] were obtained from [http://brainweb.bic.mni.mcgill.ca/brainweb BrainWeb] and [http://adni.loni.usc.edu/ ADNI].

Here are the snapshots of niftyreg on the different platforms:

<gallery caption="niftyreg on the different platforms" widths="400px" heights="300px" perrow="3">
Image:Niftyreg-ctk.png|CTK command line module explorer
Image:Niftyreg-slicer.png|3D Slicer
Image:Niftyreg-niftyview.png|NiftyView (based on MITK Workbench)
Image:Niftyreg-gimias.png|GIMIAS
Image:medinria-cli-niftyreg.png|MedInria
Image:Niftyreg-MeVisLab.png|MeVisLab
Image:Niftyreg-MITK-Workbench.png|MITK Workbench
</gallery>

== Second Interoperability tests ==

* GIMIAS's Command Line Plugins in CTK's Command Line Module Explorer

This interoperability test was done under Windows 8. Similar steps can be performed in other platforms.

Typically, GIMIAS's Command Line Plugins (CLPs) are located in folder '''<GIMIAS_install_dir>\commandLinePlugins'''. However, the DLL dependencies of these CLPs are located in '''<GIMIAS_install_dir>'''. This is a problem when attempting to use GIMIAS's CLPs in CTK's Command Line Module Explorer (CLME), as the CLME will fail to load the CLPs.

This can be easily solved by copying GIMIAS's CLPs in a different folder, let's say '''<CLP_folder>''', along with its DLL dependencies (for finding out the DLL dependencies of a CLP, a program such as [http://dependencywalker.com/ Dependency Walker] can be used).

After creating '''<CLP_folder>''' and copying the necessary files in it. Start CTK's CLME, go to menu "Module" and choose "Options". In "Module Settings" go to "Search Paths", and then add '''<CLP_folder>''' to the search paths. Press "OK" and the CLME will scan '''<CLP_folder>''' and load the CLPs.

If the loading process fails, you are probably missing a DLL dependency, close the CLME and go to the cache folder ('''<user_directory>\AppData\Local\CommonTK\CommandLineModuleExplorer\cache''' on MS Windows). Clear the content of that directory, add the additional DLL to '''<CLP_folder>''' and then start the CLME again.

If a CLP shows up in the list with a warning sign, place the mouse on top of the CLP's name and look at the warning message. Most likely the XML that defines the CLP has a compatibility problem with the CLME, which means that is does not adhere to the [http://www.commontk.org/docs/html/ctkCmdLineModule.xsd CTK XML Schema]. See the definition of the Schema, correct the XML of the CLP, clear CLME's cache folder as described in the previous paragraph, and start the CLME again.

After following these steps, you will be able to see and use your CLP in the CLME. '''This means that you can share your GIMIAS's CLP with any CTK user at any time, by just sharing your CLPs executable file and its DLL dependencies'''.

The following image shows GIMIAS's CLPs loaded in CTK's CLME. The "Create a DICOM Series" CLP is selected. The "Settings" dialog is also shown, indicating how to add the CLPs directory to the CLME's search paths. Notice that some CLPs are shown with a warning sign, so their XML definitions has to be corrected.

[[File:GIMIAS_CLPs_on_CTK_CLME.png|400px]]

* CTK's Command Line Modules in Taverna Workbench

[http://www.taverna.org.uk/download/workbench/ Taverna Workbench] is an open source Workflow Management System written in Java. GIMIAS's Command Line Plugins (CLPs) can be used in Taverna Workbench for creating medical imaging workflows composed of several filters. In order to be able to do this, the '''Center Computational Imaging and Simulation Technologies in Biomedicine (CISTIB)''' at the [http://www.shef.ac.uk/ University of Sheffield] has created a Taverna Workbench plugin for GIMIAS.

General instructions on how to install GIMIAS Command-Line Taverna Plugin can be found [https://drive.google.com/file/d/0B3kBRNGHGeP0dE53THFMYjdsdDQ/edit?usp=sharing here].

In this interoperability test, a CTK Command Line Module was created and tested with GIMIAS Command-Line Taverna Plugin. The sample plugin is called '''CopyPlugin'''. It is a simple code to open a VTK ASCII file containing a PolyData, and save the contents of the file on another VTK file. The plugin code can be accessed [https://drive.google.com/file/d/0B3kBRNGHGeP0bVZVWHZkS1NydnM/edit?usp=sharing here].

The result was successful, which means that '''GIMIAS's CLPs and CTK's Command Line Modules can be combined to create processing workflows in Taverna Workbench !!'''.

The following image shows the CopyPlugin running on CTK's Command Line Module Explorer.

[[File:COPYPLUGIN_CTK_CLME.png‎|400px]]

The CopyPlugin Command Line Module Explorer can also be imported into GIMIAS, see the following image

[[File:COPYPLUGIN_CTK_GIMIAS.png|400px]]

The following image shows a simple workflow that includes the CopyPlugin, after being imported using GIMIAS Command-Line Taverna Plugin.

[[File:CTL_CLM_TAVERNA.png|400px]]

GIMIAS's CLPs and CTK's Command Line Modules can be combined into the same Taverna workflow. See the following image where a Marching Cubes GIMIAS's CLP is used along with the CopyPlugin, a CTK Command Line Module.

[[File:GIMIAS_CTK_WORKFLOW.png|400px]]

Documentation/CLI Support in CTK

2014-11-05T10:57:30Z

Hans Meine:

Command Line Interface (CLI) support in CTK will primarly focus on providing an API for working with existing CLI modules. Providing utilities and tools for creating CLI modules from scratch is a desired addition but there are no concrete plans for this yet. See [[Documentation/Command_Line_Interface]] for more general information about CLI modules.

=== Getting the Code ===

The code is available in the CTK master:

https://github.com/commontk/CTK

Enable the following CMake options to be able to play with the code:

* '''BUILD_TESTING''' (for creating CLI test modules)
* '''CTK_APP_ctkCommandLineModuleExplorer''' (small program allowing you to test-drive CLI modules using the CTK CLI module API, enables all the options below)
* '''CTK_LIB_CommandLineModules/Core''' (the CTK library providing the core CLI module API)
* '''CTK_LIB_CommandLineModules/Frontend/QtGui''' (the CTK library providing GUI generation using the Qt widgets)
* '''CTK_LIB_CommandLineModules/Backend/LocalProcess''' (the CTK library for executing local executable files as command line modules)

=== API Design ===

This is a partially overview of the API design, showing the GUI generation process for the Qt front-end.

<graphviz>
digraph G {
graph [
rankdir = "TB"
];
node [
fontsize = "16"
shape = "ellipse"
];
edge [
];
subgraph cluster_0 {
label = "CTK";
color = lightGray;
"xmlFile" [
label = "{<f0> Command Line Module XML (.xml)| <f1>}"
shape = "record"
];
"gui" [
label = "{<f0> Qt GUI | <f1>}"
shape = "record"
];
"uiFile" [
label = "{<f0> CLI UI (.ui) | <f1>}"
shape = "record"
];
"ctkCLIModuleDescription" [
label = "{<f0> ctkCmdLineModuleDescription| <f1>}"
shape = "record"
];
}

subgraph cluster_1 {
label = "3D Slicer";
color = gray;
"vtkMRMLParametersNode" [
label = "{<f0> vtkMRMLParametersNode| <f1>}"
shape = "record"
];
}
"xmlFile":f0:e -> "xmlFile":f0:ne [label = "XSD file check" ];
"xmlFile":f1 -> "uiFile":f0 [label = "QtGui XSL file" ];
"xmlFile":f1 -> "uiFile":f0 [label = "" style=invis];
"xmlFile":f1 -> "ctkCLIModuleDescription":f0 [label=ctkCmdLineModuleXmlParser];
"ctkCLIModuleDescription":f1 -> "vtkMRMLParametersNode":f0 [label=create];
"uiFile":f1 -> "gui":f0 [label = QUiLoader];
"gui":f1:e -> "vtkMRMLParametersNode":f1:w [dir = both label=synchronize constraint=false];
}
</graphviz>

Overview of some central classes and their scope.

Please see the full [file:///opt/ctk-builds/CTK-debug-gcc/CTK-build/Documentation/html/group__CommandLineModulesCore__API.html Core API] for a list of available classes and their documentation.

==== ctkCmdLineModuleDescription ====

C++ API for accessing the command line arguments meta-data defined in the XML description.

This class is ''read-only''.

==== ctkCmdLineModuleReference ====

A handle to a command line module.

* Get ctkCmdLineModuleDescription class
* Convenient meta-data access (module location etc.)
* Used to crate actual ctkCmdLineModuleFrontend instances from specific ctkCmdLineModuleFrontendFactory implementations

==== ctkCmdLineModuleFrontend ====

Represents an invokable command line module and its current parameter values.

Multiple instances for the same ModuleReference may exist.

* Set/Get individual parameter values or all at once
* Reset to default parameters
* Get GUI representation (QObject*)
* Get parameter value change notifications

==== ctkCmdLineModuleFuture ====

Returned by the ctkCmdLineModuleManager run method and used to communicate with a running module.

* Run/Abort
* Status
* Progress reporting

==== ctkCmdLineModuleManager ====

Responsible for managing and running other ctkCmdLineModule* classes.

* Register specific back-ends for handling different types of modules
* Register/Unregister modules
* Get ctkCmdLineModuleReference objects
* Run ctkCmdLineModuleFrontend objects

=== Customizability ===

==== Qt Widget related ====

See also the [http://www.commontk.org/docs/html/classctkCmdLineModuleFrontendQtGui.html ctkCmdLineModuleFrontendQtGui] class for customization information.

* Use parameters for the default XSLT file to customize widget class names for argument types
* Use your own XSLT file for custom transformations of XML to UI
* Use your own QUiLoader to control instantiation of certain widget types

==== General ====

* Use a custom ''factory'' to create your own GUI based on a ctkCmdLineModuleDescription instance.

Documentation/CLI Support in CTK

2014-11-05T10:57:20Z

Hans Meine: link back to general information page

Command Line Interface (CLI) support in CTK will primarly focus on providing an API for working with existing CLI modules. Providing utilities and tools for creating CLI modules from scratch is a desired addition but there are no concrete plans for this yet. See [[Documentation/Command_Line_Interface] for more general information about CLI modules.

=== Getting the Code ===

The code is available in the CTK master:

https://github.com/commontk/CTK

Enable the following CMake options to be able to play with the code:

* '''BUILD_TESTING''' (for creating CLI test modules)
* '''CTK_APP_ctkCommandLineModuleExplorer''' (small program allowing you to test-drive CLI modules using the CTK CLI module API, enables all the options below)
* '''CTK_LIB_CommandLineModules/Core''' (the CTK library providing the core CLI module API)
* '''CTK_LIB_CommandLineModules/Frontend/QtGui''' (the CTK library providing GUI generation using the Qt widgets)
* '''CTK_LIB_CommandLineModules/Backend/LocalProcess''' (the CTK library for executing local executable files as command line modules)

=== API Design ===

This is a partially overview of the API design, showing the GUI generation process for the Qt front-end.

<graphviz>
digraph G {
graph [
rankdir = "TB"
];
node [
fontsize = "16"
shape = "ellipse"
];
edge [
];
subgraph cluster_0 {
label = "CTK";
color = lightGray;
"xmlFile" [
label = "{<f0> Command Line Module XML (.xml)| <f1>}"
shape = "record"
];
"gui" [
label = "{<f0> Qt GUI | <f1>}"
shape = "record"
];
"uiFile" [
label = "{<f0> CLI UI (.ui) | <f1>}"
shape = "record"
];
"ctkCLIModuleDescription" [
label = "{<f0> ctkCmdLineModuleDescription| <f1>}"
shape = "record"
];
}

subgraph cluster_1 {
label = "3D Slicer";
color = gray;
"vtkMRMLParametersNode" [
label = "{<f0> vtkMRMLParametersNode| <f1>}"
shape = "record"
];
}
"xmlFile":f0:e -> "xmlFile":f0:ne [label = "XSD file check" ];
"xmlFile":f1 -> "uiFile":f0 [label = "QtGui XSL file" ];
"xmlFile":f1 -> "uiFile":f0 [label = "" style=invis];
"xmlFile":f1 -> "ctkCLIModuleDescription":f0 [label=ctkCmdLineModuleXmlParser];
"ctkCLIModuleDescription":f1 -> "vtkMRMLParametersNode":f0 [label=create];
"uiFile":f1 -> "gui":f0 [label = QUiLoader];
"gui":f1:e -> "vtkMRMLParametersNode":f1:w [dir = both label=synchronize constraint=false];
}
</graphviz>

Overview of some central classes and their scope.

Please see the full [file:///opt/ctk-builds/CTK-debug-gcc/CTK-build/Documentation/html/group__CommandLineModulesCore__API.html Core API] for a list of available classes and their documentation.

==== ctkCmdLineModuleDescription ====

C++ API for accessing the command line arguments meta-data defined in the XML description.

This class is ''read-only''.

==== ctkCmdLineModuleReference ====

A handle to a command line module.

* Get ctkCmdLineModuleDescription class
* Convenient meta-data access (module location etc.)
* Used to crate actual ctkCmdLineModuleFrontend instances from specific ctkCmdLineModuleFrontendFactory implementations

==== ctkCmdLineModuleFrontend ====

Represents an invokable command line module and its current parameter values.

Multiple instances for the same ModuleReference may exist.

* Set/Get individual parameter values or all at once
* Reset to default parameters
* Get GUI representation (QObject*)
* Get parameter value change notifications

==== ctkCmdLineModuleFuture ====

Returned by the ctkCmdLineModuleManager run method and used to communicate with a running module.

* Run/Abort
* Status
* Progress reporting

==== ctkCmdLineModuleManager ====

Responsible for managing and running other ctkCmdLineModule* classes.

* Register specific back-ends for handling different types of modules
* Register/Unregister modules
* Get ctkCmdLineModuleReference objects
* Run ctkCmdLineModuleFrontend objects

=== Customizability ===

==== Qt Widget related ====

See also the [http://www.commontk.org/docs/html/classctkCmdLineModuleFrontendQtGui.html ctkCmdLineModuleFrontendQtGui] class for customization information.

* Use parameters for the default XSLT file to customize widget class names for argument types
* Use your own XSLT file for custom transformations of XML to UI
* Use your own QUiLoader to control instantiation of certain widget types

==== General ====

* Use a custom ''factory'' to create your own GUI based on a ctkCmdLineModuleDescription instance.

Documentation/Command Line Interface

2014-11-05T10:55:24Z

Hans Meine: link to mailing list

== What are CLI modules? ==

"CLI (commandline interface) modules" are standalone tools (for instance, a segmentation algorithm) that offer a commandline interface and a '''--xml''' switch that outputs a ''machine-readable kind of --help'' (XML description of their supported parameters, values, hints, etc.). This makes it possible to use such CLIs as some kind of "plugins" for rich GUI applications that offer visualization and '''automatically generated GUI panels''' for parameter adjustment. Also, the whole data handling is left to the host application (which may e.g. implement a batch processing pipeline, running the CLI systematically on all relevant data for a particular study), and it becomes possible to use the '''same algorithm in various different host applications and contexts''', by agreeing on a common standard for the --xml output.

== CTK Support for CLI Modules ==

CTK provides an API for interfacing with such self-describing command line modules, and the XML schema for the parameter description and most of the supported feature set for a module has been adopted from the Slicer Execution Model (the first host where this idea originated).

The API provided by CTK allows the management, GUI generation, and asynchronous execution of such modules in a toolkit-independent and interoperable way. Application writers can rely on the provided libraries and their API to quickly integrate command line modules into their applications. CTK also comes with an example application, called ctkCommandLineModuleExplorer which can be used to load different kinds of modules, to verify their correctness, to run - and finally inspect their output.

;More information on CTK's support for CLI modules:
: There is [http://www.commontk.org/docs/html/CommandLineModules_Page.html a well-written page in the Doxygen docs] (and a [http://www.commontk.org/docs/html/group__CommandLineModules__Group.html group for the classes]), as well as [[Documentation/CLI Support in CTK|a separate wiki page]].

== Example Applications ==

CLI modules are already supported by a number of host applications, e.g. 3D Slicer, NiftyView / MITK Workbench, GIMIAS, MedInria, MeVisLab, nipype and more. You can see some examples on the [[Documentation/CLI_In_Context|CLI In Context]] page.

== Background Information / Specs ==

Currently, the CLI module standard is documented as [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer's Execution Model]. There is an [https://github.com/commontk/CTK/blob/master/Libs/CommandLineModules/Core/Resources/ctkCmdLineModule.xsd XML schema definition] ([http://www.commontk.org/docs/html/ctkCmdLineModule.xsd auto-generated pretty-printed documentation]) that was created retroactively, and not all existing modules strictly follow the spec. However, one problem is that the schema definition does not facilitate to specify that e.g. the order of author and description elements is irrelevant, so the schema is more strict than the actual implementation in some respects (and less strict in some other).

You are welcome to join the [http://www.commontk.org/index.php/Getting_Started#CTK_mailing_list ctk-developers mailing list] for discussing related questions.

TODO: The standard (Slicer execution model description) should probably be moved to the CTK domain.

== Creating your own CLI modules ==

There is a [https://github.com/Slicer/SlicerExecutionModel "SlicerExecutionModel"] project at GitHub that shall help you with implementing new CLIs, e.g. by offering means to '''automatically parse commandline arguments''' based on the XML spec.

The Slicer documentation also contains instructions on [http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Modules how to extend Slicer via CLI modules] or other means.

If you want to implement a Python-based solution, you might also be interested in [https://github.com/hmeine/MeVisLab-CLI/tree/master/Modules/Scripts/python the code available on GitHub] that was developed as part of the [http://www.na-mic.org/Wiki/index.php/2013_Summer_Project_Week:CLI_modules_in_MeVisLab CLI integration in MeVisLab] during the NA-MIC summer project week 2013.

Documentation/Command Line Interface

2014-11-05T10:53:17Z

Hans Meine: /* Creating your own CLI modules */

== What are CLI modules? ==

"CLI (commandline interface) modules" are standalone tools (for instance, a segmentation algorithm) that offer a commandline interface and a '''--xml''' switch that outputs a ''machine-readable kind of --help'' (XML description of their supported parameters, values, hints, etc.). This makes it possible to use such CLIs as some kind of "plugins" for rich GUI applications that offer visualization and '''automatically generated GUI panels''' for parameter adjustment. Also, the whole data handling is left to the host application (which may e.g. implement a batch processing pipeline, running the CLI systematically on all relevant data for a particular study), and it becomes possible to use the '''same algorithm in various different host applications and contexts''', by agreeing on a common standard for the --xml output.

== CTK Support for CLI Modules ==

CTK provides an API for interfacing with such self-describing command line modules, and the XML schema for the parameter description and most of the supported feature set for a module has been adopted from the Slicer Execution Model (the first host where this idea originated).

The API provided by CTK allows the management, GUI generation, and asynchronous execution of such modules in a toolkit-independent and interoperable way. Application writers can rely on the provided libraries and their API to quickly integrate command line modules into their applications. CTK also comes with an example application, called ctkCommandLineModuleExplorer which can be used to load different kinds of modules, to verify their correctness, to run - and finally inspect their output.

;More information on CTK's support for CLI modules:
: There is [http://www.commontk.org/docs/html/CommandLineModules_Page.html a well-written page in the Doxygen docs] (and a [http://www.commontk.org/docs/html/group__CommandLineModules__Group.html group for the classes]), as well as [[Documentation/CLI Support in CTK|a separate wiki page]].

== Example Applications ==

CLI modules are already supported by a number of host applications, e.g. 3D Slicer, NiftyView / MITK Workbench, GIMIAS, MedInria, MeVisLab, nipype and more. You can see some examples on the [[Documentation/CLI_In_Context|CLI In Context]] page.

== Background Information / Specs ==

Currently, the CLI module standard is documented as [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer's Execution Model]. There is an [https://github.com/commontk/CTK/blob/master/Libs/CommandLineModules/Core/Resources/ctkCmdLineModule.xsd XML schema definition] ([http://www.commontk.org/docs/html/ctkCmdLineModule.xsd auto-generated pretty-printed documentation]) that was created retroactively, and not all existing modules strictly follow the spec. However, one problem is that the schema definition does not facilitate to specify that e.g. the order of author and description elements is irrelevant, so the schema is more strict than the actual implementation in some respects (and less strict in some other).

TODO: The standard (Slicer execution model description) should probably be moved to the CTK domain.

== Creating your own CLI modules ==

There is a [https://github.com/Slicer/SlicerExecutionModel "SlicerExecutionModel"] project at GitHub that shall help you with implementing new CLIs, e.g. by offering means to '''automatically parse commandline arguments''' based on the XML spec.

The Slicer documentation also contains instructions on [http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Modules how to extend Slicer via CLI modules] or other means.

If you want to implement a Python-based solution, you might also be interested in [https://github.com/hmeine/MeVisLab-CLI/tree/master/Modules/Scripts/python the code available on GitHub] that was developed as part of the [http://www.na-mic.org/Wiki/index.php/2013_Summer_Project_Week:CLI_modules_in_MeVisLab CLI integration in MeVisLab] during the NA-MIC summer project week 2013.

Documentation/Command Line Interface

2014-11-05T10:37:31Z

Hans Meine: /* Background Information / Specs */

Documentation/Command Line Interface

2014-11-05T10:36:08Z

Hans Meine:

Documentation/Command Line Interface

2014-11-05T10:18:21Z

Hans Meine:

Documentation/Command Line Interface

2014-11-05T09:15:40Z

Hans Meine: moved Documentation/Command Line Interface to Documentation/CLI Support in CTK: "Command Line Interface" shall be a more general overview page soon

#REDIRECT [[Documentation/CLI Support in CTK]]

Documentation/CLI Support in CTK

2014-11-05T09:15:40Z

Hans Meine: moved Documentation/Command Line Interface to Documentation/CLI Support in CTK: "Command Line Interface" shall be a more general overview page soon

Command Line Interface (CLI) support in CTK will primarly focus on providing an API for working with existing CLI modules. Providing utilities and tools for creating CLI modules from scratch is a desired addition but there are no concrete plans for this yet. See [http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation Slicer3:Execution Model Documentation] for the definition of the standard. For example integration in different frameworks, see [[Documentation/CLI_In_Context|CLI In Context]].

=== Getting the Code ===

The code is available in the CTK master:

https://github.com/commontk/CTK

Enable the following CMake options to be able to play with the code:

* '''BUILD_TESTING''' (for creating CLI test modules)
* '''CTK_APP_ctkCommandLineModuleExplorer''' (small program allowing you to test-drive CLI modules using the CTK CLI module API, enables all the options below)
* '''CTK_LIB_CommandLineModules/Core''' (the CTK library providing the core CLI module API)
* '''CTK_LIB_CommandLineModules/Frontend/QtGui''' (the CTK library providing GUI generation using the Qt widgets)
* '''CTK_LIB_CommandLineModules/Backend/LocalProcess''' (the CTK library for executing local executable files as command line modules)

=== API Design ===

This is a partially overview of the API design, showing the GUI generation process for the Qt front-end.

<graphviz>
digraph G {
graph [
rankdir = "TB"
];
node [
fontsize = "16"
shape = "ellipse"
];
edge [
];
subgraph cluster_0 {
label = "CTK";
color = lightGray;
"xmlFile" [
label = "{<f0> Command Line Module XML (.xml)| <f1>}"
shape = "record"
];
"gui" [
label = "{<f0> Qt GUI | <f1>}"
shape = "record"
];
"uiFile" [
label = "{<f0> CLI UI (.ui) | <f1>}"
shape = "record"
];
"ctkCLIModuleDescription" [
label = "{<f0> ctkCmdLineModuleDescription| <f1>}"
shape = "record"
];
}

subgraph cluster_1 {
label = "3D Slicer";
color = gray;
"vtkMRMLParametersNode" [
label = "{<f0> vtkMRMLParametersNode| <f1>}"
shape = "record"
];
}
"xmlFile":f0:e -> "xmlFile":f0:ne [label = "XSD file check" ];
"xmlFile":f1 -> "uiFile":f0 [label = "QtGui XSL file" ];
"xmlFile":f1 -> "uiFile":f0 [label = "" style=invis];
"xmlFile":f1 -> "ctkCLIModuleDescription":f0 [label=ctkCmdLineModuleXmlParser];
"ctkCLIModuleDescription":f1 -> "vtkMRMLParametersNode":f0 [label=create];
"uiFile":f1 -> "gui":f0 [label = QUiLoader];
"gui":f1:e -> "vtkMRMLParametersNode":f1:w [dir = both label=synchronize constraint=false];
}
</graphviz>

Overview of some central classes and their scope.

Please see the full [file:///opt/ctk-builds/CTK-debug-gcc/CTK-build/Documentation/html/group__CommandLineModulesCore__API.html Core API] for a list of available classes and their documentation.

==== ctkCmdLineModuleDescription ====

C++ API for accessing the command line arguments meta-data defined in the XML description.

This class is ''read-only''.

==== ctkCmdLineModuleReference ====

A handle to a command line module.

* Get ctkCmdLineModuleDescription class
* Convenient meta-data access (module location etc.)
* Used to crate actual ctkCmdLineModuleFrontend instances from specific ctkCmdLineModuleFrontendFactory implementations

==== ctkCmdLineModuleFrontend ====

Represents an invokable command line module and its current parameter values.

Multiple instances for the same ModuleReference may exist.

* Set/Get individual parameter values or all at once
* Reset to default parameters
* Get GUI representation (QObject*)
* Get parameter value change notifications

==== ctkCmdLineModuleFuture ====

Returned by the ctkCmdLineModuleManager run method and used to communicate with a running module.

* Run/Abort
* Status
* Progress reporting

==== ctkCmdLineModuleManager ====

Responsible for managing and running other ctkCmdLineModule* classes.

* Register specific back-ends for handling different types of modules
* Register/Unregister modules
* Get ctkCmdLineModuleReference objects
* Run ctkCmdLineModuleFrontend objects

=== Customizability ===

==== Qt Widget related ====

See also the [http://www.commontk.org/docs/html/classctkCmdLineModuleFrontendQtGui.html ctkCmdLineModuleFrontendQtGui] class for customization information.

* Use parameters for the default XSLT file to customize widget class names for argument types
* Use your own XSLT file for custom transformations of XML to UI
* Use your own QUiLoader to control instantiation of certain widget types

==== General ====

* Use a custom ''factory'' to create your own GUI based on a ctkCmdLineModuleDescription instance.

Main Page

2014-11-05T09:13:12Z

Hans Meine: Command_Line_Interface overview/read more link

__NOTOC__

= '''CTK - The Common Toolkit''' =

<div style="float:right; margin-left:12px;">
<wikiscript type="text/javascript" src="http://www.ohloh.net/p/483293/widgets/project_basic_stats.js"></wikiscript>
<wikiscript type="text/javascript">document.write('<style>div.gadget { border-color: #bbb; }</style>')</wikiscript>
</div>

The goal of CTK is to support biomedical image computing. CTK code is licensed under [http://www.apache.org/licenses/LICENSE-2.0.html Apache 2.0]. This means that users of CTK are allowed to use the code for academic, commercial, or other purposes without paying license fees or being restricted in their ability to redistribute their code or keep it private.

CTK works on topics that are not covered by existing toolkits that support the mutual interest and needs of the CTK community. The main scope of current CTK efforts includes the topics ''DICOM'', ''DICOM Application Hosting'', ''Widgets'', and ''Plugin Framework''.

<center>
<div style="display:table-row;">
<div style="display:table-cell; max-width:450px;">
{{documentation/g-box-start|Documentation/Dicom_Overview|DICOM}}Provides high-level classes supporting query and retrieve operations from PACS and local databases. Includes Qt widgets to easily set-up a server connection and to send queries and view the results. [http://dicom.offis.de/dcmtk DCMTK] is used as the underlying toolkit.
{{documentation/g-box-links|imggalurl=|apiurl=http://www.commontk.org/docs/html/group__Project__DICOM.html|issuelabel=DICOM}}.
[[Documentation/Dicom_Overview | Read more...]]
CTK is also the home of [http://dcmjs.org dcmjs].
{{documentation/g-box-end}}
</div>
<div style="display:table-cell; max-width:450px;">
{{documentation/g-box-start|Documentation/DicomApplicationHosting|DICOM Application Hosting}}Aims at creating a C++ reference implementation of the [[media:DicomAppHostingSpecs.pdf | DICOM Part 19 Application Hosting specifications]]. It provides an infrastructure to create both hosts and hosted applications. The project is still in alpha status but may be useful for conformance testing and initial experimentation.
{{documentation/g-box-links|imggalurl=|apiurl=http://www.commontk.org/docs/html/group__Project__DICOMAppHosting.html|issuelabel=DICOMApplicationHosting}}
[[Documentation/DicomApplicationHosting | Read more...]]
{{documentation/g-box-end}}
</div>
</div>
<div style="display:table-row">
<div style="display:table-cell; max-width:450px;">
{{documentation/g-box-start|Documentation/Widgets|Widgets}}A collection of Qt Widgets for usage in biomedical imaging applications.
{{documentation/g-box-links|imggalurl=Documentation/ImageGallery|apiurl=http://www.commontk.org/docs/html/group__Project__Widgets.html|issuelabel=Widgets}}
[[Documentation/Widgets | Read more...]]
{{documentation/g-box-end}}
</div>
<div style="display:table-cell; max-width:450px;">
{{documentation/g-box-start|Documentation/Plugin_Framework|Plugin Framework}}A dynamic component system for C++, modeled after the [http://www.osgi.org OSGi] specifications. It enables a development model where applications are (dynamically) composed of many different (reusable) components following a service oriented approach.
{{documentation/g-box-links|imggalurl=|apiurl=http://www.commontk.org/docs/html/group__PluginFramework.html|issuelabel=PluginFramework}}
[[Documentation/Plugin_Framework | Read more...]]
{{documentation/g-box-end}}
</div>
</div>
<div style="display:table-row">
<div style="display:table-cell; max-width:450px;">
{{documentation/g-box-start|Documentation/Command_Line_Interface|Command Line Interfaces}}A technology that allows the algorithms written as self-contained executables to be used in multiple end-user application environments without modifications.
{{documentation/g-box-links|imggalurl=|apiurl=http://www.commontk.org/docs/html/group__CommandLineModules__Group.html|issuelabel=CmdLineModules}}
[[Documentation/Command_Line_Interface | Read more...]]
{{documentation/g-box-end}}
</div>
</div>
</center>
=== Important Links ===

Although the CTK efforts are concentrated on the topics described above, there are a couple of other working areas covering topics like ''[[Interoperability | interoperability]]'' and ''software testing'' which might be of interest to the biomedical imaging community. Please see the links given below for more details.

{| border="0" align="center" width="98%" valign="top" cellspacing="7" cellpadding="2"
|-
! width="33%"|
! |
! width="33%"|
! |
! width="33%"|
|-
|valign="top"|
<span style="color: #555555; font-size: 18px; font-weight: bold;">About CTK</span>
----
* [[News]]
* [[Events]]
* [[The Team]]
* [[CTK-Roadmap | CTK Roadmap Document]]
* [[Interoperability]]
* [[Documentation | Technical Documentation]]
* [[CTKBarCamp | CTKBarCamp]]

|bgcolor="#CCCCCC"|
|valign="top"|

<span style="color: #555555; font-size: 18px; font-weight: bold;">CTK Users</span>
----
* [[Getting Started]]
* [[Build Instructions]]
* [http://www.commontk.org/docs/html/classes.html API Documentation]
* [[Tools:_Application_launcher|Application Launcher]]

|bgcolor="#CCCCCC"|
|valign="top"|

<span style="color: #555555; font-size: 18px; font-weight: bold;">CTK Developers</span>
----
* [http://github.com/commontk/CTK Source Code]
* [http://my.cdash.org/index.php?project=CTK Dashboard]
* [[Contributing to CTK]]
* [http://github.com/commontk/CTK/issues/new Report a problem]
* [[Project Ideas]]

|}

{|align="center"
|-
|-
|
{|cellspacing="16px"
|-
|CTK builds on some awesome technology:
| [[File:200px-GitHub.png|x26px|link=http://github.com/commontk/CTK]]
| [[File:Cmake-logo.png|x26px|link=Documentation/BuildSystem_Description]]
| [[File:Qt-logo.png|x26px|link=http://qt.nokia.com]]
| [[File:Python-powered-w-100x40.png|x26px|link=Documentation/Python_Scripting]]
| [[File:Dcmtk-logo.png|x26px|link=http://www.dcmtk.org]]
| [[File:ItkLogo med.png|x26px|link=http://www.itk.org]]
| [[File:VTKlogo.png|x26px|link=http://www.vtk.org]]
|}
|}

Getting Started

2014-11-04T10:19:53Z

Hans Meine: correct signup URL

[[File:Commontk getting started.png|50px]]
If you are new to CTK and want to learn more about the scope of the toolkit, please read the [[Main Page]].
=How to=
* Build CTK: Instructions to build CTK are available [[Build_Instructions|here]].
* Integrate CTK: The [http://www.github.com/commontk/Examples Examples] project shows how to integrate CTK within an application.
* Add CTK widgets in Qt Designer: [[CTK_In_QtDesigner|Step by step guide]] to load the CTK plugins in the Qt Designer

=CTK mailing list=
For asking questions, please use the mailing list:

ctk-developers@commontk.org

The signup form and historical data for the mailing list is:

http://public.kitware.com/mailman/listinfo/ctk-developers

The mailing list archives are available here:

http://public.kitware.com/pipermail/ctk-developers/

CTK-Hackfest-Nov-2014

2014-10-23T05:41:42Z

Hans Meine: /* Attendees */

== Event pictures ==

=== Progress ===

== Introduction ==

'''Date:''' November 3-7, 2014

'''Location:'''

German Cancer Research Center, Heidelberg, Germany

More details to follow.

'''Goal:''' A follow on to the [[Commontk:Current_events#Past_events|wildly successful previous hackfests!]]

'''Requirements:''' Attendees must be willing to spend their time during the event writing ctk code that contributes to the main [[CTK-Roadmap | ctk roadmap]]. This means spending the week immersed in C++, Qt, DCMTK, CMake, and related technologies. People who do not feel qualified for this task are politely not invited :)

'''Group size:''' Maximum 20 participants so we can have a manageable working meeting. The organizing committee will invite and select participants based on input from [[TheTeam]].

'''Site Hosts:''' Marco Nolden, Sascha Zelzer, Ivo Wolf

'''Organizing Committee:''' Steve Pieper, Ivo Wolf, Stephen Aylward

'''Future Events:''' Future hackfests will be announced in advance, and we hope lots of people will be interested in participating. The venue and activities at future hackfests will be determined based on the number of active participants in the project. We welcome participation via the CTK email lists, the source code repository, and this website.

== Attendees ==

* So far we have received confirmation for the following people (in no particular order).

Please fill in your intentions in terms of common accommodation.

{|class="wikitable alternance" style="text-align:left; border:1px solid black;"
|+ '''''Participants'''''
|-
! scope=col style="background:#cde6f8;"| Name
! scope=col style="background:#cde6f8;"| Organization
|-
|Marco Nolden
|German Cancer Research Center, Heidelberg, Germany
|-
|Sascha Zelzer
|German Cancer Research Center, Heidelberg, Germany
|-
|Andreas Fetzer
|German Cancer Research Center, Heidelberg, Germany
|-
|Ivo Wolf
|Mannheim University of Applied Sciences, Germany
|-
|Steve Pieper
|Isomics, Inc., USA
|-
|Michael Onken
|Open Connections GmbH / OFFIS
|-
|Jean-Christophe Fillion-Robin
|Kitware, Inc., USA
|-
|Miklos Espak
|University College London, UK
|-
|Nicolas Toussaint
|University College London, UK
|-
|Gergely Zombori
|University College London, UK
|-
|Christian Askeland
|SINTEF Medical Technology, Trondheim, Norway
|-
|Stefan Baumann
|Basel, Switzerland
|-
|Hans Meine
|Fraunhofer MEVIS, Germany
|-
|}

{|class="wikitable alternance" style="text-align:left; border:1px solid black;"
|+ '''''Google Hangout Participants'''''
|-
! scope=col style="background:#cde6f8;"| Name
! scope=col style="background:#cde6f8;"| Organization
! scope=col style="background:#cde6f8;"| Availablity (Central European Time)
|-
|}



{{Note}}There were also other invitations sent to active people on the community, and people who recently showed interest. When their intent will be known they will be added to the list.

== Preparation ==

Developers should bring a laptop with the [http://github.com/commontk/CTK current CTK source code] downloaded and [[Build_Instructions|built]].

Use the [http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers CTK developers mailing list] to discuss build issues and topics for ongoing work.

Phone conferences have been scheduled in the weeks leading to the event:

'''https://plus.google.com/hangouts/_/g3vi3lz7sycalj74ys2xpnpr3ya'''

== Topics and Projects ==

Consider reading [http://www.commontk.org/index.php/Contributing_to_CTK#Integrate_your_new_feature Contributing_to_CTK#Integrate_your_new_feature]

Reminder: when integrating branches, remember to use --log --no-ff when merging.

We plan to have concrete hacking topics as well as dedicated discussions in smaller groups. People are encouraged to show their interest in a particular subject by adding their name to the list below.

=== Hacking Topics ===

==== Infrastructure ====

* Qt5 migration (Christian)
* Packaging / install support (Marco)
* Dashboard
** General Situation: Continuous/Nightly clients, coverage
** Configurations: Qt4, Qt5, etc.
** Travis CI (Sascha, Steve)

==== DICOM ====

* Multi-frame support (Steve, Christian, Michael)
* Making CLIs read and write valid DICOM (Steve, Michael)
* Anonymization (Andreas Fetzer, Marco, Steve, Stefan)
** Client-side options: gdcmanon, dcmtk (?), dcmjs, DicomCleaner, CTP...

==== XNAT ====

* Improve and extend the XNAT API (Sascha Zelzer, Miklos Espak)
** Data editing
** Caching
** Filtered data query based on data type and/or properties
** Launch pipelines (remote) and follow progress

==== CLI ====

* Make it customisable what options to generate to the final command (Gergely Zombori)

==== ?? ====

=== Planned Discussions ===
* Possible extensions of CTK to the IGT domain
** OpenIGT link
** ...
* QIICR Presentation
==== ... ====

== Agenda ==

==== Monday ====

Opening discussion
* Review topics and projects
* Plans for the week
* Review [https://github.com/commontk/CTK/issues?state=open open issues on github].

Evening:

==== Tuesday ====

During the day: hack, hack, hack...

Evening:

==== Wednesday ====

During the day: hack, hack, hack...

16:00 Famous Old City tour guided by Hans-Peter Meinzer

==== Thursday ====

During the day: hack, hack, hack...

Evening:

==== Friday ====

During the day: hack, hack, hack...

11:00: Closing discussion

Afternoon: hack or travel

== Travel & Hotel ==

===Local contacts===

* Marco Nolden (m.nolden@dkfz-heidelberg.de)
* Sascha Zelzer (s.zelzer@dkfz-heidelberg.de)
* Andreas Fetzer (a.fetzer@dkfz-heidelberg.de)

===Transportation===

It takes about an hour from Frankfurt Airport (FRA) to Heidelberg Main Station with one change in Mannheim. If you stay in the Old Town you can also look for connections going to "Heidelberg Altstadt". You can look it up at [http://www.bahn.de/p_en/view/index.shtml Deutsche Bahn], but they run quite frequently.

'''Local:''' from the Old Town, "Universitätsplatz", runs bus number 32 via Main Station to DKFZ, exit at "Chirurgische Klinik", bus direction is "Neuenheim". After you exit, DKFZ is on your right.

During the day the bus runs every 10 minutes in both directions, timetables are also available at [http://fahrplanauskunft.vrn.de/vrn/XSLT_TRIP_REQUEST2?language=en VRN].

===Lodging===

We recommend to stay in the historic Old Town. There is an easy direct bus ride every 10 minutes from there to DKFZ.

We have reserved a number of rooms at the [http://www.hollaender-hof.de/en/ Holländer Hof] hotel! Please use "CTK 2014" when you do a reservation there. Of course there are plenty of other hotels in that area, e.g. [http://www.hotel-goldener-hecht.de/ Goldener Hecht] or the oldest house in town, [http://www.ritter-heidelberg.de/ Hotel zum Ritter].

===Weather===

November is a rather wet month. [http://www.weather-and-climate.com/average-monthly-Rainfall-Temperature-Sunshine,heidelberg,Germany Average weather in Heidelberg]

===Food===

Plan on having breakfast at your hotel before the meeting. Please email the organizers if you have any allergies or dietary restrictions.

Being a university and hospital campus, there are several lunch possibilities, including cafeterias, a students mensa, and two restaurants.

===Optional Activities in the Area===

File:Niftyreg-MeVisLab.png

2013-12-04T13:18:52Z

Hans Meine: uploaded a new version of "File:Niftyreg-MeVisLab.png": updated version for CLI in context page

reg_aladin in MeVisLab (for "CLI in context")

Documentation/CLI In Context

2013-12-04T13:08:52Z

Hans Meine: add MeVisLab screenshot

This page lists some example and notes on different integration of CLI modules in different frameworks including CTK (see [[Documentation/Command_Line_Interface]]). The first interoperability testing was done during the [http://www.creatis.insa-lyon.fr/Interoperability_workshop third] VPH NoE Imaging workshop hold in Lyon, France on October 22-23, 2012. It will be continued in consecutive hackfests. The aim is to try to plug in CLI modules in CLI compatible frameworks and come up with possible improvement of the CLI standard, advice to CLI module and CLI framework developers.

== Events ==

* [[CTK-Hackfest-Nov-2011|CTK Hackfest]] in Sophia Antipolis, France in November 2011
** Preliminary work to integrate CLI into GIMIAS
* [[CTK-Hackfest-Jul-2012|CTK Hackfest]] in Boston, USA in July 2012
** Preliminary work to integrate CLI into MITK
* [http://www.creatis.insa-lyon.fr/Interoperability_workshop 3rd VPH NoE Imaging workshop] in Lyon, France on October 22-23, 2012
** [[#First_Interoperability_tests|First Interoperability tests]] with CTK, GIMIAS, NiftyView and Slicer
* [[CTK-Hackfest-Dec-2012|CTK Hackfest]] in Bologna, Italy on December, 2012
** Preliminary work to integrate CLI into medInria, MAF3
** Semi-Automatic framework CLI integration tests
* [[CTK-Hackfest-Nov-2013|CTK Hackfest]] in London, UK on November, 2013
** [[#Second_Interoperability_tests|Second Interoperability tests]]: GIMIAS's Command Line Plugins in CTK's Command Line Module Explorer, CTK's Command Line Modules in Taverna Workbench

== First Interoperability tests ==

These first tests mainly concern the integration of niftyreg (registration algorithms from UCL). The different stages of integration are: load, execute and results. Meaning that the CLI module can be loaded. executed and provides the same results as if it was run only from the command line. The problems we encountered were:

* GIMIAS does not support to have a `default` element different that `None` for the output, not sure about the `advanced` option for the `parameters` element
* niftyreg was using `fileExtensions` with stars (`*.nii`) which is not supported by neither GIMIAS nor Slicer (the star is directly used in the file name)
* The default output folder should be set to the user folder and not the running one, otherwise the CLI module can crash because they were denied access to write in that folder (for example `Program Files` under Windows)
* What to do with CLI modules that have dependencies on shared libraries with the platform but of different versions? Platforms should have the option to only use the libraries shipped with the CLI module
* Platforms should align the way they treat data since if two load data differently, the same CLI module could give different results

It would be interesting to create test CLI modules for these integration tests. For example one that exposes all possible types of options, one running a simple algorithm without any dependencies (as niftyreg) and one with dependencies.

Some thoughts on the tested platforms:
* Niftyview has nice controls on the way CLI modules are found and loaded (control on the `XML` validation)
* Slicer has a nice display of the loaded and non loaded CLI modules (appear in red, there could be more explanation why the loading failed)

Test datasets:

The test datasets [https://drive.google.com/file/d/0B3kBRNGHGeP0bGFjZlZNcHJLNEU/edit?usp=sharing source_2down.nii] and [https://drive.google.com/file/d/0B3kBRNGHGeP0N2gzZTVYV2JTX28/edit?usp=sharing target_2down.nii] were obtained from [http://brainweb.bic.mni.mcgill.ca/brainweb BrainWeb] and [http://adni.loni.usc.edu/ ADNI].

Here are the snapshots of niftyreg on the different platforms:

<gallery caption="niftyreg on the different platforms" widths="400px" heights="300px" perrow="3">
Image:Niftyreg-ctk.png|CTK command line module explorer
Image:Niftyreg-slicer.png|3D Slicer
Image:Niftyreg-niftyview.png|NiftyView
Image:Niftyreg-gimias.png|GIMIAS
Image:medinria-cli-niftyreg.png|MedInria
Image:Niftyreg-MeVisLab.png|MeVisLab
</gallery>

== Second Interoperability tests ==

* GIMIAS's Command Line Plugins in CTK's Command Line Module Explorer

This interoperability test was done under Windows 8. Similar steps can be performed in other platforms.

Typically, GIMIAS's Command Line Plugins (CLPs) are located in folder '''<GIMIAS_install_dir>\commandLinePlugins'''. However, the DLL dependencies of these CLPs are located in '''<GIMIAS_install_dir>'''. This is a problem when attempting to use GIMIAS's CLPs in CTK's Command Line Module Explorer (CLME), as the CLME will fail to load the CLPs.

This can be easily solved by copying GIMIAS's CLPs in a different folder, let's say '''<CLP_folder>''', along with its DLL dependencies (for finding out the DLL dependencies of a CLP, a program such as [http://dependencywalker.com/ Dependency Walker] can be used).

After creating '''<CLP_folder>''' and copying the necessary files in it. Start CTK's CLME, go to menu "Module" and choose "Options". In "Module Settings" go to "Search Paths", and then add '''<CLP_folder>''' to the search paths. Press "OK" and the CLME will scan '''<CLP_folder>''' and load the CLPs.

If the loading process fails, you are probably missing a DLL dependency, close the CLME and go to the cache folder ('''<user_directory>\AppData\Local\CommonTK\CommandLineModuleExplorer\cache''' on MS Windows). Clear the content of that directory, add the additional DLL to '''<CLP_folder>''' and then start the CLME again.

If a CLP shows up in the list with a warning sign, place the mouse on top of the CLP's name and look at the warning message. Most likely the XML that defines the CLP has a compatibility problem with the CLME, which means that is does not adhere to the [http://www.commontk.org/docs/html/ctkCmdLineModule.xsd CTK XML Schema]. See the definition of the Schema, correct the XML of the CLP, clear CLME's cache folder as described in the previous paragraph, and start the CLME again.

After following these steps, you will be able to see and use your CLP in the CLME. '''This means that you can share your GIMIAS's CLP with any CTK user at any time, by just sharing your CLPs executable file and its DLL dependencies'''.

The following image shows GIMIAS's CLPs loaded in CTK's CLME. The "Create a DICOM Series" CLP is selected. The "Settings" dialog is also shown, indicating how to add the CLPs directory to the CLME's search paths. Notice that some CLPs are shown with a warning sign, so their XML definitions has to be corrected.

[[File:GIMIAS_CLPs_on_CTK_CLME.png|400px]]

* CTK's Command Line Modules in Taverna Workbench

[http://www.taverna.org.uk/download/workbench/ Taverna Workbench] is an open source Workflow Management System written in Java. GIMIAS's Command Line Plugins (CLPs) can be used in Taverna Workbench for creating medical imaging workflows composed of several filters. In order to be able to do this, the '''Center Computational Imaging and Simulation Technologies in Biomedicine (CISTIB)''' at the [http://www.shef.ac.uk/ University of Sheffield] has created a Taverna Workbench plugin for GIMIAS.

General instructions on how to install GIMIAS Command-Line Taverna Plugin can be found [https://drive.google.com/file/d/0B3kBRNGHGeP0dE53THFMYjdsdDQ/edit?usp=sharing here].

In this interoperability test, a CTK Command Line Module was created and tested with GIMIAS Command-Line Taverna Plugin. The sample plugin is called '''CopyPlugin'''. It is a simple code to open a VTK ASCII file containing a PolyData, and save the contents of the file on another VTK file. The plugin code can be accessed [https://drive.google.com/file/d/0B3kBRNGHGeP0bVZVWHZkS1NydnM/edit?usp=sharing here].

The result was successful, which means that '''GIMIAS's CLPs and CTK's Command Line Modules can be combined to create processing workflows in Taverna Workbench !!'''.

The following image shows the CopyPlugin running on CTK's Command Line Module Explorer.

[[File:COPYPLUGIN_CTK_CLME.png‎|400px]]

The CopyPlugin Command Line Module Explorer can also be imported into GIMIAS, see the following image

[[File:COPYPLUGIN_CTK_GIMIAS.png|400px]]

The following image shows a simple workflow that includes the CopyPlugin, after being imported using GIMIAS Command-Line Taverna Plugin.

[[File:CTL_CLM_TAVERNA.png|400px]]

GIMIAS's CLPs and CTK's Command Line Modules can be combined into the same Taverna workflow. See the following image where a Marching Cubes GIMIAS's CLP is used along with the CopyPlugin, a CTK Command Line Module.

[[File:GIMIAS_CTK_WORKFLOW.png|400px]]

File:Niftyreg-MeVisLab.png

2013-12-04T13:07:26Z

Hans Meine: reg_aladin in MeVisLab (for "CLI in context")

reg_aladin in MeVisLab (for "CLI in context")