[Dcmlib] TestChangeHeader

[Mathieu Malaterre]

> C'etait un pb general sur tous les champs 'entiers', multivalues.
> A part Matrix Aquisition, on ne doit pas en avoir d'autre dans gdcmData ...

parfait, je croise les doigts qd meme ;P

> Pour qu'il y ai 'unkn', il faut que l'image soit en Implicit Value
> Representation et que le champ soit privé.
> Dans le cas, on n'est meme pas sur d'avoir ammene la valeur correctement
> en mémoire (et on n'a aucune moyen de le savoir).

Euh, en anglais ca donne quoi ? Plus serieusement, qu'est ce que ca veut
dire implicit value ?

> En l'absence de Dictionnaire DICOM prive fourni par l'utilisateur,
> (c'etait prévu, mais on n'en a jamais eu) on ne peut rien faire avec ce
> champ.

cf mail precedent.

> Lorsque la valeur est 'gdcm::Binary data loaded with length is xxx' (la
> syntaxe du message n'est pas de moi), c'est que l'on a a faire a une
> variete particuliere de gdcmDocEntry, a savoir un gdcmBinEntry (qui est
> lui meme un cas particulier de gdcmValEntry)
> La valeur 'Binaire' (c'est a dire non convertie, pour des raison de
> convenances personnelles en std::string) se trouve dans le champ protected
> VoidArea.
> On peut recuperer un pointeur sur lui par gdcmBinEntry:: GetVoidArea().
> 
> La methode Write est supposee prendre ca en charge.

ok,

> Est-ce qu'il faut que je les concerve pour les ecrire plus tard ?
> Comment 'charger' celles qui sont 'NOT loaded' ?
> 
> Il manque effectivement une methode privee "ForceLoad", qui serait
> appellee en interne au moment du Write, qui ouvrirait de nouveau le
> fichier et qui ferait des fseek + fread pour charger tout ce qui est Not
> Loaded (et peut etre aussi une methode publique SetForceLoad qui permetra
> de dire a l'utilisateur s'il veut forcer le chargement, ou bien laisser
> tomber)
> Il faudrait peut etre aussi des accesseurs pour dire si on veut, a
> l'ecriture, laisser tomber *tous* les champs prives, ou laisser tomber les
> Sequences (gdcmSeqEntry).


D'apres Eric, si c'est possible, avec gdcmDocument::SetMaxSizeLoadEntry(
A_FOND_A_FOND)

> Je suis en train de me tirer des plombs sur ... la lecture :
> Actuellement, lorsque l'utilisateur fait un GetImageData sur une image
> contenant une LUT, on tranfsorme automatiquement l'image en RGB, et on
> modifie l'entete pour qu'elle soit coherente avec les pixels en memoire.
> Si l'utilisateur fait, juste apres, un GetImageDataRaw, pour recuperer les
> pixels 'gray level' + la LUT, ca pete, car le header ainsi modifie n'est
> plus coherent avec le fichier sur disque.
> Le pb etait connu, on ne l'a jamais eu (mais il suffirait d'ecrire le
> 'bon' programme pour l'avoir ...)


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 ?

> Je crois que je vais mettre ca entre parentheses pour traiter les 'Not
> Loaded' , ca a l'air + urgent.

ca marche

Mathieu