MedINRIA 2.0 Platform architecture overview

1

• MedINRIA 2.0 - Platform architecture overview

Olivier Clatz Julien Wintz
2
Context

• Multiple software
• MedINRIA
• CardioViz3D
• YAV
• Multiple operating systems
• Linux
• MacOSX
• Windows
• Multiple data to deal with
• Scalar, vector, tensor images
• Static or dynamic images
• Static or dynamic meshes

• Diverse algorithms
• image processing
• visualization
• FEM models
• Different users
• Clinicians
• Research scientists
• Many contributors
• Internal
• External

3
Problem

• Non compatible codes - constrained architectures
• Integration policy - compilation and dependencies
• Code maintenance
• Hard to get familiar with concepts for newcomers
• Divergence of philosophy

4
A modular architecture

• No prior knowledge of its functionalities
• Low level behavior furnished by plugins
• High level behavior furnished by scripts

5
A modular architecture
6
Kernel
7
Kernel

• Organized into layers (dtkCore, dtkScript,
  dtkSql, dtkGui )
• Qt based (only)
• Cross platform library handling
• Cross platform introspection
• Graphical user interface
• Built using cmake

A set of software components developed and
maintained at INRIA for scientific software
development
8
Kernel core layer

• Provides hierarchies of virtual data classes
• Provides hierarchies of virtual processing
  classes
• Provides hierarchies of virtual visualization
  classes
• Provides factories to manage them all
• Provides a plugin abstract interface
• Provides a plugin manager

9
Kernel script layer

• An abstract interpretation engine
• Embeds interpreters through specializations

10
Plugin
11
Plugin

• Technically speaking
• A dynamic library
• Built independently
• Relying on a common basis than the target
  application

• Conceptually speaking
• A container of concrete concept types
• Specializing abstract concept types
• Registers these types to a factory
• An optional user interface
• An optional glue to external libraries

Should be as atomic as possible to provide the
highest modularity level possible
Define low level behavior
12
Script
13
Script

• Manipulate wrapped layers
• No matter the language

Manipulate plugins, external libraries wrappers
and the application to define a high level
workflow
14
Platform
15
Platform

• Domain specific use of dtks layers
• Manipulate abstract concepts data, processing
  and visualization
• Plugin manager (dtkCore)
• Script interpreter (dtkScript, dtkGui)
• Domain specific specialization of dtks layers
• User interface (medGui dtkGui - QtGui)
• Database (medSql dtkSql QtSql)

Browsing area
Viewer area
Workspace area
16
Platform Operating systems
17
Dependencies licensing
18
Examples

• Tensor visualization
• ITK based plugins (data)
• VTK based plugins (visualization)
• Static user interface (from plugin)
• Dynamic user interface (from script)

19
Examples

• Tensor visualization
• ITK based plugins (data)
• VTK based plugins (visualization)
• Static user interface (from plugin)
• Dynamic user interface (from script)
• Design

20
Examples

• Tensor visualization
• ITK based plugins (data)
• VTK based plugins (visualization)
• Static user interface (from plugin)
• Dynamic user interface (from script)
• Usage scenario - plugins

21
Examples

• Tensor visualization
• ITK based plugins (data)
• VTK based plugins (visualization)
• Static user interface (from plugin)
• Dynamic user interface (from script)
• Usage scenario - script

def init() buttn widgetFactory.createButton
("Run", "run()") group widgetFactory.create
GroupBox("Tensor") group.addButton(buttn)
holder.addWidget(group.widget()) def run()
global data, view, imdata, viewer tndata
dataFactory.create("itkDataImageTensor")
tndata.read("...") imdata
dataFactory.create("itkDataImageDouble3")
imdata.enableReader("itkDataImageDouble3Reader")
imdata.read("...") view
viewFactory.create("vtkViewImage3DO")
view.enableInteractor("vtkViewInteractorTensors")
tndata.update() imdata.update()
proxy workspace.viewer().newView()
proxy.attach(view.widget())
view.setData(tndata) view.setData(imdata)
22
Examples
23
Roadmap

• Next months
• First LGPL software release
• Image visualization for clinical usage
• Limited computational capacities
• Access to existing wrapped libraries through
  script
• Tutorials for scripts plugins development
• Documentation
• Website
• Next year
• Advanced image processing and visualization
• Visual programming
• Advanced user interface elements

24
What's most important for a common platform /
toolkit?

• Unified development process
• Open-source community
• Powerful end-user application
• Extensible end-user application
• Heterogeneous plugins
• Scripting support
• Rapid prototyping

• General extension concept
• Workflow modeling
• Multiple consistent views
• Scene graphs
• Pipeline concept
• Visual programming

25
How could a collaboration look like?

• Possible ways of collaboration
• Common Toolkit, composed from existing toolkits
• Common Toolkit, implemented from scratch
• Funding sources ?