Events:CTK-Workshop-Chicago-2009

From NAMIC Wiki
Revision as of 21:56, 29 November 2009 by MarcoNolden (talk | contribs)
Jump to: navigation, search
Home < Events:CTK-Workshop-Chicago-2009

The Common Toolkit Workshop at RSNA, Chicago, IL

Nov 29 2009

  • The goals of the CommonTK are to:
    • provide a unified set of basic features for use in medical imaging using BSD style licenses
    • facilitate the exchange and combination of code and data
    • document, integrate, and adapt successful solutions
    • avoid duplication of code and data
    • continuously extend to new tasks within the scope of the toolkit (medical imaging) without burdening existing tasks

Past meetings: initial meeting in Heidelberg in June and a second meeting in Oxford, UK in September. CTK is a pro-tempore group of like minded technically oriented software tool builders. We expect to release a first version of CTK within a year. If you are interested to learn more, please contact Hans Peter Meinzer or Ron Kikinis.

Links

Schedule

Sunday, Nov 29

  • Time: 9:00 AM – 6:00 PM
  • Venue: McCormick Place, Lakeside Building
  • Date: Sunday, November 29, 2009
  • Room: E262

Detailed Agenda

  • Select a logo
  • Morning: Modules / Applications
    • The CTK Layer Structure (Slides) (Ivo)
    • BlueBerry (Sascha)
    • Slicer Modules and Extensions Slides (Ron)
    • WG23 DICOM Application Hosting / XIP (Lawrence, Gianluca)
    • Towards a European project submission (Olivier)
  • Afternoon: Qt Progress
    • 1:00 - 3:00 Nokia will present:
      • Roadmap: Evolving features of Qt
      • Community involvement processes
      • Q&A, e.g.:
        • Qt-Scripting support: current features and future plans?
        • Qt-Plugin concepts: current features and future plans?
        • separation of the Qt-non-GUI classes from the GUI part
        • are there plans for inter-process communication (IPC) support in Qt?
    • 3:00 - 3:15 Update on qCTKWidgets (Slides) being developed in Slicer's Qt Port (Ron)
    • TBD: other Qt progress updates
    • role of Qt in the CTK core
  • Other topics if time permits
    • Data types
    • Models for interaction

Minutes

Layer architecture

The CTK Layer Structure (Slides) (Ivo)

  • describes dependencies of toolkits, not meant as inheritance
  • discussion about dependencies between ITK, VTK, CTK. Unification or creating dependencies seem unrealistic. The topic is deferred since Steve is not present and he also raised the topic in email discussions.
  • TY: visualization community is not represented
  • TY: ITK and VTK have a lot of users, excutive decisions about unification of coordinate systems necessary
  • summary: ITK, VTK and CTK will most probably coexist on the same level.
  • OC: CTK is the glue, not provide processing
  • TODO: question to steve and gianluca about unification.
  • LT: gianluca has some concept of xml wrapped processing independent of underlying toolkits. not as inefficient as one thinks. some kind of conversion will always be necessary.
  • goal of the presentation: get some concept where to put things if an idea comes up
  • open questions: unification of core classes, interfacing between toolkits: XML, CTK core mechanisms

Package system

  • OC: no vcs mechanism exists yet to manage complex subproject / module structures efficiently
  • TY: packages can be mutually exclusive if they use special software or hardware
  • summary: this remains a very important and complex task

general summary

  • we agree on a layer structure, but not too deep
  • LT recalls that we agreed on Qt Core for CTK core in Heidelberg
  • mailing list discussion: it was proposed to use everything from ITK if it is in there.
  • summary: qt license issues: LGPL fullfills most needs of CTK, some issues need to be adressed:
    • Qt should always be built seperately
    • static linking, template classes, distribution (see also questions page of Ivo's slides)
  • OC: nobody wants to inherit from another toolkit forever
  • SZ: advantages of Qt: scripting, meta-object / reflection system.
  • OC: CTK should provide means for converting / adapting to Kitware mechanisms / classes
  • IW: CTK core should provide some common basic features; glueing mechanisms should rather be part of an optional module
  • summary: one CTK module, but not part of the core, provides mechanisms for common data exchange / conversion.

hacker meeting

  • HPM: Steve Pieper should organize it, week beginning of 22nd February or 1st of March. 10 people for a week, 1-2 persons per team. goal: produce some lines of code (see Ivo's slides)
  • OC raises the question of intellectual property of the written code and visibility of CTK contributors
    • RK: there needs to be an institution or foundation
    • summary: the topic is deferred, next step: KC will ask SA about advice, HPM and OC will care for European visibility
  • HPM: suggests Heidelberg as location
  • TODO: HPM writes an invitational email
  • TODO: RK writes an email about the IP issue.
  • OC proposes that everyone taking part writes and publishes some classes in advance as a basis for discussion
  • RK sent a doodle link to the ctk mailing list as a proposal, if not enough people can attend a new date has to be chosen
  • next general (short) meeting will be at SPIE

Blueberry Presentation

BlueBerry (Sascha)

  • PL: unloading of plugins and services would be useful
  • versioning of plugins is a strength but the CTK core should have stable interfaces
  • slicer also has some versioning of plugins
  • running application parts in different processes can solve a lot of problems
    • WG 23 application hosting uses similar concepts
  • OC: loose coupling is essential for CTK
  • TY: support for scripting and different languages is very important

Lunch break

Slicer

Slicer Modules and Extensions Slides (Ron)

  • Plugin version compatibility is checked by recompiling and using dashboards, matching plugins are provided with an extension manager in the slicer application
  • total number of modules is unknown, not everything is contributed back
  • decision what to put in the core: a lot of experience necessary

Qt / Nokia

  • roadmap is online
  • difficulties with qt:
    • keeping everything in complex rendering environments
    • keep local and remote versions of applications in sync
    • difficult debugging in complex signal/slot applications
  • Qt wants to offer infrastructure for development, get more contributions


Participants

  • Hans-Peter Meinzer, German Cancer Research Center, Heidelberg
  • Ron Kikinis, Harvard Medical School, Boston, MA
  • Lawrence Tarbox, Mallinckrodt Institute of Radiology, St.Louis
  • Patric Ljung, Siemens Corporate Research, Princeton
  • Kevin Cleary, Georgetown Medical Center, Washington, DC
  • Olivier Clatz, INRIA Sophia Antipolis, France
  • Ivo Wolf, German Cancer Research Center, Heidelberg
  • Marco Nolden, German Cancer Research Center, Heidelberg
  • Sascha Zelzer, German Cancer Research Center, Heidelberg
  • Clay Thongnopneua, Qt team, Nokia

Slides

In attendance on November 29 2009