[Insight-developers] Re: [ITK + Python] Wrapping classes proposal -
V.2
Gaetan Lehmann
gaetan.lehmann at jouy.inra.fr
Thu Jun 23 07:08:53 EDT 2005
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"
)
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")
)
+ you have not created a macro to warp the superclass in the same time
+ 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.
+ 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.
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 ?
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)>)>'
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: realclassname.patch
Type: application/octet-stream
Size: 947 bytes
Desc: not available
Url : http://www.itk.org/mailman/private/insight-developers/attachments/20050623/bae42da9/realclassname.obj
More information about the Insight-developers
mailing list