[Dcmlib] Yet another coup de gueule

[Benoit Regrain]

----- Original Message ----- 
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>
Cc: "Mailing list gdcm" <dcmlib at creatis.insa-lyon.fr>
Sent: Thursday, April 07, 2005 9:59 PM
Subject: Re: [Dcmlib] Yet another coup de gueule


>> Presque... les informations sur ce fichiers sont écrites dans la 
>> description de la
>> classe lisant ces fichiers (fichier TestAllReadCompareDicom.cxx)
>
> ok
>
>> 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).
>
> ok, je comprends.
>
>> Et si on considere les images .png ? la référence est-elle plus juste ?
>
> L'avantage des png c'est que je vois de suite quelle image DICOM on ne 
> sait pas lire. Bilan on a deux tests qui font exactement la meme chose...
Vi, mais les images png sont utilisée par VTK et de plus, on a un ShiftScale
sur les image (équivalent à celui fait lors de l'affichage) vers du 8bits... 
donc
on peut simplement garantir que l'affichage est identique sur deux 
machines...
pas que les données sources soient identiques ! ... malheureusement.

Le 1er problème qu'on a rencontré entre Windows et Linux, par la mise en
place de ce test, c'est que les résultat de conversions YBR => RGB ne 
donnaient
pas les mêmes résultats... dû à des arrondis différents entre les deux 
machines.
Il se peut que le problème soit identique avec mac... mais ce n'est qu'une 
supposition.
Un test simple pour vérifier ca, c'est de déplacer le ficher .tst et 
relancer le test sur l'image.
Le fichier est alors recréé. Ensuite, il ne reste plus qu'a comparer les 
données des 2 images
(la référence et l'image créée)... sous linux, je l'avais fait avec hexdump 
sur les deux fichiers
suivi d'un diff. Tous les octets différents avaient une différence de 1.



>
>> 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).
>
> Ben pour moi gdcm 1.0 est plutot robuste, et je pense bien que ca lis 
> aussi bien en big endian little endian. Je rajouter un night gdcm 1.0 sur 
> la machine MacOSX -ca va etre chaud pour synchrnoniser gdcmData-
Perso j'ai un doute sur la bonne lecture du big endian... car avant on 
testait
sur une image réécrite. Et les tests VTK ne sont jamais bien passés... ceux
qui testaient par rapport à des images de référence.


>> Ca aussi ca serait bien de le faire. Mais pour l'instant personne l'a 
>> fait.
>
> ...
>
>> Je ne considère pas avoir peter gdcm sur big endian, mais plutot ajouté 
>> un test
>> plus fiable sur big endian.
>
> J'ai jeter un oeil au dashboard et il est plutot rouge sur mac...
Cela a toujours été le cas... on attend d'avoir une machine Mac ici pour
enfin pouvoir comprendre réellement le problème. En attendant c'est plutot
difficile.



>> 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 ;-)
>
> ouch ! Justement je comptais reutiliser un lib existente au pire faire un 
> ifdef sur Win32 sur md5 existe pas. C'est pas possible de faire une liste 
> de md5sum pour *nix et une pour win32 ?
Je pense que la bonne solution serait de recoder un md5... ou alors de 
trouver
une lib qui donne un md5 identique sur les 3 machines.
Je n'ai jamais compris la différence entre un md5 linux ou windows
(en passant par python)... théoriquement, ca aurait dû donner les mêmes
résultats. Des tests sont peut-etre à refaire pour vérifier tout ca...

Benoit