<div dir="ltr"><div><div><div><div><div>Hello Matt,<br></div>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.<br><br></div>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<br><a href="https://github.com/InsightSoftwareConsortium/SimpleITK/tree/master/Wrapping/Python">https://github.com/InsightSoftwareConsortium/SimpleITK/tree/master/Wrapping/Python</a></div><div><br></div><div>Any hopes for something like numpy.i here?</div><div>%import(module="sitk") "SimpleITK.i"</div><div>or</div><div>%include "SimpleITK.i"<br></div><div><br></div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Best regards,</div><div>Nathan Lay<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 23, 2017 at 11:50 AM, Matt McCormick <span dir="ltr"><<a href="mailto:matt.mccormick@kitware.com" target="_blank">matt.mccormick@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Nathan,<br>
<span class=""><br>
> It's been a while!<br>
<br>
</span>Welcome back :-)<br>
<span class=""><br>
<br>
> Thanks for the prompt response. WrapITK is a pretty neat<br>
> feature and I'm glad to see recent work to better document it. Currently I<br>
> use the C++ documentation to get an idea how to use the Python version of<br>
> the functionality. I like your suggested workarounds and I'll look into<br>
> that.<br>
><br>
> The Wrapping folder generated by WrapITK seems to have a lot of<br>
> module/interface information about the WrapITK. Wouldn't it be possible to<br>
> have something like numpy.i for ITK? Then you could do something as<br>
> prescribed by Swig's documentation:<br>
><br>
> %import(module="itk") "itk.i"<br>
><br>
> And this supposedly helps Swig with tricky multi-module setups. I realize<br>
> itk.i doesn't actually do anything currently except ignore some allocators<br>
> in LightObject (I think). Some of these .i/.h files would have to be<br>
> properly installed in share/include folders. Well, it doesn't resolve the<br>
> issue where WrapITK generates brand new classes for some of the ITK data<br>
> types.<br>
<br>
</span>I don't think the current infrastructure is intended to be used in<br>
this way, but improvements here would be welcome.<br>
<span class=""><br>
<br>
> Out of curiosity, what is the rationale for generating brand new classes<br>
> for, say, itk::Image or itk::Image::Pointer anyway?<br>
<br>
</span>Part of the consideration here is that ITK uses itk::LightObject,<br>
itk::SmartPointer for memory management.<br>
<br>
<br>
Thanks,<br>
Matt<br>
</blockquote></div><br></div>