ITK/Release 4/Wrapping

Wrapping

Requirements

• Avoid unnecessary dependencies
• Wrap +80% of the toolkit
• Have ITK look similar to the native wrapped language

Tools

• WrapITK
• Swig
• CableSwig
• MUMMY

Languages

What languages to wrap

• Python
• Lua ?
• Tcl ?

Parallel Build Status

• Parallel Build Status

Discussions

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 [[ITK_Release_4/SimpleITK | 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