[Dcmlib] Serie Helper

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

> [Sorry french only]

--> Answers in English
(I never should have start witting in french language. Sorry)

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

Some times ago I extendend the "Restriction' definition.
You can now specify the'operator' (
 GDCM_EQUAL
GDCM_GREATEROREQUAL,
 GDCM_LESSOREQUAL
GDCM_EQUAL :
etc ...

> 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 peu construire une serie coherente...


--> NO !
The problem I described start from here.
What we call 'CoherentFileList' is a 'single SeriesUID File List'.
It will be coherent if the user is able to tell gdcm how to split this 
'single SeriesUID File List' into (maybe) several *coherent*file lists.

(Have a look at Luca's mail, or at 
http://www.creatis.insa-lyon.fr/~jpr/PUBLIC/gdcm/gdcmSampleData/ForSeriesTesting/VariousIncidences/
within a single SeriesUID File List (i.e. in a given directory), you can 
have one sagital image + 20 coronal images, or one axial image + 20 
sagital image.
Luca don't want to ask the Doctor "just open the directory, have a look 
to the images using ImageMagick, remove the useless images, and then run 
may sotware".

I wrote a method (not yet commited) gdcmSerieHelper::SplitOnOrientation, 
that gets a so called 'CoherentFileList' (not coherent at all, and 
return a std::map of 'CoherentFileList', that are -hope so- coherent)
I can add very easyly a method called Split ( FileList *, TagKey const &key)
that splits the FileList into as many FileList then there are different 
values for the given key.
User is supposed to be aware.
It's very easy to use.

What I wasn't very happy was the names of the methods, of the way to 
call them.

And I wanted to generalize the 'Ordering' methods to allow them to work, 
either on a FileList * or on a gdcm::DicomDirSerie *.
(no theoretical pb, just a C++ syntax pb)

JP

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


In some case you want to build a volume (what do you do if you have 2 
-or more- volumes within a single SerieUID ?)
In other cases, -perfusion problems-, you actually have *n* volumes 
within a single SerieUID, but what's meaningfull for you, is, slice per 
slice,  'temporal series'.
*you* know what's meaningfull, gdcm *doesn't*.
gdcm has to allow *you* to tell him what you expect him to do for you.

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