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

[Nathan Lay]

Hello Matt,
It's been a while! Thanks for the prompt response. WrapITK is a pretty neat
feature and I'm glad to see recent work to better document it. Currently I
use the C++ documentation to get an idea how to use the Python version of
the functionality. I like your suggested workarounds and I'll look into
that.

The Wrapping folder generated by WrapITK seems to have a lot of
module/interface information about the WrapITK. Wouldn't it be possible to
have something like numpy.i for ITK? Then you could do something as
prescribed by Swig's documentation:

%import(module="itk") "itk.i"

And this supposedly helps Swig with tricky multi-module setups. I realize
itk.i doesn't actually do anything currently except ignore some allocators
in LightObject (I think). Some of these .i/.h files would have to be
properly installed in share/include folders. Well, it doesn't resolve the
issue where WrapITK generates brand new classes for some of the ITK data
types.

Out of curiosity, what is the rationale for generating brand new classes
for, say, itk::Image or itk::Image::Pointer anyway?

Best regards,
Nathan Lay

On Fri, Oct 20, 2017 at 5:12 PM, Matt McCormick <matt.mccormick at kitware.com>
wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20171023/239da147/attachment.html>
-------------- next part --------------
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