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

[Benoit Regrain]

----- Original Message ----- 
From: "Jean-Pierre Roux" <Jean-Pierre.Roux at creatis.insa-lyon.fr>
To: <benoit.regrain at creatis.insa-lyon.fr>
Cc: <creatis-hackers at creatis.insa-lyon.fr>; <dcmlib at creatis.insa-lyon.fr>
Sent: Monday, November 03, 2003 11:39 AM
Subject: Re: [Dcmlib] Re: [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.
>
> En effet, dans la table de Hachage, des éléments seraient perdus (en fait,
> des pointeurs sur ces éléments seraient perdus ...), mais *tous* les
> éléments seraient présents dans la liste, et a leur place.
> ce qui n'est pas le cas, dans la table de hachage, pour les elements :
>
> fffa fffa SQ XX  Digital Signatures Sequence
> fffc fffc OB XX  Data Set Trailing Padding
> fffe e000 UL DL  Item
> fffe e00d UL DL  Item Delimitation Item
> fffe e0dd UL DL  Sequence Delimitation Item
>
> qui se retrouvent tjs en 'fin de table'
>
> Si on veut refaire une image Dicom, à partir du gdcmHeader (ce qui ne
> parait pas etre une exigence excessive) on pourrait le faire (pas le cas
> actuellement, dans les cas 'sensibles')
>
> - De même on pourrait lire le fichier DICOMDIR, qui se trouve sur les CD
> Rom Dicom, et ca permettrait, lorsqu'on reçoit un CD, de ne s'interesser
> qu'aux images qui nous concernent, au lieu de devoir parser les headers de
> toutes les images du disque.
>
> Et si, d'aventure un champ indique la présence d'une icone (donc NX, NY,
> taille pixels, etc, fichus en l'air), on pourra aller les rechercher dans
> la liste (moins pénalisant que de tester, lors du parsing, si le champ
> courant signale une icone, et alors, de garder les info de l'image et de
> ne pas les ecraser avec celles de l'icone, lorsqu'on les rencontrera ...)
>
> JPR
Si je comprend bien, l'ordre des éléments a une importance...
Peux tu confirmer cela ?

Et si c'est bien le cas, alors effectivement la liste a son importance pour
résoudre le problème.
Et la table de hashage a-t-elle toujours sont utilité ? elle est certes
utile pour retrouver rapidement un champs,
mais si celui ci est écrasé lorsqu'il y a doublon... ca pose des problèmes
dans son utilisation.

Il serait peut etre nécessaire de revoir la structure de gdcm concernant ce
point la... et en tout cas, au moins l'interface
des classes concernant l'acces aux données de l'entete.

Benoit