[Insight-users] Bug Report (with bugfix): GDCM SerieHelper::SplitOnOrientation

[Csaba Csoma]

Problem:

  Using GDCMSeriesFileNames to search for volumes the Series
  Restriction should be this:
   "0020|0052" - Frame Of Reference (invalid coords if changed)
   "0020|000e" - Series Instance UID (series defined by the scanner)
   "0020|0037" - Patient Orientation

  The "Patient Orientation" is necessary since in MRI the scout
  scan will create 3 volumes (axial, sagittal and coronal) into
  a singles series.

  But the GE scanner (NIH, Bethesda) created the following Orientations:
   -0.474171\0.877813\-0.0678738\0.117436\-0.0133367\-0.992991
   -0.474171\0.877813\-0.0678738\0.117436\-0.0133368\-0.992991
   -0.474171\0.877813\-0.0678739\0.117436\-0.0133367\-0.992991
  so AddSeriesRestriction or SerieHelper::SplitOnOrientation will
  split this single volume into multiple (sub) volumes.

  The problem is due to rounding error in the GE scanner, but the
  float/double variable is known to not be precise for == type
  comparisons. (Floating point is implemented using fractional
  powers of 2, so it is an approximation of the real value.)


Solution:

  AddSeriesRestriction is not a solution, since the Orientation is
  written in 0020 0037 or 0020 0035 - and it would not be a generic
  solution anyway.

  GDCM SerieHelper::SplitOnOrientation can be used if it will crop the
  last decimal of the cosines strings. Something like this:

  std::string CropLastDecimal(std::string s)
  {
      if ( s.size() < s.find_first_of('.')+1 )
         return s.substr(0, s.size()-1);
      return s;
  }

  called for each element of the cosines matrix.

  Sure this could be made into a more robust solution (compare with
  "abs" in floating or double variable level) in long run.

Csaba



Csaba Csoma
Systems Engineer
------------------------
Johns Hopkins University
3400  North Charles Str.
B26 New Engineering Bldg
Baltimore, MD 21218-2682
Phone: (410) 516-4991
mailto:csoma at jhu.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20060523/fa0f25d1/attachment.html