Re: [Gdcm2] GDCMSerieHelper and DICOM Series Restrictions in GDCM 2.x

[Mathieu M. <mat...@gm...>]

On Tue, Jan 17, 2012 at 8:38 AM, Mathieu Malaterre
<mat...@gm...> wrote:
> Hi Zeke,
>
>  Sorry I completely missed your email.
>
> On Tue, Jan 17, 2012 at 6:37 AM, Zeke McKinney <zek...@gm...> wrote:
> ...
>> On Sat, Dec 24, 2011 at 11:55 AM, Zeke McKinney <zek...@gm...> wrote:
>>> Hi all,
>>>
>>>    Thanks to all of you who work hard on this code, as it is pretty
>>> powerful stuff!
>
> Thanks :)
>
>>>    I'm using GDCM 2.x through ITK 4.0.0 on Snow Leopard with gcc 4.2.1.
>>>
>>>    I'm writing because I use ITK frequently and recently decided to
>>> switch from 3.20.0 to 4.0.0, which with respect to GDCM means I went
>>> from 1.x to 2.x.  Because of the dramatic API shift between the old
>>> and the new GDCM, I had to make a few changes to my old 3.20.0 ITK
>>> code to get it to compile, but that wasn't a big problem.  What I did
>>> notice right away, though, was that the DICOM series restrictions I
>>> was trying to implement using SerieHelper::AddRestriction(const
>>> std::string & tag) weren't seeming to get applied.  In fact, through
>>> plenty of testing, it didn't seem like any restriction I tried through
>>> that function would work.
>>>
>>>    I dug around in the source and messed with a few things, and I
>>> think I've discovered the problem.  The three instances of
>>> AddRestriction in gdcmSerieHelper.cxx are as follows:
>>>
>>> void SerieHelper::AddRestriction(uint16_t group, uint16_t elem,
>>> std::string const &value, int op)
>>> {
>>>  Rule r;
>>>  r.group = group;
>>>  r.elem  = elem;
>>>  r.value = value;
>>>  r.op    = op;
>>>  Restrictions.push_back( r );
>>> }
>>>
>>> void SerieHelper::AddRestriction(const std::string & tag)
>>> {
>>>  Tag t;
>>>  t.ReadFromPipeSeparatedString(tag.c_str());
>>>  AddRestriction( Tag(t.GetGroup(), t.GetElement()) );
>>> }
>>>
>>> void SerieHelper::AddRestriction(const Tag& tag)
>>> {
>>>  Rule r;
>>>  r.group = tag.GetGroup();
>>>  r.elem  = tag.GetElement();
>>>  Refine.push_back( r );
>>> }
>>>
>>> Interestingly, if you use the second instance, with the argument of
>>> const std::string & tag, then you get pushed to the third instance.
>>> From what I can tell, it seems like there was the intention of
>>> refining any rules passed without an associated value or operator, as
>>> are required as arguments of the first instance.  This is a problem
>>> because in SerieHelper::AddFile(FileWithName &header) the Restrictions
>>> object gets checked for any desired series restrictions, and Refine
>>> isn't used at all.  In fact, searching through the whole file reveals
>>> that Refine is only used in the context of the function
>>> SerieHelper::CreateUniqueSeriesIdentifier( File * inFile ), where it
>>> is not parsed to be redirected back into the Restrictions object.
>>>
>>> Of course, some significant changes to this file would have to be made
>>> to accomodate the (presumably) desired behavior.  For one, because
>>> there isn't any value or operator associated with the restriction as
>>> represented in the Refine object, line 198 where the comparison
>>> happens wouldn't work even if Refine was used in the
>>> CreateUniqueSeriesIdentifier(...) function.  Line 198 is below for
>>> reference, illustrating the need for an operator and a value for the
>>> restriction:
>>>
>>>    if ( !CompareDicomString(s, r.value.c_str(), r.op) )
>>>
>>> So ultimately, I'm saying that I would like the implementation of
>>> void SerieHelper::AddRestriction(const std::string & tag) to work such
>>> that my series restrictions can have the desired effect.  Or am I just
>>> reading this all wrong and there's an easy way to get my restriction
>>> to work?
>
> Are you using the latest of ITK ? There is a document explaining the
> transition from ITK 3.x to 4.x, is this issue listed on the transition
> document ?
> Did you raise this issue on the ITK mailing list ? Do you have a small
> example to reproduce the issue (with desired behavior described) ?

Doing a quick google search reveals the code from the MITK people:
http://svn.mitk.org/trunk/mitk/Core/Code/IO/mitkDicomSeriesReader.cpp

HTH

-- 
Mathieu