ITK/Release 4/Wrapping: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4
Jump to navigationJump to search
 
(5 intermediate revisions by one other user not shown)
Line 5: Line 5:
SIMPLIFY ITK by allowing easy access of the toolkit from other languages, especially scripting languages, hiding some difficulties (templates, compilation ...) along the way.
SIMPLIFY ITK by allowing easy access of the toolkit from other languages, especially scripting languages, hiding some difficulties (templates, compilation ...) along the way.


== Metrics ==
== Metrics and goals ==
* Avoid unnecessary dependencies (see Modular ITK)
* Avoid unnecessary dependencies (see Modular ITK)
* FASTER
* FASTER
Line 13: Line 13:
* Wrap 80%+ of the toolkit
* Wrap 80%+ of the toolkit
* Have ITK behaves in the different languages as close to the native code as possible
* Have ITK behaves in the different languages as close to the native code as possible
** ITK Image to/from target language array conversion
** Target language inheritance (SWIG directors)
** Automatic type selection in Python
* Binary distribution
* Automatic Inline documentation


== Languages ==
== Languages ==
Line 42: Line 47:
= Discussions and TConfs =
= Discussions and TConfs =


== Tcon July 19 2010 ==
* 19-07-2010 - NoAgenda                                      - [[/19072010_Minutes|Minutes]]
 
* 13-08-2010 - [[/13082010_Agenda|Agenda]] - [[/13082010_Minutes|Minutes]]  
* 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


== Pending Tasks ==
== Pending Tasks ==
* [http://www.vtk.org/Wiki/ITK_Release_4/Wrapping/Tasks here]
* [http://www.vtk.org/Wiki/ITK_Release_4/Wrapping/Tasks here]

Latest revision as of 16:00, 9 December 2011

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 and goals

  • 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
    • ITK Image to/from target language array conversion
    • Target language inheritance (SWIG directors)
    • Automatic type selection in Python
  • Binary distribution
  • Automatic Inline documentation

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

Parallel Build Status

Discussions and TConfs

Pending Tasks

Retrieved from "https://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Wrapping&oldid=44305"