[ITK-users] Using swig on external standalone libraries that use ITK

[Nathan Lay]

Hello Insight-Users,
I've studied the WrapITK CMake modules and an old wiki describing how to
wrap external modules, but I've yet to see anything obvious about wrapping
a standalone library that uses ITK. Since ITK is a toolkit used to build
other applications and libraries, wrapping your library with swig and using
it in concert with WrapITK seems pretty natural to me.

Swig can wrap the library that uses ITK. But the Python types for the ITK
data structures do not match those from the WrapITK Python module.

I don't have any actual examples handy, but here's roughly what will
generally happen:
x = MyModule.vectorI2()
x.resize(1)
type(x[0])
itk::Index< 2 >

y = itk.Index[2]()
type(y)
itkIndexPython.itkIndex2

x.push_back(y)
Type mismatch error happens (itk::Index< 2 > const & expected)

I also see that WrapITK generates a lot of new types/typedefs for every
class in its Wrapping build folder. For example, I'm sure I'll never be
able to use itk::Image<unsigned char, 2>::Pointer with itk.Image[itk.UC,
2]. The latter is comprised of 2 brand new standalone classes defined in
itkImageSwigInterface.h... itkImageUC2 and itkImageUC2_Pointer. Swig's
typedef reduction will never be able to match itk::Image<T,D>::Pointer with
those wrapped types even if I import the respective itkImage
headers/interfaces. Heck, it can't even match the typedefs from
itkIndexSwigInterface.h as it is. If I import the itkIndex.i or
itkIndexSwigInterface.h and instantiate

%template(vectorI2) std::vector<itkIndex2>;

mysteriously it still reduces to itk::Index< 2 >.

Is there anyway I can convince swig that the data types provided by the itk
module are the same data types I'm using in MyModule without having to turn
it into an ITK module outright?

Best regards,
Nathan Lay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20171020/c961d7e3/attachment.html>