[Dcmlib] Ecriture DICOM sur Big Endian

[Jean-Pierre ROUX]

At 18:33 -0500 10/01/05, Mathieu Malaterre wrote:
>Mathieu Malaterre wrote:
>>Ok,
>>
>>  J'y vois plus clair. Les problemes obscurs sur MacOSX sont 
>>regles. Je passe donc au probleme d'ecriture sur Big Endian. Qui a 
>>mon avis n'a pas du tout ete traite.
>>
>>   Ma question est qu'est ce qu'il vaut mieux :
>>- Ecrire l'entete en declarant l'image little endian, puis swap 
>>l'enorme image buffer en little endian.
>>
>>- Soit modifier l'entete DICOM pour dire que l'on est effectivement 
>>sur big endian et dans ce cas pas besoin de reswaper le buffer 
>>avant ecriture.

C'est la deuxieme option que j'avais prise dans la version 'été 2003' 
(pour des raisons de rapidité a l'execution)
Ca faisait des images relisibles ... par gdcm.

En fait, pour une 'vraie' image DICOM Explicit Big Endian, le groupe 
0002 doit etre ecrit imperativement en little-endian, et le reste en 
big-endian
C'est pour cela que le group 0002 est le seul dont l'element 0000 
(group length) soit obligatoire.

Et, faute d'avoir eu entre les mains une 'vraie' image DICOM 
big-endian, on a completement zappe ce problème, et on est assures 
que la version actuelle de gdcm petera lorsqu'on aura une image DICOM 
big-endian (pour les images ACR-NEMA, il n'y pas de pb).

En effet, on ne teste jamais la 'Transfert Syntax' pour des pb 
d'endiannity.On se contente de 'deviner', en examinant le debut de 
l'entete, si l'image est compatible avec le processeur, ou s'il faut 
swapper les int16 et les int32 (on positionne alors le SwapCode).

Dans le cas d'une 'vraie' image DICOM Big Endian, la conclusion qu'on 
tirera de cas sera vraie pour le group 0002, et fausse pour tous les 
autres.

Pour corriger ca, il faudra, *lors du parsing* d'une 'vraie' image 
DICOM, aussitot que le groupe lu n'est plus 0002, tester la Transfert 
Syntax, et, si c'est 'Big Endian', changer le SwapCode, dont la 
valeur donnée par l'heuristique est desormais fausse, à coup sur.
Et on n'a donc plus besoin de ma methode 'IsCurrentProcessorBigEndEndian'.

Voila.
J'ai bien fait de prendre un peu de temps pour t'expliquer le pb.
Ca m'a eclairci les idées.
Tout ca est bien plus simple que ce que j'avais commence a ecrire 
(s'arreter de lire lorsque la longueur du group 0002 est atteinte, 
comparer la Transfert Syntax a l'endiannity du processeur, etc)
Je commiterai ca demain matin (enfin ... tout a l'heure).


Le probleme de l'ecriture en Big Endian va etre + simple que ce qu'on 
pouvait craindre :
Il suffit d'ecrire le group 0002 (et celui ci seulement) en faisant 
le contraire de ce qu'on avait prévu de faire, et de continuer 
'normalement' pour le reste de l'image.

Pour la lecture des fichiers ACR-NEMA, il n'y a pas de problème : la 
norme disait que c'etait *imperativement* du little-endian; personne 
ne se sentait tenu de la respecter; les images n'etaient pas 
relisibles d'un constructeur a l'autre; l'heuristique marchait tres 
bien, tout le temps ....


JP

>
>En fait la question se pose pas. Les deux sont parfaitement valable. 
>Je fais les deux donc.
>
>Ca serait pas mal une function dans gdcmTS qui a une syntax little 
>endian me renvoi l'equivalente big endian.
>
>Mathieu
>
>
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib

  Jean-Pierre ROUX
  UMR CNRS 5515-CREATIS
  Laboratoire de Radiologie Experimentale
  Hopital Cardiologique
  28 Avenue du Doyen LEPINE
  B.P. Lyon-Montchat
  69394 Lyon Cedex 03

  Tel      : (+33) 04 72 35 74 12
  Fax      : (+33) 04 72 68 49 16
  URL      : http://www.creatis.univ-lyon1.fr
  e-mail   : jpr at creatis.univ-lyon1.fr