[Dcmlib] gdcmHeaderHelper

[Jean-Pierre Roux]

Quoting Mathieu Malaterre <Mathieu.Malaterre at creatis.insa-lyon.fr>:

> Finalement je reviens sur ma decision. Est-ce qu'on ne peut pas partir 
> de la fin ?
> 

Le seul moyen de savoir *ou* se trouve un champ DICOM, (que ca soit le nombre de
lignes de l'image, le nom du Patient, le champs des pixels, ou le premier champ
qui suit les pixels), c'est de parser l'entete.

*Tous* les champs ont une longueur variable (si on peut penser que la longueur
du nom du Patient ne varie pas d'une image à l'autre dans une serie donnée, la
longueur du numéro de l'image peut varier).

J'avais fait un executable Libido, de nom 'offset', qui s'utilisait en se
mettant dans le directory des images, et en lancant la commande, a l'usage des
toubibs qui avaient des softs qui demanadaient un nom de fichier, et un offset.
Meme en ACR-NEMA, ca pouvait varier, alors que le champ 7FE0 etait *forcement*
le dernier.
En Dicom, c'est encore pire.

L'entete et les données ne sont pas entrelacées (sauf en ce qui concerne les
images Jpeg, dans le cas des 'multifragments', où le debut de chaque fragement
est flagg-é par un tag dicom de 'debut d'element', et le dernier est flagg-é
comme une 'fin de serie'.
Il faut aller a la peche a ligne pour lancer la decompression.


Bon .
Il faudrait que je commite tout ce qui traite ça.
--> Benoit : est-ce que je peux passer demain matin a creatis. Je voudrais
m'assurer que ce qui marche sur mon PC (lecture, ecriture et re-lecture des
fichiers de gdcmData) marche *egalement* sur Tux.

Merci

 



> Apres avoir lu la première image, est-ce que l'on a suffisament d'info 
> pour savoir ou les données sont placées dans le fichier ?
> 
> Algo:
> - lire 1ere image
> - determiné la taille des données (en octets)
> - pour 2...n
>      fseek( taille_fichier - taille_données )
>      lire les pixels
> 
> ?? Est-ce qu'un expert dicom peut confirmé ? Le problème est de savoir si:
> 
> - Est-ce que l'entete et les données sont physiquement distinct/entrelacée
> - Si il y a des 'restes' d'entete à la fin du fichier, est-ce que ceux 
> la ont une taille constante :
> 
>      fseek( taille_fichier - taille_données - taille_entete_constant )
> 
> Merci
> mathieu
> 
> Emmanuel Olart wrote:
> > D'autant plus qu il n y a pas que les ID qui bougent, mais également les
> > champs de type
> > 
> > Image position ( XXX //XXX //XXX) c'est codé en chaine de caractere et
> varie
> > pour chaque image
> > Slice location ...
> > 
> > en fait tous les champs spécifiques à une image, sa représentation, sa
> > position dans l 'espace, varient.
> > Fodrait une sacré Heuristique pour ne pas se planter en lisant
> directement
> > les data ^^ :)
> > 
> > Dommage ca aurait pu etre super rapide.
> > 
> > Manu
> > 
> > ----- Original Message -----
> > From: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>
> > To: "Mathieu Malaterre" <Mathieu.Malaterre at creatis.insa-lyon.fr>
> > Cc: <dcmlib at creatis.insa-lyon.fr>
> > Sent: Tuesday, July 22, 2003 12:42 PM
> > Subject: Re: [Dcmlib] gdcmHeaderHelper
> > 
> > 
> > 
> >>----- Original Message -----
> >>From: "Mathieu Malaterre" <Mathieu.Malaterre at creatis.insa-lyon.fr>
> >>To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>
> >>Cc: <dcmlib at creatis.insa-lyon.fr>
> >>Sent: Tuesday, July 22, 2003 12:21 PM
> >>Subject: Re: [Dcmlib] gdcmHeaderHelper
> >>
> >>
> >>
> >>>>Ceci est vraiment un cas trop particulier pour être ajouté à une
> >>
> >>librairie.
> >>
> >>>>Meme si
> >>>>ca peut représenter une majeure partie de son utilisation.
> >>>>
> >>>>Ou alors, en classe spécifique... mais je me pose quand meme quelques
> >>>>questions :
> >>>> - est tu sur et certain que la taille de toutes les chaines de
> >>
> >>caractere
> >>
> >>>>contenues dans
> >>>>    les fichiers parsé sont exactement de meme taille ?
> > 
> > personnellement,
> > 
> >>>>j'en doute...
> >>>>    surtout que les id d'image sont je crois décris en chaine de
> >>
> >>caracteres.
> >>
> >>>> - et si les chaines de caracteres ne sont pas toutes de meme taille,
> >>>>comment va tu
> >>>>   faire pour résoudre ce problème ?
> >>>> - et pour les champs privés, liés au constructeur de l'imageur ? est
> > 
> > tu
> > 
> >>sur
> >>
> >>>>et certain
> >>>>   que tous ces champs soient toujours de meme taille ?
> >>>>Si tu peux me garantir tout ca, alors faire une classe spécifique pour
> >>>>charger les images
> >>>>d'une meme série provenant d'un meme imageur est possible.
> >>>>Sinon, c'est lié à ton programme et doit être implanté dans ton
> >>
> >>programme
> >>
> >>>>(en dérivant
> >>>>peut-etre de gdcm si c'est nécessaire pour toi).
> >>>
> >>>
> >>>Tiens c'est vrai que les chaines de caractères doivent changer. Je
> >>>pensais que dans une study+serie donnée les chaines étaient les
> >>>memes...sauf que l'UID est augmentée d'une image à l'autre.
> >>>Typiquement:
> >>>
> >>>123.456.789.1
> >>>123.456.789.2
> >>>...
> >>>123.456.789.9
> >>>123.456.789.10
> >>>             ^^
> >>>
> >>>Je me fais avoir !!
> >>>Merci d'avoir soulevé le problème
> >>
> >>De rien, ce fut un plaisir ;-p
> >>
> >>Benoit
> >>
> >>_______________________________________________
> >>Dcmlib mailing list
> >>Dcmlib at creatis.insa-lyon.fr
> >>http://www.creatis.insa-lyon.fr/public/mailman/listinfo/dcmlib
> >>
> > 
> > 
> > 
> 
> 
> -- 
> Mathieu Malaterre
> CREATIS
> 28 Avenue du Doyen LEPINE
> B.P. Lyon-Montchat
> 69394 Lyon Cedex 03
> http://www.creatis.insa-lyon.fr/~malaterre/
> 
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/public/mailman/listinfo/dcmlib
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/