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 ?
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