[Dcmlib] TestChangeHeader

[Eric Boix]

	Yo,

> Euh, en anglais ca donne quoi ? Plus serieusement, qu'est ce que ca veut
> dire implicit value ?
Pour pouvoir interpreter un champ DICOM dans un fichier binaire, il faut
connaitre son "TYPE" i.e. ce qu'il represente. C'est le role du "Value
Representation" (VR), qui indique si la donne'e d'un champ d'un fichier est
un "UL" (unsigned long), "US" (unsigned short), ...
Une fois que tu disposes de la VR d'un champ, alors tu sais comment
l'interpreter en memoire.
Maintenant un fichier peut-etre code' soit en "Explicit Value Representation"
ou "Implicit Value Representation". Dans le premier cas chaque entre'e 
du fichier DICOM contient sa VR, ce qui donne une chance a l'utilisateur
d'interpreter des champs prive's. 
Dans le deuxieme cas (Implicit Value Representation), c'est le dictionnaire
qui connait la VR d'un champ (le troisieme champe de gdcm//Dicts/dicomV3.dic).
Bien entendu, certains fichiers DICOM verole's s'annoncent comme "explicit"
mais comportent des champs en "implicit" ce qui peut planter le parsing...

> >Je suis en train de me tirer des plombs sur ... la lecture :
Bienvenu au club...

> Au risque de me repeter, je voudrais vraiment simplifier le bidule.
> <Pour moi>
> Lorsque tu lis l'image tu places dans ImageData juste les valeurs lues,
> pour les philips ca correspond juste a accoler tous les morceaux
> d'images. Dans le cas general, l'ImageData n'est pas un flux RGB. Mais
> en revanche on peut rajouter une methode GetImageDataAsRGB(), qui en
> fonction du type d'image (niveau de gris, YBR ...) convertie a la volee
> le flux.
> -> Comme ca a la reecriture on a deja le flux et le champ DICOM adequat.
> -> AMHA, ca doit aussi simplifier la structure interne de gdcmFile.
> 
> Dans l'absolu je serais meme tenter de conserver le flux jpeg
> compresser, et de le decompresser que si l'utilisateur appelle une
> methode specifique. Ca permet de partager le probleme de lecture en deux:
> 
> 1. Essayer de lire l'image DICOM, avec ses champs petes,
> 
> 2. une fois l'image lue, et que l'on sait comment l'image est compressee
> (jpeg, rle...), avec quelles couleurs (RGB, YBR...). Ca devrait donner
> plus de flexibilite a l'utilisateur pour reagir en fonction de ces donnees.
> 
> </Pour moi>
> 
> Avis commentaires ? Tout ca pour dire que si je gagne la majorite, je
> suis volontaire pour coder ca dans gdcmFile. Est-ce qu'il y a des
> problemes que je n'ai pas pris en compte ?

Tu preches un convaincu et mon vote t'es acquis. La facon dont je vois
les choses (et JPR commence a y venir a petit pas) est la suivante:
 1/ on parse l'entete du fichier, que l'on represente dans un gdcmHeader
    et qui contient donc le tag des pixels, le codage (ou compression),
    et les eventuelles valeurs ajoute'es LUT ou overlays ...
 2/ on interprete ce fichier pour une utilisation donne'e, comme
    gdcmImageData(), Write()...

Idealement ces deux etapes sont independantes. Le pb est que dans l'etat
actuel du code JPR modifie le gdcmHeader obtenu en fonction de l'action
demande'e. Quand deux (ou plusieurs) actions conflictuelles sont demande'es
successivement par l'utilisateur (par exemple,
   1/ je veux que les pixels en RGB,
   2/ je veux faire un write avec seulement le niveau de gris en laissant
      tomber la LUT,
   3/ je veux faire un write en mode "raw" avec un fichier initialement en
      jpeg),
il faut donc maintenir a chaque etape l'integrite' du gdcmHeader !

De nombreux bug proviennent actuellement d'incoherences d'etat entre
le gdcmHeader et l'action demande'e (le membre pixel_data peut tour
a tour contenir l'image noir et blanc d'origine, puis l'image RGB...).

Afin de regler ce bordel, Benoit Regrain et moi, etions donc en faveur de
ne JAMAIS TOUCHER le gdcmHeader obtenu apres parsing et de creer une
nouvelle classe, disons gdcmPixelData, contenant toutes les zones
temporaires necessaires aux multiples demandes d'un utilisateur
(les segments jpeg decompresses, l'image en RGB, l'image en RAW, you
 name it...)
Face a une nouvelle demande il suffit donc d'aller remplir les
membres de cette classe, si cela n'a pas deja ete fait !

Une des principales resistances a l'adoption de ce modele pard JPR, etait
que gdcmPixelData contient a l'instant T, des donne'es parfois gourmandes
en memoire et qui ne seront peut-etre plus utilise'es (c'est pourquoi
JPR recylce PixelData). A mon sens le surcout memoire est un soucis
mineur au regard des bugs induits par le poids d'une mauvaise
maintenance de la contrainte d'integrite (il faut savoir a tout moment
ce que contient PixelData, et eventuellement relire sur disque face a une
nouvelle demande). De plus cette maintenance de la contrainte d'integrite'
est repartie dans les actions du code (Write(), GetImageData()) et n'est
pas centralise'e...
A condition de rajouter une methode Squeeze() a gdcmPixelData (et en
laissant le soin a l'appelant de le gerer), JPR semblait (mais bon, il
ne cesse jamais de me surprendre) d'accord pour franchir le pas...
Sans doute a t'il croise' de nouveau bugs tenaces sur le chemin du
nettoyage du code...


	Frog.