Documentation/CLI In Context: Difference between revisions

From Commontk
Jump to navigationJump to search
Line 3: Line 3:
== Events ==
== Events ==


* [[CTK-Hackfest-Nov-2011|CTK Hackfest]] in Sofia Antipolis, France in November 2011
* [[CTK-Hackfest-Nov-2011|CTK Hackfest]] in Sophia Antipolis, France in November 2011
** Preliminary work to integrate CLI into Gimias
** Preliminary work to integrate CLI into Gimias
* [[CTK-Hackfest-Jul-2012|CTK Hackfest]] in Boston, USA in July 2012
* [[CTK-Hackfest-Jul-2012|CTK Hackfest]] in Boston, USA in July 2012

Revision as of 09:04, 18 September 2013

Home < Documentation < CLI In Context

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 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 in Sophia Antipolis, France in November 2011
    • Preliminary work to integrate CLI into Gimias
  • CTK Hackfest in Boston, USA in July 2012
    • Preliminary work to integrate CLI into MITK
  • 3rd VPH NoE Imaging workshop in Lyon, France on October 22-23, 2012
  • CTK Hackfest in Bologna, Italy on December, 2012
    • Preliminary work to integrate CLI into medInria, MAF3
    • Semi-Automatic framework CLI integration tests

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)

Snapshots

Here are the snapshots of niftyreg on the different platforms:

  • CTK command line module explorer

Niftyreg-ctk.png

  • Slicer

Niftyreg-slicer.png

  • NiftyView

Niftyreg-niftyview.png

  • GIMIAS

Niftyreg-gimias.png


  • medInria

Medinria-cli-niftyreg.png