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

[Matt McCormick]

Hi Nathan,

> 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.

Yes! Are you interested in creating a Python package for that module?
It looks like it is pretty good shape:

  https://github.com/InsightSoftwareConsortium/ITKIOOpenSlide

I could guide you through the process.


> 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"

These are not intended to be built against as far as I am aware, either.


> 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.

It is important to keep in mind that itk::Point< ... > and itk::Image<
... > cannot be wrapped directly because they are templates -- the
templates need an instantiation to result in an actual type that can
be wrapped.

Hopefully you will find that generating external modules is now low overhead.


Best regards,
Matt

>
> 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
>
>