[Dcmlib] gdcm proposal

[Mathieu Malaterre]

> Heuuu... cela me gene un peu d'avoir une utilisation Python différente 
> de celle
> en C++. Je pense qu'on peut éviter cela en réfléchissant mieux au problème.
> Mais pour l'instant, je n'ai pas encore de solution

Je ne connais pas suffisament swig mais avec le wrapper vtkPython, une 
fonction:

double *foo()

en python donne un truc du genre:

list foo()

Ma requete c'est d'avoir un moyen de manipuler les champs genre spacing, 
image position, image direction (cos machin) via des listes de float...

> SQItem est réellement une liste et donne un accès en O(1). dans une 
> séquence,
> il y a N fois le meme ensemble de DocEntry. Et on accède à chaque ensemble
> en connaissant sa place dans la liste (dont l'ordre dépend). Je ne vois 
> donc pas
> comment tu veux utiliser ta hash table.

Je voudrais vraiment lire une image DICOM du genre:

void Read()
{
end = file.gcount();
ParseDES(0, end)
}

void ParseDoc(debut, fin)
{
    if( ! SEQ )
       AddNewEntry
    else
      len = ReadLenght()
      ParseDoc( file.tellg(), file.tellg()+len)
}

Est-ce que chaque sequence est identifiee par un tag unique ? Si oui 
alors on peut faire un acces via un Tag en O(1) si on connais aussi 
l'identifier de la sequence. La requete serait alors du genre:

Document.GetEntry(0x1234, 0x5678, 0x1111, 0x2222)
                     Dicom Tag         Seq Tag

Bon je reconnais que je n'ai pas d'implementation a proposer donc on 
peut laisser ca de cote.


> Je n'avais pas dans l'idée que DicomDir derive de Document lorsque j'ai 
> écrit cela
> Je crois que Document n'etait pas le bon nom.
> Pour moi, je pensais à 2 structure différentes entre Document et 
> DicomDir. Les 2
> dérivant d'une structure Data (par exemple)

on peut essayer de se rapprocher de la definition des termes en premiere 
page de la norme 3.10 DICOM DATA SCTRUCTURES AND ENCODING DEFINITIONS

>> prend en entree un filepath d'un repertoire.
>> retourne une liste de fichiers (vector<string>), qui est passer a un 
>> SerieReader.
>> Je tiens a tout prix a cette separation, l'utilisateur doit a tout 
>> moment lire ces fichiers dans l'order qu'il veut (cas ou les 
>> heuristiques de SewrieOrder, mais l'utili lui seul sait dans quel 
>> order les lire).
> 

On a fais des heuristiques pour essayer de classer ces images, mais 
admettons qu'elles echouent toutes pour un cas particulier. Dans ce cas 
l'utilisateur devrait pouvoir ecrire son petit script python qui genere 
les noms de fichiers dans l'ordre qu'il veut lire. On ne peut pas lui 
demander de reimplementer ca via une strategie directement dans le code 
de gdcm. C'est pour ca que je tiens a laisser en entree de SerieReader 
une liste de nom de fichiers (tres facile a pluger dans son propre code).

> Mais comment l'utilisateur peut savoir d'avance quel type d'image il a à 
> lire ?
> Si son image n'est pas lisible par le DicomV3Reader, il devra essayer 
> les autre 1
> par 1 ? Je ne pense pas que ce soit la bonne solution. Pour rester poli, ca
> risque de faire chier l'utilisateur de cette librairie...

Rahhhhhhhhhhhhhhhhh !
C'est exactement le contraire que je veux faire. Tu instancies un 
gdcm.Reader(). Dans le code de gdcm.Reader tu fais une fonction :

Type Reader::GetDicomType()
{
   //blah
}

void Reader:;Initialize()
{
    type = GetDicomType()
    switch(type)
       case DICOMV3
         this->InternalReader = new gdcm.DicomV3Reader()
       case LIBIDO
         this->InternalReader = new gdcm.LIBIDOReader()
       case ACR
         this->InternalReader = new gdcm.DicomV3Reader()
       default:
         cerr << "ouch, heuristique GetDicomType failed can't recognize 
type"
}

Est-ce que c'est plus clair ? Si c'est plus clair est-ce qu'il est 
possible de mettre le gdcm.DicomDirReader dans le meme switch ou pas ? 
Ca serait tellement mieux pour le pauvre user...



> Dans la version courante de gdcm :-p
> En fait, le DicomDir actuel n'a pas besoin de toute la complexité du
> Document... Il a juste besoin de conserver une liste de Patient, qui à son
> tour contient une liste de Study qui contient les Serie qui contient les 
> Image.
> 
> 
> Je crois que je vais commencer à faire un diagramme de classes pour
> essayer de poser les choses et partir de la pour les prochaines 
> discussions.
> Ainsi que des exemples. J'ai l'impression qu'on se mélange trop les 
> papattes
> sur les noms.

ca marche, merci
Mathieu