[Dcmlib] Etat des lieux

[Eric Boix]

   Chers amateurs de dicom, ;-/

Voici un bref etat des lieux de dicomlib :
 * la substance de acr/libido est convertie en C++ en respectant l'API
   que nous avions defini.
 * excision de la glib pour la version Un*X: gcc utilise ISO C99: 7.18
   qui definie les deux types dont nous ayons besoin [cf 
   /usr/include/stdint.h sur une machine ayant gcc] i.e. uint16 et uint32
 * le tout est wrappe' pour Python (il faut la version devel de swig, cf
   le fichier d'INSTALL), et renvoit un dictionnaire natif Python (cf
   python/demo/test.py).
 * une test suite est ecrite en Python (avec unittest) et une collection
   d'images de test se trouve dans le repertoire Data. De nombreux
   commentaires sur ces images et les limitations de DCMlib dans son
   etat actuel sont en commentaire dans python/testSuite.py

Les grosses limitations actuelles sont les suivantes:
 * pas d'avancement sur la version Win32 (si ce n'est un test de compilation
   effectue' avec Hugues, pour constater que le test en C fonctionne MAIS
   est 30 fois plus lent que sous Un*x). Les wrapper python se plantent, mais
   en l'absence de pythond.dll (la version debug de la python lib pour WIn32)
   le sujet s'annonce chaud. Il est urgent qu'un vrai developpeur Win32
   ce colle sur le sujet, car VC++ me colle des boutons. Je ne sais pas
   si il est opportun de distraire Benoit Regrain avec ces joyeusete'es, bien
   que cela semble naturellement lui echoir. IMVHO il serait sans doute bon
   de voir si .net (VC++ 7.0) est plus efficace dans les acces disque
   (l'incroyable lenteur sous Win32 etant peut-etre du a des acces disque
   non bufferis'es, mais bon je suis nul en Windowseries).
 * les pixels data d'images encode'es (RLE, et toutes les moutures de JPEG)
   ne sont pas accessibles car je n'ai pas trouve' de bibliotheque PORTABLE
   (ni meme complete pour toutes les sous-ensembles de JPEG) sachant faire:
   le point d'entree sur les librairies JPEG semble etre ici
     http://www.faqs.org/faqs/jpeg-faq/part2/
   IMHO c'est le plus gros morceau qui reste encore a faire, et ACR/Libido
   ne sais pas faire non plus.
 * il faudrait remplacer les fseek et fread (qui font partie de la libc)
   par des manipulations sur les iostreams (i.e. les IO a la C++).
 * les sequences, overlays et autres choses exotiques ne sont pas parse'es.
 * il manque certaines methodes de gcdmHeader (travail qui devrait etre
   facile car les fonctions de base sont ecrites),
 * il manque encore toute la partie gdcmFile (dont le writer! mais je ne
   suis pas inquiet sur le sujet),
 * les multi-frames sont trouve's, mais il faudrait definir ce que
   l'on en fait.
 * pas encore de vtkACRReader base' sur la DCMlib.
 * il faudrait une surcouche au shadow wrapper genere's par swig, qui
   permettrait de pointer sur les dictionnaires (cela est actuellement
   integr'e a chacun des exemples, cf python/demo/load.py).


Voila, j'estime avoir fait copieusement ma part sur le sujet et
je considere la balle dans votre camp. Je reste a votre disposition
pour toute question, precision, reunion (j'exagere un peu) ou relance
du sujet.

En attendant, j'ai un ou deux projets au chaud et des chercheurs qui
attendent. Je tacherais de continuer a avancer plus lentement, le soir
a mes heures perdues, vautre' devant la teloche...en commenc,ant par un
ch'ti nettoyage des FIXME eparpille's. 

	Bien a vous,
   Frog, un peu fatigue' par le manque d'investissement de JPR sur le sujet...
         [les malheureux lecteurs de info-team savent de quoi je parle]