ITK/Release 4/Wrapping

Wrapping

High-Level Goals

SIMPLIFY ITK by allowing easy access of the toolkit from other languages, especially scripting languages, hiding some difficulties (templates, compilation ...) along the way.

Metrics

• Avoid unnecessary dependencies (see Modular ITK)
• FASTER
  • faster compilation
  • limited compilation ( see modular itk v4 )
  • faster re-compile (touching a given .h should not trigger a full re-compilation)
• Wrap 80%+ of the toolkit
• Have ITK behaves in the different languages as close to the native code as possible

Languages

• Java
• Python
• Lua ?
• Tcl ?
• see simpleITK

Comparative Examples

Required Tools and Technology

Installation is detailled here

tools

• WrapITK.
• Swig
• GccXML

WrapITK Configuration and Build Process Internals

• Build Process for Dummies

Parallel Build Status

• Parallel Build Status

Discussions and TConfs

Tcon July 19 2010

• Dropping CableSwig
• Using Swig Directly
  • Along with GCC_XML

• Two Levels of Wrapping
  • Wrapping the Simplified Layer (many wrapping tools will do)
  • Wrapping the Templated Layer (WrapITK,GCC_XML)

• Managing multiple component images
  • Microscopy use cases
  • Remote Sensing cases
  • itkVectorImage ?
  • need a "component-by-component" filter driver ?

• Make easy to add new types (e.g. another pixel type for the image...)
  • Run time binding may help here (along with the internal finder)

• Make possible (easy?) to distribute binaries of the wrapping.
  • Maybe use the package manager (Ryppl ?).
  • The same goes for the C++ version.

• Remove (or deprecate) itkSetVectorMacro and itkGetVectorMacro

they make the generated methods unusable in the target languages, and are not used that much in ITK

[glehmann@gbook build]$ grep -r etVectorMacro ~/src/Insight/Code/*/*.h | wc -l
    34

They are used in two quite common filters - ChangeInformationImageFilter and PadImageFilter - and this makes this filter at least partly unusable in the target languages.

Tcon 808310

Agenda 081310

• gccxml maintenance

who does it? migration to CLang?

• migrating to WrapITK 0.3
• recode igenerator.py in C++
• languages support
  • keep python 2
  • keep java
  • add C#
  • add Python 3?
  • remove Tcl?
• redefine the WrapITK libraries (grouping of classes)

It seems to be tightly linked to ITK_Release_4/Modularization.

• Default wrapped types and abbreviated naming scheme

Some choices are already made for SimpleITK

• Wrapping coverage

100% filters coverage?

• Binary distribution
• ITK Image to/from target language array conversion
• Automatic Inline documentation
• Target language inheritance (SWIG directors)
• Automatic type selection in Python
• Improve 64bits support in ITK — surely done elsewhere already
• GDCM wrapping integration?

Minutes 081310

Attendees

• Luis Ibañez
• Gabe Hart
• Gaëtan Lehmann
• Brad King

Topics

• gccxml maintenance

Brad working on it. Getting harder with newer compiler. Will probably possible for the next couple of years.

CLang must be explored as a replacement.

• migrating to WrapITK 0.3
• recode igenerator.py in C++

reuse cable code. already read gccxml output.

• languages support
  • keep python 2
  • keep java
  • add C#
  • add Python 3? maybe
  • remove Tcl? sure

• redefine the WrapITK libraries (grouping of classes)

use the same module organization than in ITK

• Default wrapped types and abbreviated naming scheme
• Wrapping coverage
• Binary distribution

distribute binary for now next move to ryppl

• ITK Image to/from target language array conversion
• Automatic Inline documentation
• Target language inheritance (SWIG directors)
• Automatic type selection in Python
• Improve 64bits support in ITK — surely done elsewhere already

remove 64 bit pixel type

rework filter using unsigned long type

• GDCM wrapping integration?

add interfaces in ITK classes and wrap those classes

Pending Tasks

• here