[Dcmlib] Au sujet de OD_DEBUG_US-PAL-8-10x-echo.dcm

[Eric Boix]

	Salut Mathieu,

Tu m'avais soumis cette image qui n'est pas lue par gdcm (de'sole' mais
j'ai perdu le contexte sur sa provenance). Bref, son proble`me est
que gdcm ne trouve pas l'entete Dicom a l'adresse x80.

Voila ce que donne un fichier classique
(e.g.  od -A d -c ~/cvs/gdcmData/ACUSON-24-YBR_FULL_422-Jpeg_Baseline_1.dcm )

   0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
   *
   0000128   D   I   C   M 002  \0  \0  \0   U   L 004  \0   ¾  \0  \0  \0

soit un padding de 0, jusqu'au byte 128=x80 ou on trouve "DICM" et ensuite
on commence les tags (on voit la VR du premier "UL").

Or avec le fichier incrime' 
(e.g.  od -A d -c OD_DEBUG_US-PAL-8-10x-echo.dcm )
   0000000   0   0   0   0   0   0   0           \   0           \   0
   0000016       \   0           \   0           \   0           \   0
   *
   0000064       \   0           \   0  \n   *  \n   0   0   0   0   1   2
   0000080   8               D               I               C
   0000096   M       0   0   2           \   0           \   0           \
   0000112   0               U               L       0   0   4           \

Autrement dit, la chaine recherche'e "DICM" ne se trouve pas a x80 = 128.
Mais ce qui est bizarre, c'est que "DICM" se trouve bien dans le fichier
mais a l'offset x52=82 different ET ENCODE' SUR 4 BYTES i.e. on trouve en
hexa :
   x52 :    20 20 20 44 20 20 20 49 20 20 20 43 20 20 20 4d
                      D           I           C           M 
et accessoirement le "UL" est aussi present un peu plus loin et avec le
meme codage.

Heueu, il sort d'ou ce fichier !? C'est pas un write de gdcm, sur une
machine 64bits quand meme ? Si c'est le cas, y'a ratage de marche !

	Eric, aux paquerettes...