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

[Matt McCormick]

Hi Nathan,

WrapITK has been integrated into ITKv4, and the infrastructure and
documentation on wrapping your own ITK code has greatly improved. See:

  https://blog.kitware.com/python-packages-for-itk-modules/
  https://itkpythonpackage.readthedocs.io/

For wrapping libraries that interact heavily with ITK types, this is preferred.


If this is not possible, then coercing both the library data
structures and ITK data structures into common Python data types is
another option. For example, itk.Index can be converted to a Python
list or tuple. itk.Image pixel buffers can be converted to NumPy
arrays. If this functionality is added to the library code, it serves
as a way to transmit data.

Hope this helps,
Matt

On Fri, Oct 20, 2017 at 11:01 AM, Nathan Lay <enslay at gmail.com> wrote:
> 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
>
> The ITK community is transitioning from this mailing list to
> discourse.itk.org. Please join us there!
> ________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-users
>