[Dcmlib] GE_RHAPSODE-16-MONO2-JPEG-Fragments.dcm

[Jean-Pierre Roux]

jean-michel.rouet at philips.com wrote:

>On 15/12/2004 14:26:05 Jean-Pierre Roux wrote:
>  
>
>>La seule solution qui reste est 'Pas de format' --> image RAW (pixels,
>>sans entete)
>>Lors des tests, on lit, dans l'entete DICOM de chaque image nbLignes,
>>nbColonnes, etc, on se sert de ces valeurs pour lire les Pixels de
>>l'image RAW, que l'on peut ensuite comparer avec les expanded Pixels que
>>nous a fourni la lecture courante de l'image DICOM.
>>
>>    
>>
>
>Pour continuer la discussion, pourquoi ne pas stocker dans BaselineDicom 
>les images raw créées par un dicomreader tiers (dcmtk par exemple).
>  
>
C'est ce que je proposais.
Toutefois, dcmtk est loin de lire autant de 'dicom exotiques' que gdcm.
Le fichier RAW pourrait etre fabrique, une fois pour toutes, avec gdcm 
(des que l'on 'sait' qu'une nouvelle image est lue correctement, on 
fabrique le fichier RAW, on le stocke, et on n'y touche plus jamais)

>Stocker les dimensions de l'image raw a l'aide d'un entete ou d'un fichier 
>de description séparé peux etre utile egalement car discriminant.
>  
>
Pour eviter de 'trainer' un fichier d'entete en plus, je suggerais de 
prendre NX, NY, nbFrames, nbBits, etc, dans le Header de l'image DICOM 
(il n'y a maintenant plus de risque que ces valeurs soient rammenées 
avec une valeur erronnée par gdcm)
Mais il n'y a pas d'objection methodologique (ni inconvenient, ni 
avantage) a ajouter un fichier d'entete.

JPRx

>just my 2 cents.
>
>JM
>
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>
>  
>