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

[Nathan Lay]

Hello Matt,
Thanks for the prompt response. I'm always using ITK even if I'm not vocal
about! You may not remember, but you and I corresponded a bit about
ITKIOOpenSlide work.

With regard to providing necessary hints to Swig about foreign modules,
would this be possible through SimpleITK? I looked at the Python folder for
SimpleITK and I see a few predefined interface files
https://github.com/InsightSoftwareConsortium/SimpleITK/tree/master/Wrapping/Python

Any hopes for something like numpy.i here?
%import(module="sitk") "SimpleITK.i"
or
%include "SimpleITK.i"

You guys provide this beautiful CMake interface for external projects to
use ITK as a C++ toolkit without the need to cram it into an ITK module. It
would be nice if Swig had this capability too. But I guess the trickery ITK
plays is hard to communicate between multiple modules on a number of
different languages. I spent more time reading some of the interface files
and I see some tricky %typemaps that deal with reference counting.

I have a number of C++ snippets that use, for example, an itk::Point here
or an itk::Image there and I can't wrap them with swig into Python modules.
I probably have to change namespaces and coding conventions to make them
into external ITK modules for wrapping purposes.

Best regards,
Nathan Lay

On Mon, Oct 23, 2017 at 11:50 AM, Matt McCormick <matt.mccormick at kitware.com
> wrote:

> Hello Nathan,
>
> > It's been a while!
>
> Welcome back :-)
>
>
> > 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.
>
> I don't think the current infrastructure is intended to be used in
> this way, but improvements here would be welcome.
>
>
> > Out of curiosity, what is the rationale for generating brand new classes
> > for, say, itk::Image or itk::Image::Pointer anyway?
>
> Part of the consideration here is that ITK uses itk::LightObject,
> itk::SmartPointer for memory management.
>
>
> Thanks,
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20171023/26ef7734/attachment.html>