[Dcmlib] Serie Helper

[Jean-Pierre Roux]

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