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

[Jean-Pierre Roux]

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

JPRx

> 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