[Insight-developers] Re: [ITK + Python] Wrapping classes proposal -
V.2
Benoit Regrain
benoit.regrain at creatis.insa-lyon.fr
Thu Jun 23 08:44:32 EDT 2005
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 ?
> + 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 :-(
> 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
More information about the Insight-developers
mailing list