[Insight-users] ITK in Python

Zachary Pincus zpincus at stanford.edu
Sat Sep 30 01:45:55 EDT 2006 

Oh dear, this reminds me that I really need to make a README file for  
WrapITK and Mac OS X. I've been terribly behind with all of this due  
to the minor problem of having to write my thesis right now!

The situation is that there is a bug (sort of) in Python 2.4 and  
below that makes it not interact with the dynamic loader properly on  
OS X, which only manifests when you start passing objects between  
different libraries, and then casting them to different types. And  
even then, only when a recent version of GCC is in use. Apparently,  
WrapITK is the first thing that pressed all of these buttons at the  
same time.

The short story is that for WrapITK to work correctly on macs, you'll  
need to get Python 2.5 (or custom-build a patched 2.4 with patches  
that I can point you to). Also, I think (Gaëtan, can you chime in  
here?) that you'll have to build WrapITK with the -fpermissive  
CPPFLAG to deal with some errors that would otherwise arise thanks to  
some low-level changes in Python2.5 that cableswig isn't caught up on.

I am tremendously sorry that WrapITK is such a pain on the Mac --  
after all, it's what I develop on... please let me know if I can help  
in any other way.

Zach




On Sep 29, 2006, at 3:51 PM, Erik Anderson wrote:

