[Insight-developers] Re: [ITK + Wrapping (Python)] Wrapping classes
proposal - V.3
Gaetan Lehmann
gaetan.lehmann at jouy.inra.fr
Tue Jun 28 03:41:12 EDT 2005
Hi Benoit,
I'm using a fresh cvs check out
Gaetan
On Mon, 27 Jun 2005 16:25:15 +0200, Benoit Regrain
<benoit.regrain at creatis.insa-lyon.fr> wrote:
> Hi,
>
> I have created the wrap_Xxx.cmake for the last release of Insight
> (version 2.0.1).
> But it seems you are using a more recent version :-(
>
> If you send me you version (if it's not the current nightly version), I
> could see changes.
>
> Cheers
> 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>
> Cc: "Brad King" <brad.king at kitware.com>
> Sent: Monday, June 27, 2005 2:40 PM
> Subject: Re: [ITK + Wrapping (Python)] Wrapping classes proposal - V.3
>
>
>>
>> Hi Benoit,
>> Hi Brad,
>>
>> I'm not able to build itk python with your patch : it fails on
>> ITKRigidTransforms after lots of warnings about hierarchy gaps (see
>> error messages below). Have you forgotten to submit some changes ?
>>
>> Brad, is it possible to make build fail for wrapping gaps ? I can't see
>> case where it is useful to have wrapping gap warning instead of an
>> error.
>>
>>
>> Gaetan
>>
>> Building object file wrap_ITKRigidTransformsPython.o...
>> /home/glehmann/itk/itk/build/Wrapping/CSwig/Common/wrap_ITKRigidTransformsPython.cxx:
>> In function `PyObject*
>> _wrap_itkRigid3DTransformD_Pointer_GetInverse(PyObject*, PyObject*)':
>> /home/glehmann/itk/itk/build/Wrapping/CSwig/Common/wrap_ITKRigidTransformsPython.cxx:5005:
>> error: invalid conversion from `itk::Transform<double, 3u, 3u>*' to
>> `itk::MatrixOffsetTransformBase<double, 3u, 3u>*'
>> /home/glehmann/itk/itk/build/Wrapping/CSwig/Common/wrap_ITKRigidTransformsPython.cxx:5005:
>> error: initializing argument 1 of `bool
>> itk::MatrixOffsetTransformBase<TScalarType, NInputDimensions,
>> NOutputDimensions>::GetInverse(itk::MatrixOffsetTransformBase<TScalarType,
>> NInputDimensions, NOutputDimensions>*) const [with TScalarType =
>> double, unsigned int NInputDimensions = 3u, unsigned int
>> NOutputDimensions = 3u]'
>> /home/glehmann/itk/itk/build/Wrapping/CSwig/Common/wrap_ITKRigidTransformsPython.cxx:
>> In function `PyObject*
>> _wrap_itkQuaternionRigidTransformD_Pointer_GetInverse(PyObject*,
>> PyObject*)':
>> /home/glehmann/itk/itk/build/Wrapping/CSwig/Common/wrap_ITKRigidTransformsPython.cxx:8620:
>> error: invalid conversion from `itk::Transform<double, 3u, 3u>*' to
>> `itk::MatrixOffsetTransformBase<double, 3u, 3u>*'
>> /home/glehmann/itk/itk/build/Wrapping/CSwig/Common/wrap_ITKRigidTransformsPython.cxx:8620:
>> error: initializing argument 1 of `bool
>> itk::MatrixOffsetTransformBase<TScalarType, NInputDimensions,
>> NOutputDimensions>::GetInverse(itk::MatrixOffsetTransformBase<TScalarType,
>> NInputDimensions, NOutputDimensions>*) const [with TScalarType =
>> double, unsigned int NInputDimensions = 3u, unsigned int
>> NOutputDimensions = 3u]'
>> /home/glehmann/itk/itk/build/Wrapping/CSwig/Common/wrap_ITKRigidTransformsPython.cxx:
>> In function `PyObject*
>> _wrap_itkVersorRigid3DTransformD_Pointer_GetInverse(PyObject*,
>> PyObject*)':
>> /home/glehmann/itk/itk/build/Wrapping/CSwig/Common/wrap_ITKRigidTransformsPython.cxx:19122:
>> error: invalid conversion from `itk::Transform<double, 3u, 3u>*' to
>> `itk::MatrixOffsetTransformBase<double, 3u, 3u>*'
>> /home/glehmann/itk/itk/build/Wrapping/CSwig/Common/wrap_ITKRigidTransformsPython.cxx:19122:
>> error: initializing argument 1 of `bool
>> itk::MatrixOffsetTransformBase<TScalarType, NInputDimensions,
>> NOutputDimensions>::GetInverse(itk::MatrixOffsetTransformBase<TScalarType,
>> NInputDimensions, NOutputDimensions>*) const [with TScalarType =
>> double, unsigned int NInputDimensions = 3u, unsigned int
>> NOutputDimensions = 3u]'
>> make[5]: *** [wrap_ITKRigidTransformsPython.o] Erreur 1
>> make[4]: *** [default_target] Erreur 2
>> make[3]: *** [default_target_Common] Erreur 2
>> make[2]: *** [default_target] Erreur 2
>> make[1]: *** [default_target_Wrapping_CSwig] Erreur 2
>> make: *** [default_target] Erreur 2
>>
>>
>> On Fri, 24 Jun 2005 15:52:27 +0200, Benoit Regrain
>> <benoit.regrain at creatis.insa-lyon.fr> wrote:
>>
>>> Hi,
>>>
>>> Following some mails on the subject :
>>> [ITK + Python] Wrapping classes proposal
>>> [ITK + Python] Wrapping classes proposal - V.2
>>>
>>>
>>> Changes between V.2 and V.3 :
>>> - the wrap_Xxx.cmake have been written for all itk parts
>>> - the mangled name can be choosed randomly (but not for all classes)
>>> - the class tree is now independant to the mangling name (in the
>>> final wrapped language)
>>>
>>>
>>> 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 (from the ITK project v2.0.1) :
>>>
>>> 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...
>>>
>>> For certain classes used to define the template of other classes, it
>>> may be
>>> good to have a consistant mangled name. These class's wraps are in the
>>> CSwig/WrapTypePrefix.cmake file.
>>> For other classes, the mangled name can be choosed randomly.
>>>
>>>
>>> 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")
>>> For specific internal processing, I will set the class name.
>>> The itkPyTemplate class can be used like a python dictionnary :
>>> - the key is the template definition (like in C++)
>>> - the value is the defined template class
>>>
>>> Next, I will call the set method on this new class instance to add
>>> different templates :
>>> itkImage.set("float,2",itkImageF2)
>>> itkImage.set("itk::Vector< float,2 >,2",itkImageVF22)
>>> The first parameter is parsed to know all the template definitions
>>> used.
>>> We obtain a tuple of all types needed to obtain the class (value
>>> corresponding to the key)
>>> Then, the itkPyTemplate instance can be used like a dictionnary.
>>> So, I can write :
>>> itkImage["F",2]
>>> itkImage[ITK_F,2] # ITK_F = "F"
>>> to get the itkImageUS2 class.
>>> or write :
>>> itkImage[itkVector["F",2],2]
>>> to get the itkImageVF22 class
>>>
>>> Internally, a class variable (that is a dictionnary) is used to
>>> translate from
>>> "itk::Vector< float,2 >" template definition to the itkVectorF2
>>> class
>>> But to know this type, the order of itkPyTemplate classes instanciation
>>> is important :-(
>>>
>>> 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).
>>> To do this implementation in other languages, we only need to have
>>> the type of objects. It's possible in C and Python, I think it's
>>> possible
>>> in Java and Tcl (but I don't know these languages)
>>>
>>> Information : I'm working on a C++ version of the actual
>>> itkPyTemplate, but I'm not sure that it's possible to do...
>>
>>
>>
>> -- 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
More information about the Insight-developers
mailing list