[Insight-users] Custom ITK class wrapping

[Gaetan Lehmann]

On Tue, 06 Dec 2005 07:37:36 +0100, Zachary Pincus <zpincus at stanford.edu>  
wrote:

> Gaetan,
>
> Thanks for the clarifications about your ITK wrappers. It seems that the  
> answer to some of my problems with ITK wrappers is to try to find a  
> method to build small, task-oriented python wrapper libraries for  
> subsets of ITK (and my custom C++ classes) that I need for a particular  
> task. This contrasts to the current approach of building a monolithic,  
> one-size-fits-all library covering most of ITK. I don't know if this is  
> a good general solution, but it's what I need, and it does seem that it  
> could be useful to have general tools to allow this.
>
> The need would then be for tools that facilitate integrating custom  
> classes, building wrapper libraries outside of the ITK source tree,  
> simply adding or removing class wrappers. It seems like your CMake- 
> driven menthod might be really useful for this.
>
> I also agree that the limitations you mention are a real issue for using  
> ITK python wrappers. Out of curiosity, which of the below are (a)  
> addressed currently in your wrapper method, (b) potentially addressed  
> within that method, or (c) would require something else entirely to deal  
> with? It would be good to know what's already there, and what might be  
> useful to add...
>
> (I've also got a few other questions below, if I might pester you  
> further.)
>
>> Some use of ITK in python clearly show some heavy limitations:
>> + only a few classes are available
some more work need to be done
>> + the types available may not allow to build a full pipeline: you may  
>> be stopped at by types inconsistency
almost done
>> + using completion in python interpreter (or better, in ipython) is a  
>> pita because of the high number of name in the InsightToolkit module+
done
>> + changing the type of pixel in a program force you to edit all the  
>> class names
done
>> + there is no way to write functions which automatically find the type  
>> to use
done
>> + 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
done
>> + it's hard to add new classes
done
>> + it very hard to wrap custom classes
it should be made easier, but it's already quite easy
>> + the SetInput( GetOutput() ) call can be very painful while  
>> prototyping in interpreter
done, but some person don't like it
>> + write a line per attribute setting can also be very painful while  
>> prototyping in interpreter
done
>> + there is no progress display in the interpreter
done
>> + there is no easy way to see the result in the interpreter
done
>> + using ITK can make python segfault
lots of work to do here, but it's not related to wrappers. Some methods  
will segfault in itk if the input of the filter is not set for example.  
That's not a real problem in c++ (or should I say it's a common problem in  
c++ ?), but in languages like python, we must get an exception and not a  
segfault.
>> + some types, like FixedArray, Size, Index, etc , don't have a python  
>> interface and are hard to use
I think I haven't been very clear. Those classes are wrapped and fully  
usable. However, they can't be access with the usual python interface.
I have added some method in those class to have that interface so we can  
do things like:

82> i = itk.Index[3]()

83> i[1]
83> 0

84> i[1] = 2

85> i[1]
85> 2

86> print i
<Index [0, 2, 0]>

87> list(i)
87> [0, 2, 0]

Some other things would be nice but can't be done for now with cableswig  
like using python list or tuples as parameter of an itk function instead  
of itk Index.

>> + there is no way to get some values - std::vector<?> are not wrapped  
>> for example
This problem should be fixed by updating swig included in cableswig
>> + enumerated types can't be used
It don't work actually, and I have no idea of what can be done
>> + ...
>>
>> The proposed sytem solve some of these problems (but not all)
>
> The last four issues you mention above seem like real problems. I am  
> especially interested in whether your system addresses these (either  
> currently, or with a little more work).
>
>
>>> 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)
>
> I'm not sure I totally follow how this is implemented, but the general  
> idea is being able to look up specific template instantiations from a  
> table, right?

Yes. We only have access to the template we have choose at build time

>
> How does your wrapping method make this easier or possible? I'm just  
> trying to understand what's going on under the hood that makes this work.

Benoit have done most of the work for this part.
Basically, the available template parameters are stored in a dict by the  
python code generated by cmake, and accessed with a python dict interface.

>
>>> 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.
>
> I've got a simple system now for my hand-written ITK wrappers, that just  
> involves getting an ITK buffer as a PyString and feeding it to Numeric  
> in pure python. Not super efficient, but that should be dead-simple to  
> write an an external module. And making it actually use the C-level  
> Numeric API should be really easy too. I'll work on that whenever I get  
> a chance to try setting up this wrapping system.
>

great :-)

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