[Dcmlib] Re: [Creatis-hackers] Pb metaphysique gdcm

[Emmanuel Olart]

Je me souviens avoir utilisé des tables de hashage qui empilaient les
valeurs correspondant a une meme clef en liste, cela doit donc exister dans
la STL.

Mais n'y aurait t il pas probleme de toute manière derriere pour savoir
affecter les differents elements de la liste (dans le cas d'une repetition
en sequence des memes groupe / element). On peut bien sur considerer que la
liste est constituee au fir et a mesure de la lecture du fichier est qu'elle
est donc triee dans le bon ordre au départ ce qui devrait permettre de
reecrire de la meme maniere.

Ce serait certainement plus simple que de gerer une liste en plus, qui ne
garantirais d'ailleurs pas de ne perdre aucunes donnees.

Manu

----- Original Message -----
From: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>
To: "Liste des developpeurs" <creatis-hackers at creatis.insa-lyon.fr>;
<dcmlib at creatis.insa-lyon.fr>
Sent: Monday, November 03, 2003 10:18 AM
Subject: [Dcmlib] Re: [Creatis-hackers] Pb metaphysique gdcm


> ----- Original Message -----
> From: "Jean-Pierre ROUX" <jean-pierre.roux at creatis.insa-lyon.fr>
> To: <dcmlib at creatis.insa-lyon.fr>; <creatis-hackers at creatis.insa-lyon.fr>
> Sent: Monday, October 27, 2003 10:25 AM
> Subject: [Creatis-hackers] Pb metaphysique gdcm
>
>
> > --> Autre pb, plus 'sensible'.
> >
> > Toute l'architecture de gdcm est basée sur le fait, vrai en première
> > approximation seulement (euphémisme pour dire : faux) que le 'Dicom
> > tag', c'est à dire 'Group Number + Element Number' est un identifiant
> > pour les Dicom Elements dans le Header (le Dicom Tag est bien un
> > identifiant, mais dans le Dicom Dictionnary seulement).
> > Lorsque le même Dicom Tag apparait plusieurs fois, c'est
> > systématiquement le dernier qui est retenu (Hash Table oblige), ce
> > qui fait que le Header résultant *ne permet plus* de reconstituer sur
> > disque une image DICOM 'équivalente' à l'image d'origine, et, pire,
> > que les info 'restantes' ne sont pas pertinentes (par exemple, dans
> > le cas d'une image 'avec icone', le Row Number, Column Number, Bits
> > stored, Bits Allocated ne donnent pas les info attendues)
> >
> > Serait-ce une idée (mais là, je suis moins sûr de sa pertinence) que
> > de créér une 'Liste' des Dicoms Elements rencontrés sur disque, en
> > même temps que les deux tables de hachage (sur le Tag et sur le nom),
> > qui contiendraient toutes les deux un pointeur vers le Dicom Element
> > à l'intérieur de la Liste ?
> > On pourrait ainsi être mesure de restaurer dans les tables de Hachage
> > des info s'il s'avère qu'elles ont été 'écrasées' de manière abusive,
> > sans être obligé de tester, à la volée, et pour chaque Elément, lors
> > du parsage du Header si on ne s'apprete pas a écraser abusivement qq
> > chose.
> >
> Ta solution ne changera rien, il y aura toujours des éléments perdus dans
la
> table de
> hachage.
> Une autre solution serait peut-etre envisageable... avoir une table de
> hashage qui, pour
> une clé (Dicom Tag) donnée contient plusieurs valeurs. Apres, c'est le
> HeaderHelper pourrait
> contenir les routines permettant par exemple d'associer une image a ses
> tailles respectives
> (pour un fichier contenant une icone).
>
> Avis pour des remarques sur ces idées...
>
> Benoit
>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>