[Insight-users] Custom ITK class wrapping

[Zachary Pincus]

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

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?

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.

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

Zach