Image Position (Patient) Attribute (0020,0032) in DICOM file not handled

Support
3

Hello Steve,

Thanks for getting back to me that fast. I took some time to go over the DICOM documentation to diligently come up with a piece of code that produces the result I want (i.e., a DICOM file with Image Position (Patient) Attribute (0020,0032) being accounted for when I load the file into Slicer). I think I got it now!

I also looked a bit into Slider source code to understand what tags and sequences it expects when it is about to read (0020,0032). I notice something that I want to bring to your attention (Slicer/itkDCMTKFileReader.cxx at 1026bb846d29fe9099de9ec002e332168da8392a · Slicer/Slicer · GitHub):

if((this->GetElementSQ(0x5200,0x9229,originSequence,false) == EXIT_SUCCESS ||
      this->GetElementSQ(0X5200,0X9239,originSequence,false) == EXIT_SUCCESS) &&
     originSequence.GetSequence(0,subSequence,false) == EXIT_SUCCESS &&
     subSequence.GetElementSQ(0x0028,0x9113,subsubSequence,false) == EXIT_SUCCESS)
    {
    subsubSequence.GetElementDS<double>(0x0020,0x0032,3,origin,true);
    return EXIT_SUCCESS;
    }

It seems to me that Slicer uses DCMTK to look for Tag (5200,9229) “Shared Functional Groups Sequence Attribute” and if it does not find it, it looks for Tag (5200,9239), which I could not find in the DICOM documentation. I think the logical thing to do would be to look for “Per-frame Functional Groups Sequence Attribute” (5200,9230) instead.

I have not run any test to confirm that this is indeed a typo-induced bug.

Sincerely,
Luca