medinria 2 0 platform architecture overview n.
Download
Skip this Video
Download Presentation
MedINRIA 2.0 - Platform architecture overview

Loading in 2 Seconds...

play fullscreen
1 / 25

MedINRIA 2.0 - Platform architecture overview - PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on

MedINRIA 2.0 - Platform architecture overview. Olivier Clatz Julien Wintz. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'MedINRIA 2.0 - Platform architecture overview' - helki


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
context
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
problem
Problem
  • Non compatible codes - constrained architectures
  • Integration policy - compilation and dependencies
  • Code maintenance
  • Hard to get familiar with concepts for newcomers
  • Divergence of philosophy
a modular architecture
A modular architecture
  • No prior knowledge of its functionalities
  • Low level behavior furnished by plugins
  • High level behavior furnished by scripts
kernel1
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

kernel core layer
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
kernel script layer
Kernel – script layer
  • An abstract interpretation engine
  • Embeds interpreters through specializations
plugin1
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

script1
Script
  • Manipulate wrapped layers
  • No matter the language

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

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

Browsing area

Viewer area

Workspace area

examples
Examples
  • Tensor visualization
    • ITK based plugins (data)
    • VTK based plugins (visualization)
    • Static user interface (from plugin)
    • Dynamic user interface (from script)
examples1
Examples
  • Tensor visualization
    • ITK based plugins (data)
    • VTK based plugins (visualization)
    • Static user interface (from plugin)
    • Dynamic user interface (from script)
  • Design
examples2
Examples
  • Tensor visualization
    • ITK based plugins (data)
    • VTK based plugins (visualization)
    • Static user interface (from plugin)
    • Dynamic user interface (from script)
  • Usage scenario - plugins
examples3
Examples
  • Tensor visualization
    • ITK based plugins (data)
    • VTK based plugins (visualization)
    • Static user interface (from plugin)
    • Dynamic user interface (from script)
  • Usage scenario - script

definit():

buttn = widgetFactory.createButton("Run", "run()");

group = widgetFactory.createGroupBox("Tensor");

group.addButton(buttn);

holder.addWidget(group.widget());

defrun():

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)

roadmap
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
what s most important for a common platform toolkit
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 +
how could a collaboration look like
How could a collaboration look like?

Possible ways of collaboration:

  • “Common Toolkit”, composed from existing toolkits
  • “Common Toolkit”, implemented from scratch
  • Funding sources ?