<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Bonjour à tous !</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>J'ai fini pour ma part de porter notre outil
StudyBrowser et notre Reader DICOM / VTK qui fonctionnaient avant avec libido
sur gdcm.</FONT></DIV>
<DIV><FONT face=Arial size=2>Globalement les résultats sont à la hauteur des
espérances, surtout au niveau parse d'entete ou je gagne 5 a 6 fois la vitesse
initiale :)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Dans ma première réécriture de notre parseur, j'ai
fait hériter mes objets "Images" d'un gdcmHeader. Seulement voila, un
gdcmHeader, lorsqu'il est créé, ouvre le fichier dicom, le lit, parse le header,
charge la HashTable, et le laisse ouvert.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Ceci m'amène à la question suivante : est ce le
fonctionnement normal du Header de garder le fichier auquel il est associé
ouvert ?</FONT></DIV>
<DIV><FONT face=Arial size=2>Je ne me souviens pas d'une conversation sur ce
sujet, excusez si cela a déja été débattu.</FONT></DIV>
<DIV><FONT face=Arial size=2>Le fichier est actuellement fermé à la destruction
de l'objet gdcmHeader.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Le fonctionnement actuel fait bien entendu exploser
mon parser aux alentours de 1000 gdcmHeader créés puisque j'atteint la limite
autorisée sur le système en nombre de fichiers ouverts.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>On pourrait envisager de refermer le fichier après
parsage du Header, puis de le réouvrir éventuellement si on décide de réécrire
le Header, ce qui est plus rare je pense que le fait de simplement parcourir
l'entete a des fins de recuperation d'infos et de tri.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Si cette solution est choisie, elle pose un petit
problème pour le gdcmFile qui doit réouvrir le fichier pour lire les
données.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>______</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Si la réponse est oui, on le laisse comme ca,
l'héritage d'un gdcmheader pour constituer un outil représentatif d'une image
dans une application destinée a afficher ces infos et éventuellement en
permettre la modification me semble du coup d'un intéret limité.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Le fait d'utiliser un gdcmHeader non plus comme
héritage, mais simplement comme 'outil' pour lire le contenu d'un entete, puis
de stocker ce contenu dans un autre objet 'maison' destiné a le garder a long
terme me semble tout a fait jouable, mais plus pénible et surtout moins
ergonomique dans une application de classification en Study / serie / image de
grandes quantité d'images comme c'est le cas chez moi.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Je ne sais pas si je suis très clair dans mon
explication, n'hésitez pas a poser des questions :)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Manu</FONT></DIV></BODY></HTML>