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

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 <[email protected]
> 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
>

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