[Dcmlib] gdcm proposal

[Mathieu Malaterre]

> J'ai l'impression que decris la situation  'gdcm-Juillet 2004' ...
> L'ecriture d'un fichier provoquait'en douce' la modif de certains champs 
> (comme ce que tu décrits), ce qui fait qu'effectivement un Print() 
> n'aurait pas eu le même output avant et pares l'ecrire du fichier.


Alors c'est quoi ca:

bool File::Write(std::string fileName, FileType writetype)
...
    // Bits Allocated
    if ( GetEntryValue(0x0028,0x0100) ==  "12")
    {
       SetValEntry("16", 0x0028,0x0100);
    }
...



> Ce n'est plus le cas actuellement, et j'ai l'impression que le 
> 'dictionaire dont les valeurs se baseraient sur gdcm.Image (et 
> ecraseraient celles de l'input)', il y a deja le 'Archive' qu'a ecrit 
> Benoit il y a plusieurs mois, qui fait ca.
> Me trompe-je?


ben je suis pas convaincu. Il y a enormement de logique complique (je 
reconnais sans probleme que je ne comprends pas) pour essayer de support 
le format ACR NEMA / Libidi / Papyruss: pour moi ca doit etre 
externaliser dans un dictionnaire.  Par exemple il n'y pas pas de notion 
de dictionaire qd on un image DICOM. Notre approche pour trouver le 
spacing c'est ben on essai DICOM V3, puis ACR NEMA puis d'autre champs 
selon l'humeur. Non c'est faux, une image est lu par rapport a un 
dictionaire. Si l'image ne respecte pas le dict: c'est que notre 
heurisitque pour determiner le format est foireuse soit l'image est 
foireuse et dans ce cas il faut un warning.

Pareil pour les Serie, j'aimerais qu'on fasse la difference entre un 
gdcm::SerieWriter et un gdcm::Writer. Le premier ecris une serie le 
second ecris une image. Donc en bonne logique pour ecrire SerieWriter on 
ecris  proprelemt gdcm::Writer et on fait un loop sur la derniere 
coordonnees (ca permet par exemple d'ecrire une serie d'image 3D ...)



> J'avais proposé, en son temps, de faire un 'Check Header'qu'on aurait 
> lancé juste avant d'écrire, et puis laissé tomber l'idée :
> Si, lors du Test Write Dicom (ou l'on prend tous les champs, un par un, 
> pour faire un nouveau 'gdcm::Document'), on trouve une VM qui n'est pas 
> bonne, que fait-on? On refuse d'écrire le fichier, alors qu'il aurait 
> été la copie conforme d'un fichier Siemens, par exemple?


C'est pour ca que je fais une difference entre un gdcmWriter et un 
gdcmValidator. Le premier ecris ce qu'on lui donne (donc dans le cas 
Siemens il gardera le bug dans la chaine de caractere). Mais on laisse 
la chance a un utilsateur de lire l'image, de la valider PUIS de 
l'ecrire. Les roles sont completement independant.

> Quant aux champs de type 1, 1C, 2, 2C, 3, vu que leur type varie selon 
> la modalité (et que les constructeurs ne le respectent pas), ca ferait 
> de la programmation kilometrique, pour, probablement pas grand-chose.

Je vois pas de quoi tu parles ? C'est quoi ces champs ?




Je suis toujours sur la retenue qd quelqu'un lance qu'il veut reinventer 
la roue, mais je reste persuade qu'il a des choix dans gdcm: que soit je 
ne comprends vraiment pas soit que sont -IMHO- sont mauvais voire faux. 
Je n'ai pas passer bcp de temps a explorer l'implementation si ca ce 
trouve il y a bcp de similitudes (plus que je ne pense peutr etr). Dans 
tous les cas ca reste plus un sondage d'opinion qu'autre chose vu que je 
n'ai en ce moment pas du tout de temps a consacrer a yet another dicom 
library...

Mathieu