> Zach,     I got everything working finally (on Suse 10.1) but a  
> colleague of mine sent me the following error when she tried to run  
> the exact same thing on a Mac:
>
> RuntimeError: /Users/emanuele/code/Insight/Code/Common/ 
> itkImageBase.txx:252:
> itk::ERROR: Image(0x271717b0): itk::ImageBase::CopyInformation()  
> cannot cast PKN3itk10DataObjectE to PKN3itk9ImageBaseILj2EEE
>
> I did a little digging and saw the following post by you a couple  
> years ago:
>
> http://public.kitware.com/pipermail/insight-users/2005-July/ 
> 014144.html
>
> However, I can't find a solution to this.  Do you remember how this  
> was resolved?
>
> Thanks a lot,
> Erik
>
> Zachary Pincus wrote:
>> Strange that it took so long to get everything working properly  
>> together! I'm glad it's working now.
>>
>> Unfortunately, as to getting the input and output types there's no  
>> simple way that I know of. (Perhaps others have some suggestions?)  
>> I'm not sure how the vtk wrappers are set up and the docstrings  
>> created -- maybe we could look into that for WrapITK.
>>
>> Options you might pursue could include:
>> (1) Doing something with doxygen-generated information. Doxygen  
>> can, I think, spit out east-to-parse descriptions of public class  
>> methods. There are hooks in WrapITK to link up doxygen files with  
>> the corresponding WrapITK classes.
>>
>> (2) Parsing through the gcc-xml output that is an intermediate  
>> step in the wrapping. There are python libraries for reading gcc- 
>> xml output, and this should contain all of the information about  
>> the signatures of all of the wrapped methods. This is probably the  
>> most direct method, especially since the xml files are already  
>> there in your build tree.
>>
>> Zach
>>
>>
>> On Sep 25, 2006, at 4:14 PM, Erik Anderson wrote:
>>
>>> Zach,
>>>    I have gotten to the point where itk is working in Python  
>>> (after 2 more rebuilds and a fresh checkout from CVS) but I am  
>>> running into another problem that may or may not be able to be  
>>> solved.
>>>
>>>    As I mentioned earlier, I'm trying to get at a full  
>>> description of a class.  Currently, I'm able to extract a proper  
>>> class hierarchy, but in order to finish everything, I need to get  
>>> a prototype for the class' methods.  Really, I just need a way to  
>>> get the input and output types for a given class in ITK.  Is this  
>>> possible using any sort of wrapping mechanism?  I know in VTK  
>>> this can be done via vtk.SomeClass.SomeMethod.__doc__
>>>
>>> Thanks again,
>>> Erik
>>>
>>> Zachary Pincus wrote:
>>>> Oh no, I think we're a step backwards.
>>>>
>>>> It looks like now WrapITK can't find any of the configuration  
>>>> information, and happily loads nothing at all into the itk  
>>>> module when imported.
>>>>
>>>> Please send the contents of
>>>> /usr/local/itk/Wrapping/WrapITK/Python/itkConfig.py
>>>> so that we can have a look at it and see where the problem is.
>>>>
>>>> As to your end goal, I think that the itk loading machinery  
>>>> (which I mentioned earlier) already does most of what you need.  
>>>> You'll want to look over itk.py, itkBase.py and itkConfig.py,  
>>>> but basically what happens is that itkBase.py loads all of the  
>>>> configuration files in
>>>> /usr/local/itk/Wrapping/WrapITK/Python/Configuration
>>>> (and potentially elsewhere). These files describe all of the  
>>>> classes in each module, along with the module dependencies, so  
>>>> that we can load them in a sane manner.
>>>>
>>>> This information is stored in itkBase.module_data, which is a  
>>>> dict. The keys are module names, and the values are dicts with  
>>>> two keys: 'depends' (a list of modules that need to be loaded  
>>>> before that module), and 'templates' which is a tuple.
>>>> Each element of 'templates' is itself a tuple containing either  
>>>> three or four elements.
>>>>
>>>> If four, then that element describes a particular template  
>>>> instantiation of a class:
>>>>  (pyClassName, cppClassName, swigClassName, templateParams)
>>>> where 'pyClassName' is the python-friendly name of the class (no  
>>>> enclosing namespace or template params), 'cppClassName' is the  
>>>> fully-qualified name (again less the template params),  
>>>> swigClassName is the name of the exact template instantiation  
>>>> that SWIG generated, and templateParams is the c++ template  
>>>> parameters. This information lets us store all template  
>>>> instances together in a python dict so you can say:
>>>> Image[US, 2]
>>>> as a shortcut for
>>>> itkImageUS2
>>>> which is the SWIG name for
>>>> 'itk::Image<unsigned char, 2>'
>>>>
>>>> If three, then that element describes a non-template instantiation:
>>>> (pyClassName, cppClassName, swigClassName)
>>>> as above.
>>>>
>>>> So you could grab the module_data dict from itkBase and churn  
>>>> through that to get all the information you need. But first  
>>>> you'll need to get the loading working right! So, let's see  
>>>> what's in itkConfig.py and whether that reflects what's going on  
>>>> in your filesystem.
>>>>
>>>> Zach
>>>>
>>>>
>>>>
>>>> On Sep 25, 2006, at 1:05 PM, Erik Anderson wrote:
>>>>
>>>>> Zach,
>>>>>    Thanks for the quick reply.  I rebuilt everything and now,  
>>>>> when I perform the following commands:
>>>>> import itk
>>>>> dir(itk)
>>>>>
>>>>> I get something totally different than just a list of the  
>>>>> classes I expect.  Instead, I now get the following:
>>>>>
>>>>> >>> dir(itk)
>>>>> ['B', 'D', 'F', 'LD', 'PyCommand', 'PyImageFilter', 'SC', 'SI',  
>>>>> 'SL', 'SS', 'SmartPointer', 'UC', 'UI', 'UL', 'US',  
>>>>> '_LazyITKModule__lazy_attributes', '__doc__', '__name__',  
>>>>> 'auto_progress', 'class_', 'clrLine', 'ctype', 'echo',  
>>>>> 'force_load', 'image', 'index', 'physical_size', 'pipeline',  
>>>>> 'range', 'show', 'show2D', 'simple_import_callback',  
>>>>> 'simple_progress_callback', 'size', 'spacing', 'strel',  
>>>>> 'template', 'terminal_import_callback',  
>>>>> 'terminal_progress_callback', 'write']
>>>>>
>>>>> Is this what I should be expecting?  I tried to instantiate a  
>>>>> filter (itk.AcosImageFilter) and get the LazyITKModule object  
>>>>> has no attribute 'AcosImageFilter'  I guess my real question  
>>>>> is, did I just take a step forward or a step backwards?  The  
>>>>> end goal here is to be able to capture a list or dictionary of  
>>>>> itk modules and the callable functions on those modules.
>>>>>
>>>>> Thanks a lot,
>>>>> Erik
>>>>>
>>>>> Zachary Pincus wrote:
>>>>>> So the general deal here is that the WrapITK Python libs have  
>>>>>> tricky dependencies, and are slow to load fully. So 'import  
>>>>>> itk' just gives you a bunch of proxy objects, that when you  
>>>>>> try to use them, call some code (which can be a bit brittle,  
>>>>>> as you've seen), to load the actual ITK libraries that are  
>>>>>> needed.
>>>>>>
>>>>>> It would appear that somehow, this loading is getting confused  
>>>>>> about where to find the files it needs to load. This  
>>>>>> information should be in (on your system)
>>>>>> /usr/local/itk/Wrapping/WrapITK/Python/itkConfig.py
>>>>>>  Could you send the contents of this file?
>>>>>>
>>>>>> In general, the python files you need would be in:
>>>>>> /usr/local/itk/Wrapping/WrapITK/lib
>>>>>> (I think...). Do you have a file VXLNumericsPython.py in that  
>>>>>> directory?
>>>>>>
>>>>>> Zach
>>>>>>
>>>>>>
>>>>>> On Sep 25, 2006, at 11:55 AM, Erik Anderson wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>    I have successfully built ITK and WrapITK with (I think)  
>>>>>>> the proper CMake options set.  In a Python shell, I am able  
>>>>>>> to successfully import itk via
>>>>>>>
>>>>>>> import itk
>>>>>>>
>>>>>>> using dir on the module gives me a list of all the wrappings  
>>>>>>> I would expect, however, upon instantiation of a class I get  
>>>>>>> the following type of error:
>>>>>>>
>>>>>>> >>> f = itk.AcosImageFilter
>>>>>>> Traceback (most recent call last):
>>>>>>>  File "<stdin>", line 1, in ?
>>>>>>>  File "/scratch/eranders/env/itk/Wrapping/WrapITK/Python/ 
>>>>>>> itkLazy.py", line 18, in __getattribute__
>>>>>>>    itkBase.LoadModule(module, namespace)
>>>>>>>  File "/scratch/eranders/env/itk/Wrapping/WrapITK/Python/ 
>>>>>>> itkBase.py", line 77, in LoadModule
>>>>>>>    LoadModule(dep, namespace)
>>>>>>>  File "/scratch/eranders/env/itk/Wrapping/WrapITK/Python/ 
>>>>>>> itkBase.py", line 77, in LoadModule
>>>>>>>    LoadModule(dep, namespace)
>>>>>>>  File "/scratch/eranders/env/itk/Wrapping/WrapITK/Python/ 
>>>>>>> itkBase.py", line 85, in LoadModule
>>>>>>>    if not swigModuleName in sys.modules: module = loader.load 
>>>>>>> (swigModuleName)
>>>>>>>  File "/scratch/eranders/env/itk/Wrapping/WrapITK/Python/ 
>>>>>>> itkBase.py", line 191, in load
>>>>>>>    fp, pathname, description = imp.find_module(name)
>>>>>>> ImportError: No module named VXLNumericsPython
>>>>>>>
>>>>>>> My environment is as follows:
>>>>>>>
>>>>>>> Python 2.4 on Suse 10.1
>>>>>>> itk 2.8 built from CVS with WrapITK
>>>>>>>
>>>>>>> Environment variables set:
>>>>>>> LD_LIBRARY_PATH = /usr/local/itk/bin
>>>>>>> PYTHONPATH=/usr/local/itk/Wrapping/WrapITK/Python
>>>>>>>
>>>>>>> Any help would be great.
>>>>>>>
>>>>>>> Thansk,
>>>>>>> Erik Anderson
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Insight-users mailing list
>>>>>>> Insight-users at itk.org
>>>>>>> http://www.itk.org/mailman/listinfo/insight-users
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Insight-users mailing list
>>>>> Insight-users at itk.org
>>>>> http://www.itk.org/mailman/listinfo/insight-users
>>>>
>>>
>>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users

More information about the Insight-users mailing list