[Insight-developers] Re: [ITK + Python] Wrapping classes proposal - V.2

[Gaetan Lehmann]

On Thu, 23 Jun 2005 14:44:32 +0200, Benoit Regrain  
<benoit.regrain at creatis.insa-lyon.fr> wrote:

> Hi,
>
> ----- Original Message ----- From: "Gaetan Lehmann"  
> <gaetan.lehmann at jouy.inra.fr>
> To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>; "Brad King"  
> <brad.king at kitware.com>
> Cc: <insight-developers at itk.org>
> Sent: Thursday, June 23, 2005 1:08 PM
> Subject: Re: [ITK + Python] Wrapping classes proposal - V.2
>
>
>>
>> Hi Benoit,
>> Hi Brad,
>>
>> some comments, without special order :
>>
>> + Better mangling seems to be a good thing but I'm don't believe it's  
>> the
>> solution to your problem. I'm quite sure you can't express all  
>> complexity
>> of existing ITK templates with a few characters and without separator.
>>
>> + The solution you give let user do cleaner work, but you can't be sure
>> that he will use your predifined vars, so you can't be sure you will be
>> able to parse resulting name
>>
>>   SET(itk_Wrap
>>    "${ITKM_F}2  # ${ITKT_F},2"
>>   )
>>
>> can be replaced by
>>
>>   SET(itk_Wrap
>>    "aStupidName45  # ${ITKT_F},2"
>>   )
> Here, the name isn't really important. The problem is while the use of  
> the wrapped classes
> with the tree of classes... How to find the class : itkImage[ITK_US,2] ?
> I'm open to all comments on it.
>
>
>> without problem. Type name should be generated by the build system and  
>> not
>> given by the user.
>>
>> + "${ITKM_F}2  # ${ITKT_F},2" notation (with a # as separator) is not
>> really nice. You should mask it with another macro
>>
>>   SET(itk_Wrap
>>    WRAP_VALUES("${ITKM_F}2", "${ITKT_F},2")
>>   )
> Can a CMake macro return a value ?
> How are you doing it ? What code will we write in the WRAP_VALUES macro ?
>

I was still in c++ macros :-P
I don't know if it can be done with cmake

>
>
>> + you have not created a macro to warp the superclass in the same time
> Yes, I have made it today... I'm writting the wrapping for all other ITK  
> parts.
> At this time, it's not on the CVS repository
>
>
>> + It's probably not an important problem because only a few people seems
>> to use ITK wrappers, but I don't think it's a good idea to break
>> compatibility with old versions.
> Yes, but I actually have found no other solutions :-(
>
>
>
>> + be able to write a file while wrapping (your itkcommonPy.py) is a good
>> point. It's a really good point for languages which can't generate  
>> module
>> menbers at runtime as python can.
> This may be generalised for all wrapped languages. The actual only  
> problem
> is the generation of members at runtime. But if ITK wrapped classes have
> these informations in native while the wrapping, there will no more be a  
> problem.
>
>
>> A better solution for me is to have access to c++ template parameters in
>> other languages, so we can give the name we want, it will not break
>> parsing of template parameters.
>>
>> for example
>> itkMedianImageFilterUS3US3 will have :
>>
>>  __template_classes__ = [itkImageUS3, itkImageUS3]
>>
>> It would also be great to have template parameters as attributes :
>>   itkMedianImageFilterUS3US3.TInputImage == itkImageUS3
>>   itkMedianImageFilterUS3US3.TOutputImage == itkImageUS3
>> and to know default template parameters value, to be able to say which
>> parameters can be absent. For example, we could say that
>>   itkBinaryDilateImageFilter[itkImageUS3, itkImageUS3]
>> is equivalent to
>>   itkBinaryDilateImageFilter[itkImageUS3, itkImageUS3,
>>   itkBinaryBallStructuringElement[itkImageUS3]]
>> Brad, is it possible to get those informations with cable swig :
>>  + template parameters (it's possible, see below, but there is surely
>> something better) ?
>>  + template parameters names ?
>>  + template parameters default values ?
>
> I have seen the CableSwig use and I haven't found solutions to add
> variables while the wrapping. It's possible with Swig because we don't
> have the use of gcc and cableidx before the swig call.
> Brad, have you a solution for that ?
>
>
>
>> A small patch to cable swig let us have access to template parameters in
>> python (see attached file). With this patch, we have a new attribute
>> called __real_classname__ which can be parsed to create
>> __template_classes__ attribute... I have still found nothing for  
>> template
>> names and default values.
>> Ex :
>> 13> InsightToolkit.itkMedianImageFilterUS3US3.__real_classname__
>> 13> 'itk::MedianImageFilter<(itk::Image<(unsigned
>> short,3)>,itk::Image<(unsigned short,3)>)>'
>
> But how to pass from
>    itk::MedianImageFilter<itk::Image<unsigned  
> short,3>,itk::Image<unsigned short,3>>
> to
>    itkMedianImageFilterUS3US3 (or itkMedianImageFilterIUS3IUS3 with my  
> wrapping)
> At this time, I have no good solution than use the strings :-(
>

but I don't want to convert itk::MedianImageFilter<itk::Image<unsigned  
short,3>,itk::Image<unsigned short,3>> to itkMedianImageFilterUS3US3. As  
said above, I don't think a few characters in upper case and without  
separator is enough to express all the complexity of existing ITK  
templates.
I want to convert it to python objects and use those objects to identify  
template parameters

>
>> A comment on your write( itkImg, file ) example : What I like in your
>> module, is that we give real types as in c++ templates. In python we  
>> can't
>> really give types, but we can give class objects. This is what we do  
>> when
>> we write
>>
>>   imType = itk.Image[itk.US, 3]
>>   writerT = itkImageFileWriter[imType]
>>
>> so, to be more consistent, you should write
>>
>>   writerT = itkImageFileWriter[itkImage.__class__]
>>
>> instead of
>>
>>   writerT = itkImageFileWriter[itkImage]
>>
>> Last changes you done on itk.py allow that :-)
>> More than that, giving template parameters as string (as I do in my itk
>> module) should not be allowed. Only classes, basic types (itk.US, itk.F,
>> itk.UL, ...) and numbers should be ok.
>
>
>> On Wed, 22 Jun 2005 17:14:50 +0200, Benoit Regrain
>> <benoit.regrain at creatis.insa-lyon.fr> wrote:
>>
>>> Hi,
>>>
>>> Following some mails on the subject :    [ITK + Python] Wrapping  
>>> classes
>>> proposal
>>>
>>> I have worked on the ITK wrapping. Then, I have made 2 serious changes
>>> (presented later). It's actually made only on the Common part and for
>>> python
>>>
>>> All of this work can be found on the Creatis CVS server :
>>>    CVSROOT :  
>>> :pserver:anonymous at cvs.creatis.insa-lyon.fr:2402/cvs/public
>>>    password  : anonymous    Module name : itkWrapping
>>>
>>>
>>> Concerning this patch, I would now :
>>>  - if ITK is interested by that, and integrate it
>>>    (thus, I will continue and write the wrap_Xxx.cmake
>>>    files for other ITK parts)
>>>  - if there have conceptual or other problems with this proposal
>>>    (for each of 2 points)
>>> Thanks to ITK to answer me concerning their interest for
>>> this proposal.
>>>
>>> Cheers
>>> Benoit Regrain
>>>
>>>
>>>
>>> ---> Presentation of changes :
>>>
>>> 1 - Use of CMake to generate wrapping :
>>> ------------------------------------------
>>> All wrap_Xxx.cxx files are directly generated by CMake.
>>> For :
>>>  - There is no enought C++ macros (that are numerous and
>>>    copied between some files... ex : All Transform classes wrapping)
>>>  - All classes are wrapped with consistent rules. The mangled    name  
>>> is
>>> then coherent between all classes
>>>  - It simplifies the integration of the second point (Tree of
>>>    templated classes)
>>>  - The itkCSwigMacro.h and itkCSwigImage.h files are now useless...
>>>    Thus, it's easier to wrap personal ITK classes without integrate  
>>> them
>>>    in the ITK folder tree.
>>>  - Best support for future ITK addons
>>> Against :
>>>  - The mangled name isn't kept  The write of these files is made using
>>> CMake macros. These macros
>>> are in CSwig/WrapITK.cmake
>>> The CSwig/WrapType*.cmake files are help  for the basic types and
>>> advanced types creation. These types are used define the template
>>> classes.
>>> In CSwig/Common : all wrap_Xxx.cxx files are replaced by wrap_Xxx.cmake
>>> when it's needed
>>>
>>>
>>> 2 - Tree of templated classes :
>>> -------------------------------
>>> The goal is to have a simplest and generic use of templated ITK  
>>> classes.
>>> Consider this python example :
>>>    def write( itkImg, file ) :
>>>       # typedef itk::ImageFileWriter< itkImg::Self > writerT
>>>       writerT = itkImageFileWriter[ itkImg ]
>>>       writer = writerT.New()
>>>       writer.SetInput( itkImg )
>>>       writer.SetFileName( file )       writer.Update()
>>>
>>> This function will write an image (itkImg) in a file.
>>> But the writer creation is dependant to the itkImg type. The goal is :
>>> offer the possibility to the programmer to instanciate an ITK class
>>> without before known of the itkImg
>>> type.
>>>
>>> To have it, I will create a new class instance of itkPyTemplate type
>>> while the wrapping of the ITK classes.
>>> So, I will have :    itkImage = itkPyTemplate("itkImage","I")
>>> For specific internal processing, I will set the class name and the
>>> mangling prefix (prefix found in the CSwig/ITKTypePrefix.cmake file).
>>> The itkPyTemplate class can be used like a python dictionnary
>>>
>>> Next, I will call the set method on this new class instance to add
>>> different templates :
>>>    itkImage.set("US2",itkImageUS2)
>>> First parameter is the template type used as a key and the second
>>> parameter is the definition corresponding to the key.
>>> So, I can write :    itkImage["US2"] to get the itkImageUS2 class.
>>> After, I call the New method on this class and I get a class instance.
>>>
>>> The code of the itkPyTemplate class is at CSwig/Python/itkPyTemplate.py
>>> The code to generate these classes is written by CMake. It's
>>> in the resulting file : itkcommonPy.py for the common part
>>> Last, we need call the itkcommonPy module while the import of
>>> InsightToolkit package.
>>> In the CSwig/Tests/Python directory, I added the testTemplate.py file  
>>> to
>>> test the class creation The code to write the itkcommonPy.py file is in
>>> CSwig/WrapITK.cmake
>>> This code contains the WRITE_LANG_WRAP macro that will
>>> write these additionnal python classes
>>>
>>> This solution is actually only in python but it can be implemented for
>>> Java (I don't know if Tcl has classes... but a similar solution may be
>>> found).
>>>
>>
>>
>>
>> -- Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr>
>> Tel: +33 1 34 65 29 66
>> Biologie du Développement et de la Reproduction
>> INRA de Jouy-en-Josas (France)
>> Web: http://voxel.jouy.inra.fr
>



-- 
Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr>
Tel: +33 1 34 65 29 66
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
Web: http://voxel.jouy.inra.fr