<div dir="ltr"><div><div>Hello Matt,<br></div>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. <br></div><div><br></div><div>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:</div><div><br></div><div>%import(module="itk") "itk.i"</div><div><br></div><div>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. <br></div><div><br></div><div>Out of curiosity, what is the rationale for generating brand new classes for, say, itk::Image or itk::Image::Pointer anyway?<br></div><div><br></div><div>Best regards,</div>Nathan Lay</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 20, 2017 at 5:12 PM, 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">Hi Nathan,<br>
<br>
WrapITK has been integrated into ITKv4, and the infrastructure and<br>
documentation on wrapping your own ITK code has greatly improved. See:<br>
<br>
  <a href="https://blog.kitware.com/python-packages-for-itk-modules/" rel="noreferrer" target="_blank">https://blog.kitware.com/<wbr>python-packages-for-itk-<wbr>modules/</a><br>
  <a href="https://itkpythonpackage.readthedocs.io/" rel="noreferrer" target="_blank">https://itkpythonpackage.<wbr>readthedocs.io/</a><br>
<br>
For wrapping libraries that interact heavily with ITK types, this is preferred.<br>
<br>
<br>
If this is not possible, then coercing both the library data<br>
structures and ITK data structures into common Python data types is<br>
another option. For example, itk.Index can be converted to a Python<br>
list or tuple. itk.Image pixel buffers can be converted to NumPy<br>
arrays. If this functionality is added to the library code, it serves<br>
as a way to transmit data.<br>
<br>
Hope this helps,<br>
Matt<br>
<div><div class="h5"><br>
On Fri, Oct 20, 2017 at 11:01 AM, Nathan Lay <<a href="mailto:enslay@gmail.com">enslay@gmail.com</a>> wrote:<br>
> Hello Insight-Users,<br>
> I've studied the WrapITK CMake modules and an old wiki describing how to<br>
> wrap external modules, but I've yet to see anything obvious about wrapping a<br>
> standalone library that uses ITK. Since ITK is a toolkit used to build other<br>
> applications and libraries, wrapping your library with swig and using it in<br>
> concert with WrapITK seems pretty natural to me.<br>
><br>
> Swig can wrap the library that uses ITK. But the Python types for the ITK<br>
> data structures do not match those from the WrapITK Python module.<br>
><br>
> I don't have any actual examples handy, but here's roughly what will<br>
> generally happen:<br>
> x = MyModule.vectorI2()<br>
> x.resize(1)<br>
> type(x[0])<br>
> itk::Index< 2 ><br>
><br>
> y = itk.Index[2]()<br>
> type(y)<br>
> itkIndexPython.itkIndex2<br>
><br>
> x.push_back(y)<br>
> Type mismatch error happens (itk::Index< 2 > const & expected)<br>
><br>
> I also see that WrapITK generates a lot of new types/typedefs for every<br>
> class in its Wrapping build folder. For example, I'm sure I'll never be able<br>
> to use itk::Image<unsigned char, 2>::Pointer with itk.Image[itk.UC, 2]. The<br>
> latter is comprised of 2 brand new standalone classes defined in<br>
> itkImageSwigInterface.h... itkImageUC2 and itkImageUC2_Pointer. Swig's<br>
> typedef reduction will never be able to match itk::Image<T,D>::Pointer with<br>
> those wrapped types even if I import the respective itkImage<br>
> headers/interfaces. Heck, it can't even match the typedefs from<br>
> itkIndexSwigInterface.h as it is. If I import the itkIndex.i or<br>
> itkIndexSwigInterface.h and instantiate<br>
><br>
> %template(vectorI2) std::vector<itkIndex2>;<br>
><br>
> mysteriously it still reduces to itk::Index< 2 >.<br>
><br>
> Is there anyway I can convince swig that the data types provided by the itk<br>
> module are the same data types I'm using in MyModule without having to turn<br>
> it into an ITK module outright?<br>
><br>
> Best regards,<br>
> Nathan Lay<br>
><br>
</div></div>> The ITK community is transitioning from this mailing list to<br>
> <a href="http://discourse.itk.org" rel="noreferrer" target="_blank">discourse.itk.org</a>. Please join us there!<br>
> ______________________________<wbr>__<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
><br>
> Kitware offers ITK Training Courses, for more information visit:<br>
> <a href="http://www.kitware.com/products/protraining.php" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>products/protraining.php</a><br>
><br>
> Please keep messages on-topic and check the ITK FAQ at:<br>
> <a href="http://www.itk.org/Wiki/ITK_FAQ" rel="noreferrer" target="_blank">http://www.itk.org/Wiki/ITK_<wbr>FAQ</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/insight-users" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/insight-users</a><br>
><br>
</blockquote></div><br></div>