[Dcmlib] Serie Helper

[Mathieu Malaterre]

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

Cool, never realize it was actually working...

> --> NO !

oops... :)

> 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".

agree

> 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)

Again I believe this is a problem of defining who is doing what.
So I see three cases:
- Directory with only DicomDir
- ""                  Dicom (image)
- Mixed of DicomDir and image.

Let's call gdcm::Organizer the class that organize the DicomDir, then 
IMHO you cannot have the same algorithm for a bunch of DICOM images. So 
you may need a sub class of gdcm::Organizer, something like 
gdcm::SerieOrganizer. But then again how do you treat case #3 when you 
have a mixture of DicomDir and Dicom image. What kind of comparison can 
you apply in between those two docs ?

Anyway I still have trouble seing what the approach. So JP could you 
enumerate all the possible cases (or at least those you want to handle). 
Once this is done then I think this will be easier to define a robust 
architecture... as I still don't see how SerieHelper could handle all 
possible cases.


> 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.

Well at the end someone will be building a GUI, so whatever way we(you) 
implement this, the input should be extremely easy for the 
radiologist... Or gdcm should also be able to tell the different way to 
organize the serie.


Mathieu... still very confused