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

**URL:** <https://discourse.slicer.org/t/image-position-patient-attribute-0020-0032-in-dicom-file-not-handled/23950>\
**Category:** Support\
**Tags:** dicom\
**Created:** [June 19, 2022, 5:58pm UTC](https://discourse.slicer.org/t/image-position-patient-attribute-0020-0032-in-dicom-file-not-handled/23950 "2022-06-19T17:58:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![lcaucci78](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lcaucci78/32/15703_2.png) [@lcaucci78](https://discourse.slicer.org/u/lcaucci78)\
**Post date:** [June 19, 2022, 5:58pm UTC](https://discourse.slicer.org/t/image-position-patient-attribute-0020-0032-in-dicom-file-not-handled/23950/1 "2022-06-19T17:58:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [June 19, 2022, 6:06pm UTC](https://discourse.slicer.org/t/image-position-patient-attribute-0020-0032-in-dicom-file-not-handled/23950/2 "2022-06-19T18:06:30Z")

</div>

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](https://www.slicer.org/wiki/Coordinate_systems)

---

<div class="post-metadata">

**Author:** ![lcaucci78](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lcaucci78/32/15703_2.png) [@lcaucci78](https://discourse.slicer.org/u/lcaucci78)\
**Post date:** [June 22, 2022, 8:17am UTC](https://discourse.slicer.org/t/image-position-patient-attribute-0020-0032-in-dicom-file-not-handled/23950/3 "2022-06-22T08:17:24Z")

</div>

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](https://github.com/Slicer/Slicer/blob/1026bb846d29fe9099de9ec002e332168da8392a/Modules/CLI/PETStandardUptakeValueComputation/itkDCMTKFileReader.cxx#L1111)):

```auto
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

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [June 22, 2022, 2:53pm UTC](https://discourse.slicer.org/t/image-position-patient-attribute-0020-0032-in-dicom-file-not-handled/23950/4 "2022-06-22T14:53:35Z")

</div>

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:

> <https://github.com/Slicer/Slicer/pull/6446>
>
> itkDCMTKFileReader was added in 2012 but it seems that current itkDCMTKFileReade…r in ITK works just as well.
> The 2012 version has a bug (it should use (0x5200, 0x9230) instead of (0x5200, 0x9239) tag - see https://discourse.slicer.org/t/image-position-patient-attribute-0020-0032-in-dicom-file-not-handled/23950/3) therefore it makes sense to switch to the ITK implementation.