[Insight-users] Custom ITK class wrapping
Gaetan Lehmann
gaetan.lehmann at jouy.inra.fr
Mon Dec 5 06:50:11 EST 2005
On Sun, 04 Dec 2005 22:33:55 +0100, Zachary Pincus <zpincus at stanford.edu>
wrote:
> Gatean -
>
> Thanks for posting this information. Your approach looks very
> intriguing. If I might ask a couple of questions:
It's not intriguing :-)
Some use of ITK in python clearly show some heavy limitations:
+ only a few classes are available
+ the types available may not allow to build a full pipeline: you may be
stopped at by types inconsistency
+ using completion in python interpreter (or better, in ipython) is a pita
because of the high number of name in the InsightToolkit module
+ changing the type of pixel in a program force you to edit all the class
names
+ there is no way to write functions which automatically find the type to
use
+ someone may want to work mainly with one type (say unsigned char) and
another one with another (unsigned short for example), but there is no way
to select types to wrap
+ it's hard to add new classes
+ it very hard to wrap custom classes
+ the SetInput( GetOutput() ) call can be very painful while prototyping
in interpreter
+ write a line per attribute setting can also be very painful while
prototyping in interpreter
+ there is no progress display in the interpreter
+ there is no easy way to see the result in the interpreter
+ using ITK can make python segfault
+ some types, like FixedArray, Size, Index, etc , don't have a python
interface and are hard to use
+ there is no way to get some values - std::vector<?> are not wrapped for
example
+ enumerated types can't be used
+ ...
The proposed sytem solve some of these problems (but not all)
>
> First, could you provide a little information about how your wrappers
> work and how they differ from the ITK model? I can vaguely follow what's
> going on in the ITK code, but I'm not at all sure how things work with
> the codebase you've pointed me to.
The system is the same, but cxx files are not written by the user but
generated by a cmake script. This approach allow several new features:
+ generate code which will be used for dynamic type selection
+ select at build time what will be wrapped
+ consistent naming of classes
+ easier creation of wrappers
+ wrap custom classes
typically, simple filter wrappers looks like this one:
http://voxel.jouy.inra.fr/darcs/itk-mima2/Insight/Wrapping/CSwig/BasicFiltersB/wrap_itkMedianImageFilter.cmake
WRAP_CLASS("MedianImageFilter" POINTER)
WRAP_INT(2)
WRAP_SIGN_INT(2)
WRAP_REAL(2)
END_WRAP_CLASS()
which mean: wrap MedianImageFilter with 2 template parameters for image
with type of pixel which can be integer (unsigned short, unsigned char,
unsigned long), singed integer (signed short, signed char, signed long) or
real (float, double). The types which are really used are selected with
cmake.
The 2 template parameters are the same, but it's possible to build more
complex combinaisons if needed. Here is an example
http://voxel.jouy.inra.fr/darcs/itk-mima2/Insight/Wrapping/CSwig/BasicFiltersC/wrap_itkMorphologicalWatershedFromMarkersImageFilter.cmake
To wrap a new class, you just have to add a wrap_*.cmake file, and it will
automatically be included. You can also remove or rename a file to not
wrap a class, and have nothing more to edit.
>
> Second, is this work slated for inclusion in ITK at any point? All other
> things being equal, I tend to prefer using toolchains that I know will
> continue to be supported. (But of course, not all other things are
> equal...) Failing that, are these wrappers known to work on OS X?
I hope it will be integrated in ITK, but I can't say if it will be done.
There is a page about that on the wiki
http://www.itk.org/Wiki/Proposals:Refactoring_Wrapping
It have been tested on windows and linux, but not on mac os x
>
> Third, could you explain what "the dynamic type selection with the new
> itk python module" does? It seems like it could be useful.
for sure it can be useful :-)
There is an example at
http://www.itk.org/Wiki/Proposals:Refactoring_Wrapping . I have a little
changed the syntax (itk is a module so you have to use
itk.ImageFileWriter[ itkImg ] instead of itkImageFileWriter[ itkImg ], but
the rest is the same)
>
> Finally, do you know if this wrapping method works with the "numeric
> python" interface that I've heard rumors of -- allowing easy conversion
> of ITK images into Numeric Python arrays? I don't know a whole lot about
> this, but it is something that I think I'll need to get working.
It doesn't work for now, but it also doesn't work official ITK wrappers.
IMHO, it should be done as an external extension; like the itk-vtk
connection. It should not be a problem to make it work; someone just need
to find the time to do it.
>
> Thanks for your time -- and for the work on this alternate wrapping
> strategy.
>
> Zach
>
>
>
> On Dec 4, 2005, at 3:31 AM, Gaetan Lehmann wrote:
>
>>
>> Hi,
>>
>> Benoit Regrain and I have done some work on itk wrappers which should
>> make
>> what you want to do easier.
>> The work is available at
>> http://voxel.jouy.inra.fr/darcs/itk-mima2/Insight/Wrapping/CSwig/ for
>> the itk
>> wrapping, and at http://voxel.jouy.inra.fr/darcs/itkvtk/ for an example
>> of
>> external classes wrapping (the itk-vtk image filters).
>>
>> I think it can make things easier for several reasons:
>> + there is a lots more classes wrapped
>> + you can remove some classes (to decrease the bin size) just by
>> removing the
>> corresponding wrap_?.cmake files.
>> + you can select types you want to wrap, and so decrease the size of the
>> binary
>> + you can wrap some custom classes
>>
>> you may also find some very nice features like the dynamic type
>> selection with
>> the new itk python module
>>
>> I hope you will find it useful, and will contribute some new wrappers
>> :-)
>> All feedbacks are also welcome
>>
>> Regards,
>>
>> Gaetan
>>
>> On Sunday 04 December 2005 11:41, Zachary Pincus wrote:
>>> Hi folks -
>>>
>>> Sorry to send this to both the users and developers list, but I'm
>>> hoping to get some advice on relatively deep ITK magic, so I'm not
>>> sure where best to ask.
>>>
>>> My basic question is if anyone can give me any advice, tips, or
>>> warnings about creating a custom python wrapping library for ITK.
>>>
>>> The basics of my problem are twofold:
>>> (1) I wish to wrap some custom C++ classes I've written
>>> (2) I've never managed to get the default python wrapper library to
>>> work on OS X, due to some sort of loader issues with huge libraries.
>>> (Perhaps this is fixed in the newest ITK releases, or under OS X
>>> 10.4? I haven't tried in a while.)
>>>
>>> At any rate, I'd like to wrap a narrow subset of ITK and my custom
>>> code into a (relatively) small python wrapper library. I know this
>>> isn't a "supported" procedure, and a lot of very confusing stuff is
>>> going on to get CMake, cswig, gccxml, and the rest to all cooperate
>>> and make things work. If anyone could give me a rundown of the basic
>>> issues involved here, and where I should start, I would be pretty
>>> grateful.
>>>
>>> I've read through some of the contents of $ITK_ROOT/Wrapping, and it
>>> by and large makes sense -- but any details or hard-won insight into
>>> how to make this work in my own project would be really appreciated.
>>>
>>> Thanks,
>>>
>>> Zach
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>
--
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
http://voxel.jouy.inra.fr
More information about the Insight-users
mailing list