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

Support
1

Hello,

One application I am working on uses dcmtk to create a DICOM file, which I then load into Slicer, along with an STL file I have. I want the voxel volume from the DICOM file be positioned in a specific way with respect to the triangle mesh in the STL file (think to this as positioning a SPECT-reconstructed volume with respect the mesh of a patient). To this end, I use Image Position (Patient) Attribute (0020,0032) when I create the DICOM file. However, Slicer seems to ignore anything I set for Image Position (Patient) Attribute, and it is always using (0, 0, 0) for that attribute. Am I doing something wrong?

I am using Slicer 5.0.2 r30822/a4420c3.

Sincerely,
Luca

2

Hi -

Be sure you are importing via the DICOM module. Slicer is pretty careful to respect whatā€™s in the dicom header so I suspect the alignment error is elsewhere, such as the coordinate system assumptions of the STL file.

If you do find any issues with coordinate system handling please report it with example (anonymized) data to reproduce.

Refer to this page:
https://www.slicer.org/wiki/Coordinate_systems

1 Like
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

4

Good catch, indeed the file reader should use (0x5200, 0x9230) instead of (0x5200, 0x9239). It seems that itkDCMTKFileReader.cxx was copied from ITK in 2012 and all the changes since then were just to fix compilation issues.

It seems that we can switch to the DCMTK reader in ITK, where the correct tags are used. Iā€™ve submitted a pull request with this change:

1 Like