[Dcmlib] Emulation big endian

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

> Jean-Pierre ROUX wrote:
>
>>> Mathieu Malaterre wrote:
>>>
>>>> Salut,
>>>>
>>>>   Je suis en train de me demander si c'est veritablement possible 
>>>> d'emuler big endian sur little endian.
>>>>
>>>>   Dans ma test, on charge l'image en memoire en restant en little 
>>>> endian, donc jusque la c'est censer marcher. Mais au moment de 
>>>> l'ecriture seulement on ecris tout en big endian. En theorie ca 
>>>> devrait bien marcher non ?
>>>>
>>>>   Dans les choses que ne sont pas censer marcher c'est le group 
>>>> 0002 qui doit etre toujours en little endian. Pour l'instant ca 
>>>> marche vu que sur Mac lors de l'ecriture on swap tout (je n'ai pas 
>>>> reussi a trouver dans le source gdcm ou on traitait le cas de 0002 
>>>> et little endian...)
>>>
>>
>>
>> Le pb de l'ecriture du groupe 0002 (qui doit toujours etre Little 
>> Endian, meme lorsque la Transfer Syntax est Big Endian) a été zappé :-(.
>>
>> Vu :
>> - qu'on sait lire tous les types d'images sur tous les types de 
>> processeurs
>> - qu'on sait ecrire proprement les images en Little Endian, même sur 
>> des processeurs Big Endian,
>> - que Little Endian est le format recommande par DICOM, et ce que 
>> cette recomandation est maintenant suivie par a peu pres tout le monde
>> - que tous les Dicom Readers du commerce savent lire a la fois le Big 
>> Endian et le Little Endian
>>
>> Je pense que ca ne generait aucun utilisateur si on disait 'gdcm 
>> ecrit seulement en Little Endian'
>
>
> Ok, plusieurs choses:
>
> - Je ne crois absolument pas qu'en restreignant les features de gdcm 
> on va eliminer des bugs: faux et archi faux. Il vaut mieux ecrire 
> plus/mieux des tests.
>
> - JP tu dis dans ton message que gdcm c'est lire du Big Endian, 
> vraiment ? Dans ce cas ca serait pas mal de le tester via gdcm, non :)

Si on fait un
grep Big
sur la sortie de ctest -V pour TestPrintAllDocument, on obtient ca :

/home/jpr/gdcmCurr/gdcmData/XA_GE_DLX_xadc.dcm TransferSyntaxName= 
[Implicit VR Big Endian DLX (G.E Private)] SwapCode = 1234 
PhotometricInterpretation=MONOCHROME2  pixelType=8U SamplesPerPixel=1 
PlanarConfiguration=0

/home/jpr/gdcmCurr/gdcmData/US-RGB-8-epicard.dcm TransferSyntaxName= 
[Explicit VR - Big Endian] SwapCode = 4321 
PhotometricInterpretation=RGB  pixelType=8U SamplesPerPixel=3 
PlanarConfiguration=1

/home/jpr/gdcmCurr/gdcmData/GE_DLX-8-MONO2-PrivateSyntax.dcm 
TransferSyntaxName= [Implicit VR Big Endian DLX (G.E Private)] SwapCode 
= 1234 PhotometricInterpretation=MONOCHROME2  pixelType=8U 
SamplesPerPixel=1 PlanarConfiguration=0
 
3 images BigEndian (dont 2 GE, mais qui n'ont d'autre particularite que 
d'etre en IMPLICIT Big, qui n'existe pas dans DICOM, le diable seul sait 
pourquoi ...), et qui passent
Ceci dit, ca serait bien d'avoir d'autre images Big Endian, car j'ai un 
serieux doute sur leur caractere Kasher ...

Si tu regardes le contenu avec hexedit, le groupe des pixels est ecrit 
une fois comme 7F E0, une autre fois comme E0  7F.
Forcement l'une des deux est fausse...
Et comme gdcm fait toutes sortes de contorsions pour s'en sortir 
lorsqu'il y a des trucs douteux, on peut penser que si on se vautre a 
l'ecriture, on va recuperer le coup lors de la leccture, et qu'on ne 
verra que du feu ...

Pourrais-tu nous envoyrer qq images ecrites par gdcm sur MacOS.
Thx
JPRx


> D'ou le 2eme interet (et c'est mon point). On devrait etre capable de 
> generer des images DICOM qui nous servirait d'input au lieu d'attendre 
> que qlq nous envoie l'image en disant : "je comprends pas mon image 
> passe pas dans gdcm, elle est en Big Endian...". Non seulement on tord 
> le coup avant de recevoir l'image en question, mais en plus on evite 
> d'exploser la taille de gdcmData.

> Derniere argument, sans doute beaucoup moindre c'est effectivement 
> -entre autre- le GE Private special full feature.

Pour le coup, si on sait generer proprement de l'Explicit Big Endian sur 
toutes les plateformes, ca sera un vrai plaisir de generer *egalement* 
de l'Implicit Big  (l'ecriture ou non de la VR n'a jamais pose de pb)

>
> Limiter les features de gdcm, pour moi c'est un defaut d'architecture 
> de gdcm...
>
> Enfin sinon pour trancher la poire en deux, je vois pas pourquoi les 
> dev ne pourrait pas generer du Big Endian. Meme si gdcm ne supporte 
> officielemtn que l'ecriture de little endian
>
> My 2 cents
> Mathieu
>