MITK Diffusion (under the hood) Klaus H. Maier-Hein (Ph.D.) Computational Disease Analysis Group Medical and Biological Informatics
Reproducibility anything less than the release of source programs is intolerable for results that depend on computation
Different levels of interoperability Different user-groups use and extend our software Department Research Center (Physics, Radiology) „Sonderforschungsbereich“ (special research area) Collaborators / “the world” MITK supports data- and code interoperability Code: “component-based” approaches Data: Nifty/Nrrd, DICOM (Q/R), XNAT, (NITRC) …
Data interoperability Different Interfaces REST, Webinterface, -applets, DICOM q/r Very flexible Upload, view, search, meta-data, manage access Support by Slicer, NiftyView, CTK (soon available) Data infrastructure of choice for SFB Heidelberg Centralized data management resource to support multiple investigators and research studies
Code interoperability Scientists don’t “waste” time on software architecture Requirements are still demanding Re-usability Interoperability Collaboration Clinical application MITK uses component technology to minimize the effort
The BlueBerry Application Framework
The MITK Workbench Views Editors
The BlueBerry application framework What is BlueBerry? The BlueBerry application framework Similar to the Eclipse RCP (but in C++) Builds plugin-based applications (OSGi-driven) Lazy loading of plug-ins (scalability) Strong encapsulation & loose coupling Reuse/recombine already existing plug-ins Flexible application layout „views“ and „perspectives“ Written for and included in MITK (but independent)
CTK Plugin Framework
Application Hosting (DICOM WG23) CTK CTK is an international initiative to provide a shared code base for re-usable components and interoperability technology. Plugin Framework Command Line Modules Widgets DICOM support Application Hosting (DICOM WG23)
CTK Plugin Framework
Dynamic OSGi-based Framework CTK Plugin Framework Dynamic OSGi-based Framework Enables service oriented architectures Enables distributed/large-scale applications
C++ implementation of the OSGi Service Layer: CTK Service Registriy C++ implementation of the OSGi Service Layer: Service registry Publish Find Service description Service provider Service requester Bind API is very close to the OSGi Service Layer specs
Plug-in structure Unique name Meta information Third-party dependencies
Simple and non-intrusive Plugin Framework Simple and non-intrusive The API is surprisingly simple, services require no special interface Reduced complexity Focus on interface/service, internals hidden Versioning Plug-ins and their dependencies are versioned
Command Line Interface
Command Line Interface Integrating command line programs Executables use XML to describe their input and output Communication via standard input/output channels Examples ITK based registration programs Compiled Matlab code Slicer CLI modules Command arguments
MITK – modular application development at different levels: Toolkit: Summary MITK – modular application development at different levels: Toolkit: Use MITK shared libs + µServices Application Framework: Create dynamic and extensible applications using BlueBerry and CTK MITK Workbench: An extensible end-user application for rapid prototyping
MITK (Diffusion) is a lot more than just a bunch of algorithms Conclusion MITK (Diffusion) is a lot more than just a bunch of algorithms CLI Modules supported by Slicer, GIMIAS, MITK, (MedInria) Very easy to adapt to the standard Immediate visibility through widely applied platforms CTK and BlueBerry allow rich plugin-based applications Everybody profits from developments Nobody wants to repeat implementations of e.g. DICOM (Diffusion) or XNAT interfaces Enables and eases distribution and reproducibility of research results
Medical and Biological Informatics German Cancer Research Center
MITK & CTK Plattform group
Computational Disease Analysis Group Jonas Michael
Thank you! www.mitk.org
Implemented OSGi specifications in CTK Plugin Framework Implemented OSGi specifications in CTK Log Service Specification Provides a general purpose message logger. Metatype Service Specification Provides a unified way to describe metadata about services. Configuration Admin Service Specification Allows to set the configuration information of deployed plugins. Event Admin Service Specification Inter-plugin communication mechanism based on a event publish and subscribe model.
OSGi Specifications OSGi Core Specifications are small OSGi Service Compendium defines many optional services:
Plug-in structure Unique name Meta information Third-party dependencies
manifest_headers.cmake OSGi meta information manifest_headers.cmake set(Plugin-Name "A human readable plug-in name") set(Plugin-Version "x.x.x") set(Plugin-Vendor "A human readable vendor name") set(Plugin-ContactAddress “Web page, email, etc.") set(Require-Plugin <list-of-plugin-symbolic-names>)
Increased complexity due to the dynamic nature of the system Conclusion Costs Increased complexity due to the dynamic nature of the system Services can come and go as they want Components are tied to the BlueBerry application framework