[Dcmlib] gdcm proposal (2)

[Benoit Regrain]

----- Original Message ----- 
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>
Cc: "Mailing list gdcm" <dcmlib at creatis.insa-lyon.fr>
Sent: Friday, April 29, 2005 5:20 PM
Subject: Re: [Dcmlib] gdcm proposal (2)


>
>> Un SeqEntry contient des SQItem qui sont eux des pseudo Document...
>> En fait, dans la structure actuelle, un SQItem et un Document derivent de
>> ElementSet. Deux points les différencie :
>>  - dans le Document, on stoque les entry dans une map (pour des questions
>> de rapidité) et dans les SQItem on y stoque dans une liste (car moins 
>> gourmande
>> en place).
>
> Comprends pas ? Pourquoi la liste ? Si je manipule des image GE et j'ai a 
> tout pris besoin d'acceder au Tag bidule, machin (mais je sais pas dans 
> quel SeqEntry c'est). Comment je fais ? Je veux mon acces en O(1) et pas 
> que sur le toplevel...
Une SeqEntry contient des SQItem. Chaque SQItem contient les memes tag
et le meme nombre de tag (normalement) Donc si tu veux accéder au Tag
bidule, il est normalement dans tous les SQItem du SeqEntry. Maintenant,
c'est vrai que dans le SQItem on a mis des listes et non pas des map... ceci
diminue la rapidité d'accès. Mais ca peut etre changé ;-)


> >  - dans un Document (ou plutot un File), on a des méthodes
> supplémentaires
> > pour acceder aux caractéristiques du Document.
>
> ces acces supplementaires n'existe pas chez moi. C'est le 
> gdcm.ImageInterpreter qui produit une gdcm.Image. Si je veux le spacing 
> d'une DICOM je le recupere sur l'image, tant pis. Si je veux pas creer une 
> image mais que je veux mon spacing et que j'ai peux que le spacing sois 
> tout pourri (contient 3 float), je fais:
>
> reader = Reader
> reader.SetFileName
> reader.SetSkipMode(bla)
> reader.Read()
>
> inter = gdcm.ImageInterpreter
> inter.SetInput(reader.GetOutput())
> inter.ExecuteInformation()  # je ne lis pas les heavy data
> inter.GetOutput().GetSpacing()
>
> print inter.GetOutput().GetRawImage() -> seg fault car image non chargee
Ou alors avoir un ImageInterpreterLight (nom à revoir) dont deriverait le
ImageInterpreter


>> La distinction BinEntry / ValEntry se fait en fonction de la VR. Pour un 
>> BinEntry,
>> par exemple les pixels de l'image ou d'autres données, y stoquer dans une 
>> stream
>> n'aurait pas vraiment de sens... et quel en serait reelement l'intérêt ?
>
> ok on tourne en rond. Faut que j'approfondice pourquoi y'a besoin de cette 
> VR dans les deux cas Explicit/Implicit...
oki


>> Moui, c'est une excuse tout à fait valable... A étudier. Mais ca ne 
>> resoudrait pas
>> le problème des SeqEntry. Il faudra de toute manière faire le travail 
>> pour lui.
>> Par contre, il est clair que la transformation en chaine du ValEntry est 
>> un peu
>> lourde. Je pense qu'il manquerait meme une classe qui genere les 
>> NumberEntry
>> Ainsi on supprimerait les parsing de chaine de caractères pour au final 
>> obtenir les
>> nombres. Les transformation number->string et string->number sont a mon 
>> avis
>> plutot couteuses en temps.
>>  On pourrait avoir une structure de DocEntry comme suit :
>> DocEntry (existe deja)
>>  - SeqEntry (existe deja)
>>  - ContentEntry (existe deja)
>>     - ValEtnry (pour tout ce qui est chaine)
>>     - BinEntry (pour tout ce qui est donnée non interpretable)
>>     - NumberEntry (pour tout ce qui est nombre)
>> mais ca ne résout pas le problème de passage d'un BinEntry lorsqu'on a un 
>> ShadowDict
>> et qu'on est en ImplicitVR (car pour le ExplicitVR, on n'a pas de 
>> problèmes).
>> Mais avec les ShadowDict, il reste le problème du SeqEntry... car il se 
>> peut qu'on ne
>> sache pas qu'on a une SeqEntry à un moment (car son groupe est privé)... 
>> ce qui
>> d'ailleurs m'interpelle un peu, car l'élément suivant d'un SeqEntry 
>> serait un SQItem... et
>> on devrait pouvoir le repérer lui... na ? JPR, toi qui connait tout de 
>> Dicom, qu'en penses tu ?
>
> je suis perdu... comprends pas...
Ha ben j'ai noyé le poisson dans la marre... je fais un doc sur 
l'explication de tout
ca a coté.


>> En ExplicitVR, on peut avoir des Entry dont la VR diffère de la VR du 
>> dictonnaire.
>> C'est dans la norme Dicom ca (enfin a verifer avec JPR)
> C'est vrai ca ? ou c'est encore les cas d'image philips avec 'feature' ?
Je ne crois pas que ca a à voir avec Philips. Je ne connais pas la nome par 
coeur,
mais il me semble avoir parlé avec JPR de ca.



>> Mais comment savoir lors de la lecture d'un fichier à quel constructeur 
>> il
>> appartient pour ensuite prendre le bon ShadowDict...
>
> gdcm n'est pas en charge d'ajouter les ShadowDict au demarrage. En 
> pratique l'utilisateur sait exactement quel constructeur il a et sait 
> exactement quel tag il veut. Il ajoute donc le bon dictionaire, et en 
> theorie tous les tag sont unique (par rapport au public dist).
La théorie est belle, mais en pratique, quand je vois les logiciels comme 
Maracas
ou CreaTools... ils ne savent pas forcément d'ou viennent les images.

> Dans le cas du neuneu de base qui ne sait pas quel shadow dict utiliser, 
> mais qu'il veut a tout pris la tag qui correspond a "Proprietary Tag", il 
> devrait pouvoir charger a la volee un shadow dict apres l'autre juste qu'a 
> trouver celui qu'il souhaite...
L'idée serait pt-etre d'avoir un DicomObject, contenant tous les champs 
Dicom
tels qu'ils ont été lus par un Reader, ne cherchant aucune interprétation ou
hiérarchie dans leur interprétation. Puis avoir un DocumentInterpreter qui 
va
prendre ce DicomObject et l'interpreter pour en faire soit un Document (avec 
utilisation
du ShadowDict), soit un DicomDir, soit autre chose...




>> une BinEntry, c'est une VR = 'OB' ou 'OW'
>> une SeqEntry, c'est une VR = 'SQ'
>> une ValEntry, c'est tout le reste
>> (sauf erreur de ma part)
>
> Ah ok donc ValEntry devient la super classe les autres sont des cas plus 
> specifiques de ValEntry...
Na, chacune est différente, dans la valeur sauvegardée et la manière de la
sauvegarder :
BinEntry : valeur dans un tableau uint8_t avec la taille du tableau a coté.
SeqEntry : valeur dans une liste de SQItem
ValEntry : valeur dans une string
C'est le DocEntry qui est la superclasse de tout cela.


Benoit