[Dcmlib] Pb metaphysique gdcm

[Jean-Pierre ROUX]

Bonjour.

--> Actuellement, le constructeur de gdcmHeader renvoie .. un 
gdcmHeader, c'est à dire le contenu de ce qu'il a trouvé sur disque 
concernant les champs du Header, et GetPixelData renvoie les Pixels, 
présentés de telle sorte que l'utilisateur n'ai pas à se soucier de 
la manière dont ils étaient écrits sur disque.
Facile.
Ainsi, les pixels, qu'ils aient été big Endian ou little endian sur 
disque, sont renvoyés dans un ordre compatible avec celui du 
processeur, que la 'Planar Configuration' ait indique que le 'RGB' 
est codé au niveau du Pixel (RGBRGBRGBRGB ...) ou au niveau du Plan 
(RRRRR.... GGGGG.... BBBBB.....), on renvoie RGBRGBRGB..., ce qui 
permet à vtk d'afficher sans se poser pb.
Jusque la, tout va bien.

Lorsqu'il y a une ou des 'Palettes LUT', GetPixelData 'fabrique' une 
'image RGB', de telle sorte que vtk, etc, et met à jour dans le 
Header les info qui 'décrivent' une image RGB, afin que les 
programmes qui interrogent le Header trouvent une info cohérente.
Et c'est là que ça se gâte ...
Si un programme a accédé à un ensemble d'images, conservé en mémoire 
les Headers des images sur lesquelles il souhaite travailler, puis 
appelle GetPixelData, il aura des info incohérentes dans 'ses' 
Headers lorsqu'il voudra exploiter les Pixels :-(

La solution qui consisterait à 'mettre à jour' le Header dès qu'il 
est lu n'est pas à retenir, car GetPixelData ne disposerait plus des 
'bonnes' info pour mettre les Pixels en forme.

Doit-on faire des accesseurs -aux noms clairement identifiables- qui 
renverraient, non pas la valeur contenue dans le Header, mais la 
valeur qui *sera* utilisable lorsque GetPixelData aura réorganisé les 
Pixels?

Dans cette hypothèse -qui me parait satisfaisante-, doit-on faire une 
classe pour ces trucs-là?
Les mettre dans la classe gdcmHeaderHelper qu'a fait Mathieu Malaterre?

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

--> Troisième pb, anecdotique par rapport aux précédents :

Certains applicatifs (Creatis) font la supposition que le nom du Tag 
est un identifiant.
Il ne l'est, ni dans le Dicom Dictionnary, ni dans le Header.
De plus sa valeur peut être modifiée d'une année sur l'autre, avec la 
nouvelle mouture annuelle des spécifs Dicoms (le site de David Clunie 
répertorie les modifs d'une année sur l'autre -éléments ajoutés, 
éléments modifiés-.
L'exemple le plus tristement célèbre est 'Patient Name' devenu 
'Patient's Name', qui a causé pas mal de sueurs froides aux gdcmLib 
users...

Voila.
Toute suggestion sur les 2 premiers points serait la bienvenue.

Thx

JPRx



  Jean-Pierre ROUX
  UMR CNRS 5515-CREATIS
  Laboratoire de Radiologie Experimentale
  Hopital Cardiologique
  28 Avenue du Doyen LEPINE
  B.P. Lyon-Montchat
  69394 Lyon Cedex 03

  Tel      : (+33) 04 72 35 74 12
  Fax      : (+33) 04 72 68 49 16
  URL      : http://www.creatis.univ-lyon1.fr
  e-mail   : jpr at univ-lyon1.fr