[Dcmlib] Yet another coup de gueule

[Benoit Regrain]

Hi,

C'est moi qu'ai fait ces fichiers... et j'ai envoyé un mail la dessus sur
la mailing list gdcm...


----- Original Message ----- 
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Mailing list gdcm" <dcmlib at creatis.insa-lyon.fr>
Sent: Wednesday, April 06, 2005 11:03 PM
Subject: [Dcmlib] Yet another coup de gueule


> Yo,
>
> Ok j'ai peut etre rater un episode., mais c'est quoi ces fichiers .tst 
> dans BaselineDicom ? Qu'est ce que ca contient ? On dirait un fichier raw.
Presque... les informations sur ce fichiers sont écrites dans la description 
de la
classe lisant ces fichiers (fichier TestAllReadCompareDicom.cxx)


> Enfin bon reprenons la problematique. BaselineDicom produisait des images 
> DICOM qui servaient plus tard de references. L'avantage c'est que ce 
> n'etait pas fixe et que la baseline pouvait etre regenere (ex: passage de 
> la lib jpeg bugger a la ijg+patch lossless). Autre avantage y'a 500Mo de 
> moins a telecharger qd on veut faire un dashboard gdcm (pauvre modem 56k).
Et le problème etait surtout : si une image est générée fausse et qu'on 
corrige le
problème... alors le test cassera jusqu'a ce que le responsable de la 
machine supprime
la baselineDicom... Et personnelement... je trouve ca chiant (pour rester 
poli).


> Maintenant on a part du principe que l'image generee est forcement bonne 
> (!!) et on la compare a l'image chargee. Je comprends l'avantage c'est 
> d'avoir une image de reference que quelqu'un a declaree bonne a un instant 
> t (d'ailleurs qui a fais ca?). Le probleme c'est que c'est faux. Certaines 
> images sont mal lues donc les fichiers tst sont faux. Bilan le test 
> nightly devient: verifier chaque nuit que l'on lis toujours aussi mal la 
> meme image...
Et si on considere les images .png ? la référence est-elle plus juste ?



> Maintenant mes questions sont, etait-ce vraiment util de faire ca ?
Oui, depuis longtemps on en parlait (entre nous à Creatis et sur la mailing 
list).
Sauf que personne n'avait eu le courage de le faire. Et le but premier... 
c'est
justement de résoudre le problème du BigEndian : Sait-on lire une image 
dicom
juste ? aussi bien sur little endian que sur big endian (il s'avère que 
non).

> Est-ce que ca n'aurait pas ete plus intelligent de creer un vrai format de 
> fichier (genre XML) pour permettre de sauver les chaines de caractere (les 
> nightly tests devrait verifier que toutes les nuits on lit bien le meme 
> nom de patient).
Ca aussi ca serait bien de le faire. Mais pour l'instant personne l'a fait.


> En gros j'aurais preferer que le temps passer a faire ca, soit plutot 
> passe :
> - a un dcmcheck (verifier les VM par ex),
> - regler les problemes de dciodvfy
> - Ou eventuellement eviter de peter encore une fois gdcm sur big endian !
Je ne considère pas avoir peter gdcm sur big endian, mais plutot ajouté un 
test
plus fiable sur big endian.


> (*) Accessoirement plutot que de faire une image RAW gigantique un algo 
> genre md5 aurait tres bien pu faire l'affaire...
Heuuuu... ca avait été testé en python, d'utiliser le md5 pour vérifier la 
signature
de l'image. Et bizarrement, on n'avait pas le même résultat sous windows et 
linux.
Maintenant, ecrire un algo de md5 qui donne un résultat identique sur chaque 
machine...
pourquoi pas. Mais faut le faire... A rajouter dans les TODO ;-)

Benoit