The Common Toolkit Workshop at RSNA, Chicago, IL
Nov 29 2009
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.
- http://www.CommonTk.org (under development - reserved as future home page)
- http://my-trac.assembla.com/protoctk Prototype trac installation for CTK hosted by assembla.com.
Sunday, Nov 29
- Time: 9:00 AM – 6:00 PM
- Venue: McCormick Place, Lakeside Building
- Date: Sunday, November 29, 2009
- Room: E262
- Select a logo
- too busy for such a plain background
- theme 2 preferred
- logo 1+3 too similar to NSF logo
- theme 2 should have a little gap between the C and the K
- Morning: Modules / Applications
- 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
- 1:00 - 3:00 Nokia will present:
- Other topics if time permits
- Data types
- Models for interaction
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
- 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
- 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.
- 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
- 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
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
Towards a European project submission (Olivier)
- some participants of the proposal were not participants of CTK meetings
- agreements like everything is c++ could get broken
- consortium is very mixed
- TY: there is a strong dependency on WP2, this makes the project management very difficult
- discussion: medical imaging vs. biomedical community, include more partners?
Slicer Qt port
- coexistence with KWWidgets
- demonstration movies
- HPM: uniting development efforts is important, hacker meeting has to happen soon
SCR update: Patric Ljung
- TY: 1999 asked about hardware future, situation was pretty clear. Today the situation is more unclear.
- LT: upcoming things should be taken into account for design
- IW: GPU and things like that should become modules
- LT: application hosting is not frozen anymore
- TY: for the next ITK version a lot of converging ideas like in CTK have been discussed.
- HPM: modularization / plugin mechanisms have to be decided
- KC: starting with a common core, funding adds restrictions for the groups
- discussion about common data format
- common data type shouldn'n be compulsory
- create a new type on the same level like the others that could be used
- create common denominators
- OC: CTK should not only complement ITK and VTK, it should be designed flexible from the start
- SPIE 2010, LT will set up a doodle for it.
- 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
In attendance on November 29 2009