[Dcmlib] [Fwd: the ultimate dicom reader fight]

[Mathieu Malaterre]

Juste pour etre consistant est-ce que vous pouvez essayer ITK-gdcm pour 
lire les images et et faire un print image->GetScalarRange();

gdcm n'applique pas le Modality LUT, donc slope et intercept sont 
ignores. Mais c'est fais au niveau de ITK.

@+
-M
Ps: si j'avais access au images en question je pourrais repondre de 
maniere plus sur, mais pour l'instant c'est le seul probleme que 
j'envisage...

Jean-Pierre Roux wrote:
> Emmanuel Olart wrote:
> 
>> Salut Vous !
>> Voici une petite colle pour vous.
>>
>> Pour nos besoins internes on est en train de valider gdcm (comme je te 
>> l avais dit) et on tombe sur quelques curiosités avec certaines images 
>> (surtout des philips)
>> On compare les valeurs lues dans les headers par gdcm d'une part, et 
>> dcmtk d'autre part (on savait pas trop choisir comme gold standard, on 
>> s'est dit pkoi pas lui).
>> On compare également les images data qu'on recupere.
>> Outre le fait que dcmtk est un enfer a utiliser (et je pese mes mots), 
>> on a fini par extraire les valeurs des image data par les deux methodes.
>> On les compare sur 150 series tests (un peu tous les imageurs qu'on a 
>> pu trouver) et on regarde ce qui match / match pas.
>>
>> Dans le cas des images ci jointes, on a des différentes tres 
>> importantes dans les valeurs d'intensité des pixels qu'on récupere.
>> - gdcm nous donne en gros des valeurs entre 0 et 500
>> - dcmtk entre 0 et 3500
> 
> OK;
> On a de la chance : les images ne sont pas compressées, elles sont 
> LittleEndian et mon PC aussi, elles sont MONOCHROME2 (0, c'est noir, 
> 4095, c'est blanc ...)
> J'ai fait un programme de bourricot, qui saute (fseek) l'entete, avec la 
> taille que me montre PrintFile filein= TOF-MRA_93_0051 level=2  (8454) 
> et qui fait des read, 2 octets a la fois, et  calcule le max.
> Je retrouve la meme valeur que gdcm (441).
> Ou alors, un coup d'editeur hexadecimal sur l'image, et tu recherches 
> (au traitement de texte) BB (car 3003 en base 10, ca fait BBB en base 16.
> 
> Any comment?
> JP
> 
>>
>> on a regardé efilm pour arbitrer : il est ok avec gdcm
>> on a regardé avec la librairie de Leads : elle penche pour dcmtk
>> Avez vous une idée quelquonque de pourquoi on trouve de telles 
>> différences ? Interprétation des data ? LUT ? encodage ?
>> Au niveau des headers, ca colle globalement, a qques espaces et \0 prets.
>>
>> Merci d'avance !
>>
>> Manu
>>
>> -------- Message original --------
>> Sujet:     the ultimate dicom reader fight
>> Date:     Thu, 07 Dec 2006 17:19:37 +0100
>> De:     Nicolas Villetard <nvilletard at theralys.com>
>> Pour:     Emmanuel Olart <eolart at theralys.com>
>>
>>
>>
>>
>> TOF-MRA_93_0051
>> gdcm, efilm: valeur max = 441
>> dcmtk, LEADS medical imaging: valeur max = 3003
>>
>> 3DT1_88_0074
>> gdcm, efilm: valeur max = 492
>> dcmtk, LEADS medical imaging: valeur max = 2253
>>
>> diantre!
>>
>> -- 
>>
>> Nicolas Villetard.
>> Quality Assurance & Regulatory Affairs
>>
>> *THERALYS*
>> Diagnostic & Therapeutic Image Analysis in Clinical Trials
>>
>> Address :
>>
>>     
>>
>> THERALYS
>> 60 avenue Rockefeller
>> 69008 Lyon (France)
>>
>> Phone :
>>
>>     
>>
>> +33 (0)4 26 23 05 05
>>
>> Fax :
>>
>>     
>>
>> +33 (0)4 26 23 05 06
>>
>> Email :
>>
>>     
>>
>> nvilletard at theralys.com <mailto:nvilletard at theralys.com>
>>
>> Web site:
>>
>>     
>>
>> www.theralys.com <http://www.theralys.com>
>>
>>
>> -- 
>> Emmanuel OLART, IT Manager
>> *THERALYS*
>> Diagnostic & Therapeutic Image Analysis in Clinical Trials
>>
>> Address : Bioparc, 60 av. Rockefeller, 69008 Lyon, France
>> +33 (0)4 26 23 05 05 (Phone)
>> +33 (0)4 26 23 05 06 (Fax)
>> Email : eolart at theralys.com <mailto:eolart at theralys.com>
>> THERALYS <http://www.theralys.com/>
> 
>