[Dcmlib] gdcm proposal (2)

[Jean-Pierre ROUX]

At 10:04 -0400 2/05/05, Mathieu Malaterre wrote:
>
>Je comprends ton point de vue, mais je reste persuade que les 
>dictionaires shadow sont qd meme pour les utilisateurs avances.

Les shadow dict, c'est pour parler de qq chose quand on n'a PLUS RIEN A DIRE!
C'est une invention de Creatis.
Ce n'est pas dans la norme !
Dans la norme, il y a precisé la possibilité d'utiliser des shadow 
groups par les constructeurs qui auraient des info privées a stocker.
Nulle part, il n'est fait reference a des shadow dicts.

En 10 ans, je n'ai jamais entendu parler d'une seule personne qui 
avait besoin d'un champs privé d'un constructeur.

Et si un jour, qq'un en a besoin, shadow dict ou non, il ira le 
chercher, en utilisant (group number, element number), comme pour 
n'importe quel public element !

La seule liste d'elements privés que nous ayions vue, c'est celle que 
nous avait communiquée Jean-Michel Rouillet.
Et l'experience a montre que, sur la centaine de champs prives que 
contenait l'image, seuls 35 etaient renseignés !
Et qu'un bon nombre etait la répétition d'info stockées par ailleurs, 
dans les champs publics.


> Mon probleme 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:

Il N'Y A PAS de 'type d'images DICOMV3' a reconnaitre !
Il y a des images a lire !

Les 3 ou 4 type d'images buggées que gdcm traite, ce sont des images 
buggées, que l'on a *voulu* pouvoir lire, a un moment ou a un autre.
Lorsque la longueur d'un champs est codée de travers, shadow dict ou 
non, elle reste codee de travers!


>
>Process
> - Reader
>    - DocReader
>       - DicomV3Reader
>         - SiemensReader (+Shadow dict)
>         - GEReader      (+Shadow dict)
>         - PhilipsReader (+Shadow dict)

du grand d'importe quoi!

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


Ce qui serait bien, c'est de se pencher serieusement sur ce qui rame dans gdcm.
S'il y a qq chose a casser pour ce que aille plus vite, on le casse 
et on le refait.

En particulier, comme le soulignait Mathieu, la maniere de traiter 
chaque 'Entry' n'est pas tres rusée.
On la modifie pour que ca aille + vite.

Se lancer dans des modifs en disant 'bien sur, ca va ralentir, mais 
...', c'est du *suicide* !

Douek a deja dit aux gens qui travaillent pour lui <<vous avez le 
droit de jouer avec gdcm si ca vous amuse, a condition que ca nuise 
pas aux *vrais* developpements, qui doivent s'appuyer sur la dll de 
DicomWorks>>

DicomWorks lit les images 2 fois plus vite que gdcm !
Il est vrai que ca a ete ecrit par un medecin, qui ne sait pas programmer.


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

Il faut qu'on se mette d'accord sur les noms qu'on donne aux choses, 
sinon, on ne s'en sortira jamais !


JPRx

  Jean-Pierre ROUX
  UMR CNRS 5515-CREATIS
  Laboratoire de Radiologie Experimentale
  Hopital Cardiologique
  28 Avenue du Doyen LEPINE
  B.P. Lyon-Montchat
  69394 Lyon Cedex 03

  Tel      : (+33) 04 72 35 74 12
  Fax      : (+33) 04 72 68 49 16
  URL      : http://www.creatis.univ-lyon1.fr
  e-mail   : jpr at creatis.univ-lyon1.fr