[Dcmlib] Serie Helper

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

>> 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)
>
>
--> I finally commited the methods.
They don't break anything, we shall change their names when sby find 
better ones.

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

I don't get your differences...
After user called SerieHelper on a directory (or tree of directories), 
and choosed one of the returned 'FileList' ,
he may now:
- split this 'FileList' on the 'Orientation' (to remove *the* axial 
scout view for a Serie that contains sagital views, for instance),
- split this 'FileList' on the 'Position' (to have temporal file sets, 
if he want to study perfusion on ecah slice, for instance)
- split this 'FileList' on a given Tag value (*he* knows better than we 
do, what he wants to do !)
He is now able to process one or more of these file sets, depending on 
what *he* knows.
He can now order the gdcm::File*, on the way he wants, using 
ImagePositionPatientOrdering, ImageNumberOrdering,  FileNameOrdering, or 
giving it's own comparison function -hope *he* knows more tahn we do, 
about his images -
That's at application level, not at gdcm level.
Still following?

Second problem :
The user has a DICOMDIR.
Better than opening 10 000 files, he looks at the DICOMDIR  (gdcm 
provides all the methods to do that)
He chooses the gdcm::DicomDirSerie he wants to work with.
A gdcm::DicomDirSerie is std::list of gdcm::DicomDirImage.
A gdcm::DicomDirImage  contains *all* the tags necessary to split, to 
sort, etc, just like a gdcm::File.
All the low level accesors (defined as members of gdcm::DocEntrySet 
class) exist to do the job.
The only trouble I have is *how* to use template functions to be able to 
work, either on a std::vector of gdcm::File, or a std::list of 
gdcm::DicomDirImage.

I'll send you the piece of code that hangs at compile time (to be able 
to generate the code(s) for a given template function, the compilers 
needs to know the actual  data type the function is called with.  It 
doesn't in my code.
Probabely, I should use macro ?)

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

I have *exactly* the sames sort/split algorithms to deal with a set of 
gdcm::File or a set of gdcm::DicomDirImages.

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

-> Two methods are now provided to the user, to split a given 'Single 
SerieUID' file set (formerly called 'CoherentFileList')
-on the Orientation
-on the Position
One extra method allows user to split a 'Single SerieUID' file set on 
the Tag value *he* decided.

JP

>
>
>> 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
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>