[Dcmlib] SerieHelper::AddRestriction

[Benoit Regrain]

----- Original Message ----- 
From: "Jean-Pierre ROUX" <jean-pierre.roux at creatis.insa-lyon.fr>
To: "Mailing list gdcm" <dcmlib at creatis.insa-lyon.fr>
Sent: Sunday, May 29, 2005 12:52 PM
Subject: Re: [Dcmlib] SerieHelper::AddRestriction


> At 17:24 -0400 27/05/05, Mathieu Malaterre wrote:
>>Yo,
>>
>> Une des demandes actuelles sur la ML de ITK c'est de pouvoir sous 
>> selectionner une serie DICOM des le depart. On doit pouvoir donner une 
>> ensemble de regle a gdcm pour ne lire que certain fichier DICOM. Le cas 
>> actuel qui s'est presenter c'est de pouvoir trier la serie selon son 
>> EchotTime et d'ecarter celles qui n'aurait pas le bon (dans ce cas lUID 
>> etait la meme dans toutes les series).
>
> Il se peut qu'on soit ammenés à réfléchir de nouveau sur la manière de s'y 
> prendre avec les 'ensembles d'images', qu'on considère pour le moment 
> comme pouvant etre multi-patient, multi-modalite, multi-examen ...
>
> Pour le moment dans SerieHelper, en une seule opération (du point de vue 
> user) :
> - on 'ventile' les images par 'Serie' (c'est a dire sur le Serie UID quand 
> il y en a un -c'est le cas des images DICOM-Kasher-, ou sur d'autres 
> criteres heuristiques.
> - on 'trie' a l'intérieur de chaque 'Serie', selon des considérations 
> géographiques, au mieux de ce que les champs présents dans l'entete nous 
> permettent de faire.
>
> Il faudra probablement dissocier :
> - 'selection' (ce que l'on veut garder),
> - 'ventilation' (dans ce qu'on a gardé, on fait une partition -au sens 
> math.- des images)
> - 'classement' (dans chaque partition, on ordonne les images, selon un 
> certain critère)
>
> Ce qu'on fait actuellement a toujours son utilité (pour afficher le 
> contenu d'un directory, en l'absence du DICOMDIR correspondant)
>
> Les questions des utilisateurs de la ML ITK portent vraisemblablement sur 
> la partie 'Selection': ne garder *que* celles qui ont un 'Echo Time' 
> donné, a l'interieur de qq chose deja 'ventile' (une Serie).
>
> Il faut, a mon avis, permettre a un utilisateur 'aware' de dissocxier les 
> opérations.

Plus vite on aura décidé de la nouvelle structure, plus vite on pourra 
régler
ce genre de problèmes.



>>
>> J'ai essayer de faire ca de maniere generique afin que plus tard on 
>> puisse trier selon une date donnee, une hopital donne, une age...
>>
>> Le probleme c'est que je me suis encore pris la meme porte: Il n'y 
>> absolument pas de consistance dans gdcm on peut soit attendre:
>>
>>uint16_t group, uint16_t elem
>>
>>ou bien
>>
>>TagKeg key  (par ex: "1234|5678")
>
> Le TagKey est qq chose de parfaitement 'interne' (c'est la cle de la 
> std::map, dont l'utilisateur ignore l'existance), et n'aurait donc jamais 
> du etre 'vu' par les utilisateurs.
> Ce que l'utilisateur connait, c'est 'group number', 'element number'.

Le TagKey a été inséré par Eric pour définir un tag global pour chaque
Entry, en prenant en compte l'arborescence créée par les Sequence.
Je pense que JPR a tout à fait raison, il faut garder le group, elem pour 
l'utilisateur.
En ce qui concerne le TagKey, je ne l'ai personnelement jamais utilisé. Je 
ne suis
pas sur qu'un jour je l'utiliserai (meme lorsque je développerai l'éditeur 
Dicom).
Mais je ne suis pas le seul utilisateur de gdcm dans le monde et je ne sais 
pas si
cela pourrait un jour (ou meme déjà) servir à quelqu'un. Si on considère que 
non,
on pourrait le supprimer définitivement, mais c'est à discuter...

Benoit