ITK/Release 4/Wrapping: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4
Jump to navigationJump to search
No edit summary
No edit summary
Line 55: Line 55:


They are used in two quite common filters - ChangeInformationImageFilter and PadImageFilter - and this makes this filter at least partly unusable in the target languages.
They are used in two quite common filters - ChangeInformationImageFilter and PadImageFilter - and this makes this filter at least partly unusable in the target languages.
= Agenda 081310 =
* gccxml maintenance
* Migrating to WrapITK 0.3
* recode igenerator.py in C++
* support for C#
* support for Python 3?
* support for Tcl?
* Redefine the WrapITK libraries (grouping of classes) — seems to be tightly linked to [[ITK_Release_4/Modularization]].
* Default wrapped types and abbreviated naming scheme — some choices already made for SimpleITK, some stuff done as well in the microscopy group
* Wrapping 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?

Revision as of 12:20, 11 August 2010

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.


Agenda 081310

  • gccxml maintenance
  • Migrating to WrapITK 0.3
  • recode igenerator.py in C++
  • support for C#
  • support for Python 3?
  • support for Tcl?
  • Redefine the WrapITK libraries (grouping of classes) — seems to be tightly linked to ITK_Release_4/Modularization.
  • Default wrapped types and abbreviated naming scheme — some choices already made for SimpleITK, some stuff done as well in the microscopy group
  • Wrapping 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?