[Dcmlib] Serie Helper

[Mathieu Malaterre]

[Sorry french only]

C'est ce que j'avais commence avec mes 'AddRestriction'...

Mise en situation:
Je suis un utilisateur, j'ai 10000 images DICOM et je dois visualier Mr. 
X, le jour de son exam IRM, le 01/01/1997.
Qu'est ce que je fais:
Je cree un SerieHelper dans mon script python

 >> s = SerieHelper
 >> s.SetDirectory( 'bla' )
 >> s.Execute()

-> gdcm ne doit pas seg faulter mais me dire: 'Sorry I can't find a 
coherent serie for you'

Je continue:

#group elem serait mieux mais je me souvient pas des tag par coeur
 >> s.AddRestriction( 'Patient Name', 'Mr X')
 >> s.AddRestriction( 'Modality',  'MRI')
 >> s.AddRestriction( 'Date',  '01.01.1997')
 >> s.Execute()

-> gdcm est content a a peu construire une serie coherente...

------------------------------------------------------------------

Le vrai probleme c'est de refaire les cas d'utilisation de SerieHelper. 
Ca a ete fais a la base pour Maracas, pour reconstruire un volume. C'est 
pas prevu pour etre le couteau suisse des images series.

2 cents,
Mathieu
Ps: Tu as pu voir que tout est fais par chaine de caractere, donc python 
devrait etre content.

Jean-Pierre Roux wrote:
> Salut, Mathieu .
> 
> --> English translation will follow.
> Sorry.
> JPRx
> 
> Il va falloir qu'on se penche *serieusement* sur le pb du SerieHelper, 
> maintenant qu'on a un peu d'experience.
> 
> Actuellement, on passe au constructeur, des noms de fichiers, et/ou des 
> gdcm::File *, et il fabrique a la volée autant de std::vector qu'il y a 
> de "Series Instance UID" différents.
> Ces std::vector sont rangés dans une std::map (nommée -on s'en tape- :  
> CoherentFileListmap CoherentFileListHT;)
> qui a pour clé le "Series Instance UID".
> On accede a chacun de ces std::vector (dont le typedef est 
> gdcm::FileList), par :
> FileList *GetFirstCoherentFileList();
> FileList *GetNextCoherentFileList();
> 
> C'est a l'utilisateur de decider, en fonction de ce qu'il sait de ses 
> données, de demander le tri des "CoherentFileList" dont il a besoin.
> Par defaut, le tri est fait sur la Position; s'il y a des ex aequo (ou 
> que la Position n'est pas trouvee), on trie sur ImageNumber, si pas 
> trouvé, sur le filename -pourquoi pas ?-
> 
> -->Si l'utilisateur en sait plus que nous sur son critere de tri (par 
> exemple, et n'importe quoi : tri sur le 'TimeTrigger'), il positionne un 
> pointeur sur sa propre fonction de comparaison.
> Ca marche tres bien, mais ca a l'air de chagriner Benoit, pour des 
> problèmes d'utilisation en Python.
> Si on se lance dans trucs du genre 'functor', l'utilsation de gdcm par 
> un utilisateur 'non Itk' ne va pas gagner en clarté, non?
> 
> --> On a vu , qu'en fait, ces "ensembles de gdcm::File* de meme Series 
> Instance UID" ne sont pas si 'coherents' que ca, puis qu'ils peuvent 
> avoir des orientations, ou des positions differentes, et que, dans ce 
> cas, ca peut ne pas convenir *du tout* à l'utilisateur.
> Je propose que, dans la prochaine release de gdcm, on les renome,  
> "SingleSerieUIDFileSet", ou qq chose comme ça, et qu'on ajoute des 
> methodes qui permettraient de ventiler ces "SingleSerieUIDFileSet" en de 
> vraies "CoherentFileSet" (meme taille image/taille pixel, meme 
> Orientation, ou meme taille image/taille pixel, meme Position, ou 
> ventillation sur ce que l'utilisateur souhaite : il nous passe un 
> pointeur sur sa fonction de "test d'egalite".
> (voir remarque précendente  : Python pb)
> 
> --> Si, pour des raisons qui ne concernent que lui, l'utisateur -qui 
> sait ce qu'il fait- recupere des images où bon lui semble, qu'il se fait 
> un std::vector de gdcm::File*, et qu'il lance le tri de ce std::vector, 
> ca marchera -legitimement- tres bien, mais il lui faudra avoir instancié 
> un gdcm::SerieHelper pour avoir acces a la methode de tri 
> SerieHelper::OrderFileList().
> Ma question :
> Cette methode dit-elle rester dans la classe SerieHelper, ou bien 
> doit-elle porter sur une nouvelle classe  "ensemble de gdcm::File*" 
> (name it as you like).
> 
> --> For application reasons of their own, some users wish to 'order' , 
> using  OrderFileList() method -or the next one-, not a
> std::vector(<gdcm::File*>)             - typedefed, right now as 
> gdcm::FileList -
> but a
> gdcm::DicomDirSerie                    - that's, right now, a 
> std::list(<gdcm::DicomDirImage *>) -
> 
> gdcm::File inherits from gdcm::Document
> DicomDirImage inherits from gdcm::SQItem
> Both gdcm::Document and gdcm::SQItem inherits from gdcm::DocEntrySet.
> All the low level methods to access the gdcm::DocEntries to perform the 
> comparison operations are available at the gdcm::DocEntrySet level(no pb 
> till here), the iterators work the same way for both std::vector and 
> std::list
> but the 'Added Value Methods', say : GetImageOrientationPatient, 
> GetXOrigin, GetYOrigin, GetZOrigin are only defined for gdcm;;File (they 
> are meaningless for, say a gdcm::DicomDir, or any kind of gdcm::SQItem), 
> but there are fully meaningfull (?) for a gdcm::DicomDirImage.
> It would be silly to nove theses methods up to gdcm::DocEntrySet.
> Using template method hang at  *application* compile time
> 
> What do we do ?
> 
> JP
> 
> 
> 
> 
> 
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>