MITK - Na-MIC

MITK module layers: building blocks; OSGi bundles. CTK Workshop Heidelberg, June 29/30, 2009. MITK: Ways of usage. MITK can be used in different ways:.
展开查看详情

1. MEDICAL IMAGING INTERACTION TOOLKIT Ivo Wolf Marco Nolden

2. CTK Workshop Heidelberg, June 29/30, 2009 Examples

3. CTK Workshop Heidelberg, June 29/30, 2009 Examples

4. CTK Workshop Heidelberg, June 29/30, 2009 Examples

5. CTK Workshop Heidelberg, June 29/30, 2009 Examples

6. CTK Workshop Heidelberg, June 29/30, 2009 Examples

7. CTK Workshop Heidelberg, June 29/30, 2009 Examples

8. CTK Workshop Heidelberg, June 29/30, 2009 Medical Imaging Interaction Toolkit (MITK)  Open-source C++ toolkit based on ITK/VTK  Coordination of visualizations and interactions  Combine modules developed independently from each other Application / PACS Viewer Plugin MITK module layers: building blocks; OSGi bundles MITK: coordination GUI- interactivity toolkit (Qt, FLTK, …) ITK: algorithms VTK: segmentation visualization registration

9. CTK Workshop Heidelberg, June 29/30, 2009 MITK: Ways of usage MITK can be used in different ways: You can …  … start a new applications from scratch  usage as a pure TK  … extend the “MITK-Main Application”:  write additional modules  plug modules into existing modules  usage as extensible application  … use the existing “MITK-Main Application”  segmentation  registration  usage as an end-user product

10. CTK Workshop Heidelberg, June 29/30, 2009 MITK: Modularization MITK‘s modular design consists of four layers: 1. Toolkit Core 2. Toolkit UI Core 3. Toolkit Modules 4. Application Layer

11. CTK Workshop Heidelberg, June 29/30, 2009 1. Toolkit Core Toolkit Core: classes required by (nearly) all applications  GUI independent part:  Data management  View synchronization  Coordinate system definition and conversion  Interaction repository->Add(image); repository->Add(surface); repository->Add(points); renderer1- >SetData(repository); renderer2- >SetData(repository);

12. CTK Workshop Heidelberg, June 29/30, 2009 2. Toolkit UI Core Toolkit UI Core: GUI specific core classes  Currently implemented for Qt3 and Qt4 (partly for FLTK, wxWidgets):  renderwindow  multi-widget  scene manager

13. CTK Workshop Heidelberg, June 29/30, 2009 3. Toolkit Modules Toolkit Modules: optional toolkit-level extensions  Core extensions: more data classes, mappers, filters, etc.  Core UI extensions: widgets  OSGi components (openCherry)  Functional modules:  Image guided therapy  Unified tracker interface: Aurora, Polaris, MicronTracker, daVinci  Synchronization of tracking devices  Tracking data pipeline  …  Segmentation tools

14. CTK Workshop Heidelberg, June 29/30, 2009 4. Application Layer Application Layer: Extensible “MITK-Main Application”  Based on an OSGi framework (openCherry, developed at DKFZ)  General extension concept  Plugins can hook into other plugins  MITK-Main Application  Minimal core application  All extensions implemented as OSGi bundles (plugins) and services

15. CTK Workshop Heidelberg, June 29/30, 2009 4. Application Layer  Bundles:  Frontends for segmentation, registration, IGT, …  Common tasks as surface extraction, measurement, …  Results from master and PhD theses  Standard services:  Data repository  Preferences  Logging

16. CTK Workshop Heidelberg, June 29/30, 2009 4. Application Layer  Why OSGi:  Established standard for component software  Loose coupling of components (SOA)  Easier exchange of binary modules through standardized metadata  Vendor independent  Successfully used for large software projects (e.g. Eclipse, Websphere, …)

17. CTK Workshop Heidelberg, June 29/30, 2009 Focus of development  Support the sustainable development of usable interactive applications  View synchronization  Modularization  Reusability  Recently: image guided therapy

18. CTK Workshop Heidelberg, June 29/30, 2009 Roadmap  Scripting  GPGPU programming  Workflow modelling  Fully specified core (prerequisite for CE/FDA approved software)  Further modularization  Fast turnaround development

19. CTK Workshop Heidelberg, June 29/30, 2009 Dreams  Plugin repository  Thin client architecture

20. CTK Workshop Heidelberg, June 29/30, 2009 Open-source status and activities  Source code availability: Source packages, Windows Installer, Read-only Subversion repository  BSD Style License  Public bug tracker  Public build and testing results (dashboard: CDash)  Contributions: some application modules, bug fix patches  Community: mailing list, ~15 posts / week  ...

21. CTK Workshop Heidelberg, June 29/30, 2009 What's most important for a common platform / toolkit? General:  High level of modularization  Unified development process (incl. testing, dashboard, ...) Content:  Continuous integration as  Consistent multiple views and interaction (2D, 3D) on arbitrary data (images, surfaces, open-source policy points, vessels, etc.)  Extensible end-user  Pipeline concept as in ITK/VTK Workflow modeling application   Support for image guided therapy  General extension concept: allow extensions of extensions  Integration into existing systems (application hosting)

22. CTK Workshop Heidelberg, June 29/30, 2009 How could a collaboration look like? Possible ways of collaboration (from loose to tight):  Regular workshops  Defined interfaces as in DICOM  Bridges between existing toolkits on different levels:  Data level: file-based exchange, inter-process communication, ...  Code level: adapter classes, common base classes, ...  “Common Toolkit”, composed from existing toolkits  “Common Toolkit”, implemented from scratch

23. CTK Workshop Heidelberg, June 29/30, 2009 How could a collaboration look like? Possible ways of collaboration (from loose to tight):  Regular workshops Sure!  Defined interfaces as in DICOM necessary  Bridges between existing toolkits on different levels:first step  Data level: file-based exchange, inter-process communication, ...  Code level: adapter classes, common base classes, ...  “Common Toolkit”, composed from existing toolkits vision  “Common Toolkit”, implemented from scratch