[Insight-developers] [ITK + Python] Wrapping classes proposal

[Benoit Regrain]

----- Original Message ----- 
From: "Gaetan Lehmann" <gaetan.lehmann at jouy.inra.fr>
To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>; 
<insight-developers at itk.org>
Sent: Wednesday, June 15, 2005 12:48 PM
Subject: Re: [Insight-developers] [ITK + Python] Wrapping classes proposal


> On Tue, 14 Jun 2005 12:34:57 +0200, Benoit Regrain 
> <benoit.regrain at creatis.insa-lyon.fr> wrote:
>
>
>>> But if it's possible to add an attribute to the class which cleany 
>>> identify the type (as you say below), we don't have to worry about name 
>>> : we should just use the new attributes.
>>> If names are not changed, we keep full compatibility with older itk 
>>> versions...
>> Yes, you have right in theory. And I understand the will to keep this
>> compatibility. But I'm not sure that's easily possible.
>>
>> Consider the itk::Image < itk::Vector<float,2>, 2> with an attribute to
>> get the mangled add.
>> So, for the itk::Vector<float,2>, the attribute will have 'VF2'
>> So, when we will search the type of the image, we will search 'VF22'
>> But the wrapped image classes for the want type are 'VF2' or 'V2F2'
>> and never 'VF22'
>>
>> So, I see only one solution. Create the _ItkClassXxx while wrapping
>> and generate the link between a wanted 'VF22' and a real 'V2F2' or 'VF2'
>> But I don't know if it's possible with CableSwig or Swig.
>>
>> In other hand, is it really a problem to not keep the backward 
>> compatibility
>> in all cases ?
>> Actually, the known persons working with ITK (in the same society than 
>> me)
>> are afraid by the use of itk in python. But after a little sounding, it 
>> appears that
>> a change of the mangled names with a simplest use in the wrapped 
>> languages
>> will be more attractive.
>> It's why I prefer a change of the mangled name (if we don't have other
>> choice)
>
> ok
>
>>>>> But there is good and less good things in c++ style, and I find quite
>>>>> boring
>>>>> to have to set parameters on several lines, or to have to call
>>>>> a.SetInput(b.GetOutput()) for each filter, especially in interperter.
>>>>> So I have given the ability to set attribute value in New method :
>>>>>
>>>>>  reader = itk.ImageFileReader[imageType].New(FileName='image.png')
>>>>>
>>>>> and to make construction of the process pipeline easier, if a var is 
>>>>> used
>>>>> as
>>>>> parameter in New method, it is used as source of image :
>>>>>
>>>>>  reader2 = itk.ImageFileReader[imageType].New(FileName='image2.png')
>>>>>  sub = itk.SubtractImageFilter[imageType, imageType,
>>>>> imageType].New(reader,
>>>>> reader2)
>>>>>  writer = itk.ImageFileWriter[imageType].New(sub, FileName='out.png')
>>>>>  writer.Update()
>>>>>
>>>>> All of this make code short, readable and flexible.
>>>> This can be a good addict. But some processes in ITK don't have the 
>>>> SetInput
>>>> method (reader processes for example). How does the function
>>>> react in this case ? Does your solution work in all cases ?
>>>
>>> I use the SetInput(int, image) method, and if it fail (for 
>>> itkImageToVTKImageFilter for example), I try with SetImage(image). If 
>>> it still fail, it return a AttributeError, exactly as using SetInput if 
>>> it does not exists.
>>> I don't see case where it can't work...
>> For me, it will stay in a second (interessant) point. At this time, I 
>> focus on a
>> best use of the itk wrapping (essentially with python).
>>
>
> I done like you when I began to write my module, but when I have seen that 
> this module allow me to add feature which reduce amount of code, I haven't 
> hesitate to add it.
> I hope you will come to it soon ;-)
>
>>
>>>>> I agree that type names are not really consistent, but I'm not sure 
>>>>> your
>>>>> solution is totally doable. How would you call wrapped
>>>>> BinaryDilateImageFilter :
>>>>>
>>>>>    ITK_WRAP_OBJECT3(BinaryDilateImageFilter, image::F2 , image::F2 ,
>>>>> structuringElement::F2,   itkBinaryDilateImageFilterF2F2  );
>>>>
>>>> The images are : IF2
>>>> For the structure element, we can prefix by SE, so we have the result 
>>>> : SEF2
>>>> Finally, we obtain : BinaryDilateUmageFilterIF2IF2SEF2
>>>>
>>>> But we may consider that the structure element can be different that
>>>> structuringElement::F2
>>>> for each 2D images process, so the resulting mangled name will be :
>>>> BinaryDilateUmageFilterIF2IF2
>>>
>>>> I will see to have a mix between our solutions. But I think the first 
>>>> point
>>>> to solve is to have a coherence between all mangled names.
>>>
>>> If you can implement class creation at wrapping time, it would be 
>>> really great : it's important for me to be able to use completion.
>>> Also, I found usage of [type] (__getitem__) much nice than giving the 
>>> type in New function, and it allow to use New for other things.
>>> On the other side, your typing mechanism is stronger than mine (which 
>>> is nothing more than refinding the string used in InsightToolkit 
>>> module) and allow interesting things, such as the example you have 
>>> given :-)
>> I have finished to mix our 2 codes. The result is very good and offers a 
>> simple use
>> But with a first parse of the itk classes :-(
>> I have used my parsing and adapted it to your classes. I have added some 
>> usefull
>> methods in classes to have facilities.
>
> Great:-), but sadely you took an old version of my module, and lots of 
> things are better now, without talking of New method facilities (dict 
> interface for types, no names with _ prefix in itk module, better 
> management of __call__ to be consistent with vtk, ...)
> I'm modifying it to integrate changes.
Where could I get the last version of your module ?


> Also, I don't really understand the can_instanciate method : some classes 
> can be instanciated without New method, just with () (Ex: itk.Index[2]())
But some classes found like ImageToImageFilter aren't instanciable because
they haven't the ::New method (in the C++ code). The can_instanciate method
is to differenciate super classes and instanciable classes


>
>>
>> In your solution, you have kept the _New, _Pointer, _SuperClass, etc. 
>> extentions
>> to create corresponding methods New, Pointer, SuperClass. What is the 
>> interest
>> to keep Pointer, Superclas, etc. ? Have the New method seems to me the 
>> only
>> usefull method.
>
> I don't know if other methods are useful. In doubt, I kept them. The goal 
> was to make everything in InsightToolkit module avaible in itk module.
But in your solution, you don't make difference between
 - classes : _Pointer, _SuperClass
 - methods : _New
Having methods is usefull but I don't see the interest to have the 
_SuperClass.
Concerning _Pointer, it may be usefull, but I'm not sure.



>>> Can we get your code somewhere ?
>> Yes, I have made a CVS repository on our server :
>>    CVSROOT : :pserver:anonymous at cvs.creatis.insa-lyon.fr:2402/cvs/public
>>    password  : anonymous Module name : itkWrapping
>>
>> All is in the python directory :
>>  itkParser.py : the parser of the itk classes
>>  itk.py : creation of classes
>>  itkTestX.py : 3 tests presenting the use and limitations

Benoit Regrain