[Insight-users] ITK in Python

Zachary Pincus zpincus at stanford.edu
Mon Sep 25 19:34:57 EDT 2006 

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

More information about the Insight-users mailing list