[Dcmlib] gdcm proposal (2)

[Mathieu Malaterre]

> 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é ;-)

ok

> Ou alors avoir un ImageInterpreterLight (nom à revoir) dont deriverait le
> ImageInterpreter

bof bof... ImageInterpreterLight n'aurait pas vraiment d'Output ou 
toujours NULL. Je prefere laisser ce genre d'utilisation a une fonction 
interne de gdcm dans le cas ou le gars sais ce qu'il veut en ne faisant 
que ExecuteInformation()...

> Ha ben j'ai noyé le poisson dans la marre... je fais un doc sur 
> l'explication de tout
> ca a coté.

ok

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

ok

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

Je comprends ton point de vue, mais je reste persuade que les 
dictionaires shadow sont qd meme pour les utilisateurs avances. Mon prob 
leme c'est qu'on ne peut pas tous les charges, et il ne sont pas 
interchangeable. Mais la chose que je sais c'est qu'on sait lire une 
image DICOM (et produire l'image) juste avec le dictionaires public. 
C'est pour moi la seule chose que veulent Maracas et CreaTools, non ?

Mais je suis aussi d'accord que l'on pourrait commencer a penser a un 
mechasnime qui reconnaissent les type d'images DICOMV3:

Process
  - Reader
     - DocReader
        - DicomV3Reader
          - SiemensReader (+Shadow dict)
          - GEReader      (+Shadow dict)
          - PhilipsReader (+Shadow dict)
          - PublicReader (public dict only)


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

l'objet que tu decris c'est la structure interne du gdcm.Document. Ce 
que j'appelle gdcm.EntrySet...

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

ouais... je suis pas convaincu ;-P Mais comme j'ai pas d'autres 
propositions je suis d'accord.

Mathieu