[Dcmlib] Etat des lieux

[Emmanuel Olart]

Menfin c pas une heure pour ecrire ca ! :)

>    Chers amateurs de dicom, ;-/

On sent que tu y crois :)

>
> 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++).

Je regarde ca dès demain


>  * les sequences, overlays et autres choses exotiques ne sont pas
parse'es.

? je comprend pas :)

>  * il manque certaines methodes de gcdmHeader (travail qui devrait etre
>    facile car les fonctions de base sont ecrites),

Je regarde également ca

>  * il manque encore toute la partie gdcmFile (dont le writer! mais je ne
>    suis pas inquiet sur le sujet),

Je peux faire l'héritage et ecrire les fonctions de base, je verrais le
writer avec JPR

>  * les multi-frames sont trouve's, mais il faudrait definir ce que
>    l'on en fait.

Simplement charger les data, ce serait ptet sympa de voir a ecrire un
multiframe en slices (je fais ca sous python)

>  * pas encore de vtkACRReader base' sur la DCMlib.

Pour les ACR libido ?

>  * 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).
>

oh oui oh oui :) je regarde si ca se fait bien :)

>
> 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.
>

Euh c'est le moins que l'on puisse dire. J'essaye d'avancer un maximum
demain (j'ai le temps pour une fois)

> 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]
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at www.creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/public/mailman/listinfo/dcmlib
>