[Dcmlib] recriture images

[Jean-Pierre Roux]

-->Re ecriture des images.
On avait considere jusqu'a present que l'utilisateur de gdcm *savait ce 
qu'il faisait*, modifiait les champs de la maniere coherente qu'il 
voulait, et qu'on écrivait l'entete dans l'etat ou il nous l'avait passee.

Dans la TestSuite, l'utilisateur de gdcm, c'est nous, et, naturellement 
(?) nous ne savons pas ce que nous faisons ...
Nous prenons les images, amenons en memoire entete + pixels, gdcm se 
charge de modifier le strict minimun de choses, pour signaler que 
l'image a ete decompressee, et c'est tout.

Pour ce qui est UID, c'est clair, on n'a pas a demander son avis a 
l'utilisateur.
Pour le reste ... ?

Dans le cas d'une copie image-image :
S'il n'a pas de SOPClass UID (vieil ACR-NEMA, ou image forgee), on 
considere que c'est une 'Secondary Capture'
S'il y en a une, on la copie, ainsi que le SOP Instance UID dans le 
sequence 0008,2112,
On garde le SOPClass UID tel qu'il est
On fabrique une SOPInstance UID (image)
On met 0008,0008 a DERIVED\PRIMARY
On garde 0008,0060 (Modality)  tel qu'il etait.
On met 0008,0012 et 0008,0012 a Date - Heure courante

Si l'utilisateur a modifie les Pixels -on ne peut pas le savoir- ca sera 
a lui :
- de mettre 'OT' dans Modality
- de mettre 'DERIVED\SECONDARY' dans 0008,0008 (Image Type; la VM est 
1-n, il pourra d'ailleurs mettre ce que bon lui semble, non?)

Pour le changement de SerieUID ?
L'utilisateur devrait pouvoir recuperer un UID (genere par gdcm), et 
pouvoir le passer au Writter en lui disant de l'utiliser -c'est le seul 
moyen pour lui de 'fabriquer' des series a partir d'images calculées ?- 
ou ne rien dire, et gdcm en genere un nouvel UID a chaque appel du Writer.

Pareil pour le StudyInstance UID. (seul moyen de pouvoir rattacher 
plusieurs Series au meme examen)

Commentaires?