[Dcmlib] Feedback

[Emmanuel Olart]

Salut a tous,

Comme promis je vous donne un feedback sur la version de gdcm que j'ai
checkout la semaine dernière :

Le wrapping python pose quelques problemes que je suppose connus : il
est notamment impossible d'utiliser toute méthode prenant un std::string
en paramètre ou en retournant un. J'ai bien essayé de bidouiller le .i
(j'utilise pour des modules theralys le meme type de donnée std::string
et je n'ai jamais rencontré de problèmes) mais ca ne passe pas pour une
raison qui m'échappe.

Il faudrait définir quelle méthode doit être wrappée dans le cas d'un
overload, notamment pour les constructeurs. Sur ma version seul
gdcmHeader(void) est wrappé, si je veux l'autre qui me semble plus utile
(d'un point de vue personnel) je l'indique clairement a SWIG.  Serait il
utilie qu'on prenne une par une les methodes surchargées en qu'on décide
lesquelles wrapper pour python ? Dans certains cas, si toutes les
methodes surchargées doivent etre accessible en python la seule solution
est a priori de les renommer ou de creer une fonction de wrapping qui
appelle ensuite les différents candidats, ce qui n'est pas très propre.

Autre problème plus génant a mon sens :

La méthode :

bool gdcmFile::SetImageData(void *inData, size_t expectedSize) est
recemment passée à 
bool gdcmFile::SetImageData(uint8_t *inData, size_t expectedSize)

Ceci a entrainé une série de modifications sur toutes les méthodes sous
jacentes.

La conséquence directe est qu'il n'est plus possible d'écrire autre
chose que du uchar.
J'ai cru comprendre que cette modif a été faite afin de pouvoir faire un
free sur le inData le moment venu.
Il faudrait donc réfléchir a une méthode permettant d'avoir n'importe
quel type de données en entrée, tout en gardant la possibilité de
libérer la mémoire après coup.
Cela peut donc se faire soit avec un template sur le type de données,
soit sur différentes méthodes SetImageData prenant respectivement les
types de données attendus (galère pour python bien sur).

Dernière petite remarque sur ma short list, le python setup.py install
ne copie pas le _gdcm.so la ou il doit aller. 

Voici les remarques que j'ai pour l'instant, feel free to ask any
question :)

Manu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.creatis.insa-lyon.fr/pipermail/dcmlib/attachments/20041005/3d55e243/attachment.html>