File:Niftyreg-MITK-Workbench.png

2014-03-28T18:06:10Z

Sascha:

Documentation/CLI In Context

2014-03-28T18:05:21Z

Sascha: /* First Interoperability tests */

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
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]]

XNAT Discussion

2013-11-13T14:45:39Z

Sascha:

CTK-Hackfest-Nov-2013

2013-11-06T11:23:55Z

Sascha: /* Wednesday */

== Introduction ==

'''Date:''' Nov 4-8, 2013

'''Location:'''

Room 1.19 (Monday, Friday) and Room 2.14 (other days)
Malet Place Engineering Building, University College London.

[[#location|How to get here.]]

'''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:''' Matt Clarkson (m.clarkson@ucl.ac.uk), Miklos Espak (m.espak@ucl.ac.uk)

'''Organizing Committee:''' (need to ask people)

'''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
|-
|Matt Clarkson
|University College London, UK.
|-
|Miklos Espak
|University College London, UK.
|-
|Nicolas Toussaint
|University College London, UK.
|-
|Marco Nolden
|German Cancer Research Center, Heidelberg, Germany.
|-
|Sascha Zelzer
|German Cancer Research Center, Heidelberg, Germany.
|-
|Andreas Fetzer
|German Cancer Research Center, Heidelberg, Germany.
|-
|Steve Pieper
|Isomics, Inc. Cambridge, USA.
|-
|Florian Vichot
|INRIA, Sophia-Antipolis, France
|-
|Ivo Wolf
|Mannheim University of Applied Sciences, Germany
|-
| Ernesto Coto
| University of Sheffield, UK.
|-
|}

{|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 (London time)
|-
|Jean-Christophe Fillion-Robin
|Kitware Inc, North Carolina, USA
| 1pm to 6pm
|-
|Michael Onken (planned)
|OFFIS, Germany.
| as needed. Skype: "michaeloffis"
|-
|Csaba Pinter
|Queen's University, Kingston, ON
| TBD
|-
|}



{{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:
* To be announced

== Topics and Projects ==

=== XNAT Library ===

Interested people: Miklos, Nicolas, Florian, Ivo, Sascha

* Stabilize API and make it more robust
* Merge to master

Open topics

* Error handling (Miklos)
* Timeout handling (Miklos)
* Unit tests for ctkXnatCore
* Zip support (Sascha)
* Up/Download support in the API (Sascha / Miklos)
* SSL support (ask about disabling SSL) (Florian?)
* Support browsing files attached to assessments
* General API review (Sascha, Miklos, Ivo, Florian)
* Add API documentation

=== CLI Library ===

Florian, Sascha, Ernesto, Steve, Marco

Open Topics

* Add a CTK "test" for validating the XML of external CLIs
** Maybe a "web service" for quickly validating the XML files
* CTK should become the official CTK schema hosting site
* Default values for some elements are problematic (e.g. for SpinBox)
** Have a best practices document how to handle optional default values
* CLIs depending on external dependencies (shared libraries) are problematic
** Probably nothing we can solve inside CTK
* The UiLoader should be more customizable (JC did that in a branch for the Slicer integration)
* Maybe have a way to check for long running modules during the XML retrieval and cancel them (more of a developer thing)
* Add a method for clearing the XML cache (probably in ctkCmdLineModuleManager)
* Having a new web services front-end could be interesting

Discussion

* Make GIMIAS CLI modules work with the ctkCmdLineModuleExplorer (Ernesto)

=== DICOM Application Hosting ===

Ivo, Sascha

=== DICOM Libraries ===

Andreas, Steve

* Improve and finish the widgets
* DICOM Database backend (Marco, Steve)

=== CTK packaging ===

Marco, Sascha

* continue [[Debian_Packaging | Debian packaging support]]

=== General Discussion ===

* Create support for CLI Web Services in CTK?
* Could we make CLI modules run in Osirix?

== 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...

15:00 Google Hangout with US and other participants

* Talk about DCMTK_DIR ([https://github.com/commontk/CTK/issues/382 Issue 382])
** Michael: Would integrate the DCMTKConfig.cmake file but needs more time to check the changes and make sure it works for everyone
** Jc: NO_DEFAULT_PATH in FindDCMTK.cmake would work for Slicer, CTK, etc. but in the future (when all distributions contain a DCMTK package with a DCMTKConfig.cmake) FindDCMTK.cmake should not be needed anymore
** Marco: We still need a way to find the system installed DCMTK
** Steve: We should be able to tell the scripts that it should find a specific DCMTK version and not automatically prefer one version over another. E.g. there could be a system DCMTK but we would still want to use a developer DCMTK build
** Jc: Is not sure why it failed at all on Csaba's machine. Will look remotely at the concrete problem on that machine.
** Marco: NO_DEFAULT_PATH would still work for the Debian packages if we pass DCMTK_DIR=/usr
** Steve: Mentions that find_program was gone from FindDCMTK.cmake leading to test failures. It is probably okay to add the find_program paths to the CMakeLists.txt file of the CTK tests.
** Jc: The DCMTK fixes are in the commontk DCMTK fork
** Marco: We should not depend on the commontk DCMTK fork since it makes compatibility with official snapshots difficult
** Jc: We should set-up a dashboard for DCMTK builds on cdash.org
* Discuss CTK install and Debian package support
** Marco: Let's have a separate hangout for that
* Failing tests on Steves machine (and others like Ivos)
** Steve: ctkCrosshairTest2 is failing on all platforms.
** Jc: It is not used anymore in Slicer
** Steve: We could remove the class and the test if nobody is using it
** General agreement
* Dashboard
** Jc suggests to move back to a traditional dashboard style (no splitting by library)
** Everyone agrees

Evening:

==== Wednesday ====

10:00 Roadmap discussion

* Matt: Right now we have Widgets, DICOM, etc. is that still how we see CTK?
* Steve:
** Generally we factor out common stuff. Mainly project driven requirements
** Adding JavaScript widgets for image processing (on top of e.g. jQuery) would be nice
* Marco:
** Currently we are focusing on data management aspects (XNAT, DICOM RT, CLIs, etc.)
** Image guided therapy applications are driving the requirements for us
** New data structures for imaging are hard to agree on
* Marco:
** How CTK is presented to the outside is important
** CTK could provide standardized approaches to develop e.g. CLIs
* Florian:
** Students ask what they could CTK use for - has to tell them that it is rather for application/platform developers
* Matt:
** Pushing the XNAT work is important for us
** Also interested in mor DICOM data structure support
** Wrapping algorithms inside a proper DICOM workflow would be interesting
** What about Application Hosting?
* Steve:
** Its not directly in the QIICR proposal
* Sascha:
** We are still not ready for a production grade implementation
** Same goes for probably any other implementation
* Steve:
** Syngo Via does not seem to see a role for application hosting (they have a kind of distributed client server architecture)
** Doesn't fit with running applications locally on the workstation supporting application hosting
* Marco:
** Physicians are not really happy with proprietary solutions so there is some pressure for a more open system
** There is an IHE profile which contains application hosting, so there is also some interest
* Matt:
** We are working on XNAT support which also supports pipelines. But there is also Nipype, the GIMIAS Taverna approach, etc.
** Having XNAT in CTK is nice since people converge somehow to using the same type of database
* Marco:
** What is QIICR using as a data backend?
** Having a more light-weight, easily installable and searchable PACS would be nice
* Steve:
** The plan is to use TCIA
** It is unclear which backend technology is used for it

Conclusion:

* We are pretty much happy as it is
* A light-weight database solution would be really nice to have
* Same goes for a pipeline system

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

Evening:

==== Thursday ====

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

Evening:

==== Friday ====

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

Late morning; Closing discussion

Afternoon: hack or travel



== Travel & Hotel ==

'''Local contact'''

Need any help in organizing your visit, contact Miklos Espak (m.espak@ucl.ac.uk).
If you have any troubles during your visit, call +44 792 6656 927.

'''Transportation'''

[http://www.ucl.ac.uk/maps/public-transport How to get to the UCL.]

'''Lodging'''

Hotels in central London can be expensive, this one seems reasonably priced:

* [http://www.imperialhotels.co.uk/tavistock The Tavistock Hotel]

<div id="location">'''Meeting Location'''</div>

Malet Place Engineering Building, University College London
[http://goo.gl/maps/2encP]

Monday and Friday: room 1.19
Other days: room 2.14

The reception is at the '''Engineering Front Building''' right at the gate, so please come there and refer to the CTK hackfest.

[http://www.ucl.ac.uk/maps UCL Bloomsbury campus map]

[http://crf.casa.ucl.ac.uk/ UCL campus route finder]

'''Weather'''

Daily temperature will be around 12-15C (53-59F), mostly dry, light rain is possible some days.

'''Food'''

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

Debian Packaging

2013-11-05T15:47:09Z

Sascha: /* Open issues */

= Status =

There is an experimental debian package here: http://packages.qa.debian.org/c/ctk.html

The current Debian sources for CTK are here: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/ctk/trunk/debian/

Some experimental changes are published here: https://github.com/nolden/ctk-debian and https://github.com/nolden/CTK/commits/debian-patches ''Update 11/05/2013:'' everything from here has been merged upstream, apart from the DCMTK workarounds, see [[#DCMTK|below]].

== Related Issues and Pull Requests on Github ==

https://github.com/commontk/CTK/issues/65

https://github.com/commontk/CTK/pull/158

== Working configuration ==

''Updated 11/05/2013''

This is a working subset (possibly not complete) of CTK that builds with Debian Unstable, use this as an initial cache

<pre>
CTK_APP_ctkCommandLineModuleExplorer:BOOL=ON
CTK_APP_ctkDICOM:BOOL=ON
CTK_APP_ctkPluginBrowser:BOOL=ON
CTK_APP_ctkPluginGenerator:BOOL=ON
CTK_BUILD_QTDESIGNER_PLUGINS:BOOL=ON
CTK_ENABLE_DICOM:BOOL=ON
CTK_ENABLE_PluginFramework:BOOL=ON
CTK_ENABLE_Widgets:BOOL=ON
CTK_LIB_CommandLineModules/Backend/FunctionPointer:BOOL=ON
CTK_LIB_CommandLineModules/Backend/LocalProcess:BOOL=ON
CTK_LIB_CommandLineModules/Core:BOOL=ON
CTK_LIB_CommandLineModules/Frontend/QtGui:BOOL=ON
CTK_LIB_CommandLineModules/Frontend/QtWebKit:BOOL=ON
CTK_LIB_Core:BOOL=ON
CTK_LIB_DICOM/Core:BOOL=ON
CTK_LIB_DICOM/Widgets:BOOL=ON
CTK_LIB_PluginFramework:BOOL=ON
CTK_LIB_Visualization/VTK/Core:BOOL=ON
CTK_LIB_Visualization/VTK/Widgets:BOOL=ON
CTK_LIB_Widgets:BOOL=ON
CTK_PLUGIN_org.commontk.configadmin:BOOL=ON
CTK_PLUGIN_org.commontk.eventadmin:BOOL=ON
CTK_PLUGIN_org.commontk.log:BOOL=ON
CTK_PLUGIN_org.commontk.metatype:BOOL=ON
CTK_PLUGIN_org.commontk.plugingenerator.core:BOOL=ON
CTK_PLUGIN_org.commontk.plugingenerator.ui:BOOL=ON
CTK_SUPERBUILD:BOOL=OFF
DCMTK_DIR:PATH=/usr
</pre>

== Proposed package structure ==

/usr/lib/:
# CTK libraries
libCTKCore.so
libCTKDICOM.so
...
/usr/lib/ctk-plugins/:
# CTK plugin framework plugins
liborg_commontk_eventadmin.so
liborg_commontk_dah_core.so
...
/usr/lib/x86_64-linux-gnu/qt4/plugins/designer/:
# Qt designer plugins
libCTKWidgetsPlugins.so
libCTKDICOMWidgetsPlugins.so
/usr/include/ctk/:
# all public library headers
ctkUtils.h
ctkComboBox.h
ctkDICOMDatabase.h
...
/usr/include/ctk/org.commontk.dah.core/:
# public plugin headers
ctkDicomAppInterface.h
...
/usr/bin:
# executables (separate package "ctk" or "ctk-utils"?)
ctkDICOM
ctkCommandLineModuleExplorer

== Open issues ==
* CTK side
** installation of CMake files: make CTKConfig.cmake and UseCTK.cmake relocatable (after some cleanup), see also https://github.com/commontk/CTK/pull/158#issuecomment-6955188
** make DGraph work for external projects without a CTK source tree
** test whether CTK CMake macros work with an installation tree depicted above
** install support for Qt plugins and CTK plugins
* Debian side
** do we want to create separate packages for the various topics? (libctk-core, libctk-dicom, libctk-cli, ... )
** currently the installation paths are changed in the debian/rules files, e.g. removing the "ctk-0.1" part of the path. Is that ok or should we try to solve this as well upstream?
** should we wait for the 3.6.1 experimental package to enter "sid" or try to create some workarounds in CTK and/or the Debian package?
** if the Debian rules map files from the install tree to a different directory layout in the Debian package, how is this going to play well together with CTKConfig.cmake?

== Dependencies with potential problems ==

=== DCMTK ===

CTK is using a recent snapshot in the superbuild, but Debian includes the latest stable release 3.6.0 . Since the Bologna Hackfest in December 2012 CTK builds (again) with DCMTK 3.6.0, using one backported class that is included conditionally (scu.cc)

''Update 11/05/2013:''
* using CTK master and the Debian sid (3.6.0) package you need two patches that would be much more complicated to integrate upstream since the would be specific to Debian
* using the Debian experimental package (3.6.1) everything works fine, you have to provide <tt>-DDCMTK_DIR:PATH=/usr</tt> to the initial CMake run

=== Log4Qt ===

Log4Qt is in general not used by CTK anymore. There is one plugin left using it but this is more of a technical study and can be turned of:

<pre>CTK_PLUGIN_org.commontk.log4qt:BOOL=OFF</pre>

''Update 11/05/2013:'' This plugin is outdated will be removed soon, so we should probably remove all related code from the debian package rules

=== PythonQt ===

Several patches have been submitted to upstream, some are left, a summary can be found here. If this is resolved more features of CTK can be enabled for the Debian package.

''Update 11/05/2013:'' one header is missing: ctkAbstractPythonManager.cpp:31:33: fatal error: PythonQt_QtBindings.h .

=== VTK ===

CTK Visualization Core compiles with VTK 5.8, just missing one small functionality.

=== QtSoap ===

There is a debian package called libqtsolutions-soap-2.7-1, but there is no development package so it's unclear if this can be useful.

''Update 11/05/2013:'' libqtsolutions-soap-2.7-1 is probably not useful. In the CTK context QtSoap is currently only needed for DICOM application hosting which itself is highly experimental and should probably be omitted from an initial debian package anyway

CTK-Hackfest-Nov-2013

2013-11-05T15:38:11Z

Sascha: /* Tuesday */

== Introduction ==

'''Date:''' Nov 4-8, 2013

'''Location:'''

Room 1.19 (Monday, Friday) and Room 2.14 (other days)
Malet Place Engineering Building, University College London.

[[#location|How to get here.]]

'''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:''' Matt Clarkson (m.clarkson@ucl.ac.uk), Miklos Espak (m.espak@ucl.ac.uk)

'''Organizing Committee:''' (need to ask people)

'''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
|-
|Matt Clarkson
|University College London, UK.
|-
|Miklos Espak
|University College London, UK.
|-
|Nicolas Toussaint
|University College London, UK.
|-
|Marco Nolden
|German Cancer Research Center, Heidelberg, Germany.
|-
|Sascha Zelzer
|German Cancer Research Center, Heidelberg, Germany.
|-
|Andreas Fetzer
|German Cancer Research Center, Heidelberg, Germany.
|-
|Steve Pieper
|Isomics, Inc. Cambridge, USA.
|-
|Florian Vichot
|INRIA, Sophia-Antipolis, France
|-
|Ivo Wolf
|Mannheim University of Applied Sciences, Germany
|-
| Ernesto Coto
| University of Sheffield, UK.
|-
|}

{|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 (London time)
|-
|Jean-Christophe Fillion-Robin
|Kitware Inc, North Carolina, USA
| 1pm to 6pm
|-
|Michael Onken (planned)
|OFFIS, Germany.
| as needed. Skype: "michaeloffis"
|-
|Csaba Pinter
|Queen's University, Kingston, ON
| TBD
|-
|}



{{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:
* To be announced

== Topics and Projects ==

=== XNAT Library ===

Interested people: Miklos, Nicolas, Florian, Ivo, Sascha

* Stabilize API and make it more robust
* Merge to master

Open topics

* Error handling (Miklos)
* Timeout handling (Miklos)
* Unit tests for ctkXnatCore
* Zip support (Sascha)
* Up/Download support in the API (Sascha / Miklos)
* SSL support (ask about disabling SSL) (Florian?)
* Support browsing files attached to assessments
* General API review (Sascha, Miklos, Ivo, Florian)
* Add API documentation

=== CLI Library ===

Florian, Sascha, Ernesto, Steve, Marco

Open Topics

* Add a CTK "test" for validating the XML of external CLIs
** Maybe a "web service" for quickly validating the XML files
* CTK should become the official CTK schema hosting site
* Default values for some elements are problematic (e.g. for SpinBox)
** Have a best practices document how to handle optional default values
* CLIs depending on external dependencies (shared libraries) are problematic
** Probably nothing we can solve inside CTK
* The UiLoader should be more customizable (JC did that in a branch for the Slicer integration)
* Maybe have a way to check for long running modules during the XML retrieval and cancel them (more of a developer thing)
* Add a method for clearing the XML cache (probably in ctkCmdLineModuleManager)
* Having a new web services front-end could be interesting

Discussion

* Make GIMIAS CLI modules work with the ctkCmdLineModuleExplorer (Ernesto)

=== DICOM Application Hosting ===

Ivo, Sascha

=== DICOM Libraries ===

Andreas, Steve

* Improve and finish the widgets
* DICOM Database backend (Marco, Steve)

=== CTK packaging ===

Marco, Sascha

* continue [[Debian_Packaging | Debian packaging support]]

=== General Discussion ===

* Create support for CLI Web Services in CTK?
* Could we make CLI modules run in Osirix?

== 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...

15:00 Google Hangout with US and other participants

* Talk about DCMTK_DIR ([https://github.com/commontk/CTK/issues/382 Issue 382])
** Michael: Would integrate the DCMTKConfig.cmake file but needs more time to check the changes and make sure it works for everyone
** Jc: NO_DEFAULT_PATH in FindDCMTK.cmake would work for Slicer, CTK, etc. but in the future (when all distributions contain a DCMTK package with a DCMTKConfig.cmake) FindDCMTK.cmake should not be needed anymore
** Marco: We still need a way to find the system installed DCMTK
** Steve: We should be able to tell the scripts that it should find a specific DCMTK version and not automatically prefer one version over another. E.g. there could be a system DCMTK but we would still want to use a developer DCMTK build
** Jc: Is not sure why it failed at all on Csaba's machine. Will look remotely at the concrete problem on that machine.
** Marco: NO_DEFAULT_PATH would still work for the Debian packages if we pass DCMTK_DIR=/usr
** Steve: Mentions that find_program was gone from FindDCMTK.cmake leading to test failures. It is probably okay to add the find_program paths to the CMakeLists.txt file of the CTK tests.
** Jc: The DCMTK fixes are in the commontk DCMTK fork
** Marco: We should not depend on the commontk DCMTK fork since it makes compatibility with official snapshots difficult
** Jc: We should set-up a dashboard for DCMTK builds on cdash.org
* Discuss CTK install and Debian package support
** Marco: Let's have a separate hangout for that
* Failing tests on Steves machine (and others like Ivos)
** Steve: ctkCrosshairTest2 is failing on all platforms.
** Jc: It is not used anymore in Slicer
** Steve: We could remove the class and the test if nobody is using it
** General agreement
* Dashboard
** Jc suggests to move back to a traditional dashboard style (no splitting by library)
** Everyone agrees

Evening:

==== Wednesday ====

10:00 Roadmap discussion

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

Evening:

==== Thursday ====

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

Evening:

==== Friday ====

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

Late morning; Closing discussion

Afternoon: hack or travel



== Travel & Hotel ==

'''Local contact'''

Need any help in organizing your visit, contact Miklos Espak (m.espak@ucl.ac.uk).
If you have any troubles during your visit, call +44 792 6656 927.

'''Transportation'''

[http://www.ucl.ac.uk/maps/public-transport How to get to the UCL.]

'''Lodging'''

Hotels in central London can be expensive, this one seems reasonably priced:

* [http://www.imperialhotels.co.uk/tavistock The Tavistock Hotel]

<div id="location">'''Meeting Location'''</div>

Malet Place Engineering Building, University College London
[http://goo.gl/maps/2encP]

Monday and Friday: room 1.19
Other days: room 2.14

The reception is at the '''Engineering Front Building''' right at the gate, so please come there and refer to the CTK hackfest.

[http://www.ucl.ac.uk/maps UCL Bloomsbury campus map]

[http://crf.casa.ucl.ac.uk/ UCL campus route finder]

'''Weather'''

Daily temperature will be around 12-15C (53-59F), mostly dry, light rain is possible some days.

'''Food'''

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

CTK-Hackfest-Nov-2013

2013-11-05T15:13:59Z

Sascha: /* Tuesday */

CTK-Hackfest-Nov-2013

2013-11-05T15:12:48Z

Sascha: /* Tuesday */

Main Page

2013-11-04T14:44:10Z

XNAT Discussion

2013-05-22T19:28:41Z

Sascha:

Things we could do:

* Pull out the XNAT data structures from the plug-in and create a CTK library (there have been requests for that)
* Use virtual methods in ctkXnatObject subclasses for fetching the data (i.e. move the fetch methods from ctkXnatConnection to the subclasses)
* Support asynchronous operations in ctkXnatObject?
* Support editing Xnat data and committing it back to the servere (?)
* Think about user access rights and how to handle read-only access within setters of ctkXnatObject sub-classes
* Use ctkException as a base class for ctkXnatException
* Create (asynchronous) Qt models for displaying data in list and table widgets
* Thinks about possibilities to generate GUI masks for editing or creating XNAT data objects
* Add a simple example application which reuses Xnat related Widgets from a (new) CTK library and allows to query a Xnat server

qRestAPI library:

* emit resultReceived signal in the qRestAPI class