[Dcmlib] gdcm proposal (2)

[Mathieu Malaterre]

> La seule liste d'elements privés que nous ayions vue, c'est celle que 
> nous avait communiquée Jean-Michel Rouillet.

s/Rouillet/Rouet/g

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

Je reste sur ma position que gdcm doit pouvoir gerer la shadow dict. 
Ensuite c'est une histoire de l'avoir par defaut ou pas. Tout mon propos 
c'est d'autoriser l'utilisateur une plus grande flexibilite dans les 
dictionaires.

Voila ce que j'ai compris des dictionaires: J'ai une ancienne image ACR 
NEMA avec ImagePosition en (0020,0030) elle est donc valide (au sens 
gdcm.Validator + dictionaire ACR NEMA). Mais elle devient invalide par 
rapport a un dictionaire dicomV3 2003/2004. Si j'ai bien compris une 
image DICOM est valide par rapport a un dictionaire produit une annee X. 
Donc meme si on n'aura jamais de dictionaires privee/shadow je pense 
qu'il est important de pouvoir manipuler plusieurs dictionaires...

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

J'essai de proposer une architecture dans le lequel il est facile 
d'ajouter/enlever le support de DICOM buggee. Si je tiens a faire des 
classes separer c'est pour isoler les cas d'image bugger qui font perdre 
du temps a la lecture plus qu'autre chose. On devrait avoir une entree 
cmake qui permettent d'enlever facilement ce overhead. Dans mon idee 
c'etait de faire des classes separees comme ca on peut completement 
enlever de la dll ces classes, et avoir une implementation kasher DICOMV3...


> du grand d'importe quoi!

Tu peux detailler ta conclusion ?

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

Mon probleme actuel c'est d'ajouter le streaming a gdcm. On doit pouvoir 
afficher la premiere slice d'une image 5Go sans avoir a lire 
l'integratee du volume. On doit pouvoir extraire un sous volume x,y,z 
d'une image DICOM sans avoir a tout lire !
Et dans le cas present je ne vois pas comment faire ca *proprement*. 
Voila mon probleme.


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

Faire des 'mini' new Entry a chaque fois que tu lis 2+2 bytes c'est qd 
meme un peu lourd. Si jamais on arrive a consider que ce sont toujours 
les meme types d'element a lire on peut constuire un 'pool' de ces 
objets. Dans le pire des cas le pool sera surestimer et on perdra en 
place memoire le nombre d'entry allouer - le nombre d'entry rellement lu...


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

je vois pas bien comment tu peux ralentir gdcm ;-P

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

je me cogne la tete contre le mur...

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

Y'a plusieurs chose a voir:
- Est-ce que DicomWorks lis toutes les images qu'on lit ?
- Comment est compile la dll ? ( gcc -O3 )

Le probleme c'est qu'on a fais le choix d'utiliser C++ pour faire du IO. 
C'est pas mauvais mais des le depart on admet qu'on sera bcp + lent que 
l'equivalent C. En revanche je continue de penser que ce n'est pas 
l'acces disque qui est lourd mais la gestion memoire. Et dans ce cas des 
outils comme valgrind+callgrind+massif sont la pour nous aider.

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

Je propose de se rapprocher des notations de :

3.10 DICOM DATA SCTRUCTURES AND ENCODING DEFINITIONS



Mathieu