[Dcmlib] gdcm proposal (2)

[Mathieu Malaterre]

> 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...

 >  - 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


> 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...

> 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...


> 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' ?

> Mais cela va ralentir lors de la recherche du nom appartenant une Entry...
> certes le parsing sera plus rapide, les Entry plus petits. C'est à discuter.
> Pour moi je laisse le sujet en suspend pour l'instant.

ok

> 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).

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...


> 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...

> Le New/Delete de VTK sert aussi a proteger l'accès au constructeur et 
> destructeur
> car ce dernier utilise le reference counting... ca n'a rien a voir avec 
> des compilos !

Tu peux surcharger l'operateur operateur::new() et faire le reference 
counting a ce niveau.
Mais tu as raison le ::New est en fait pour la factory dans VTK. Tu peux 
faire: vtkActor::New() et en fait ca creer un vtkOpenGLActor() ou un 
vtkMesaActor(). Desole pour la confusion

Mathieu