"Please check slice thicknesses" for certain DICOM files

[baxpr]

This is not so much a dcm2niix issue as me trying to debug some DICOM transfers in our systems. But we have a DICOM file that works great with dcm2niix v1.0.20200331. But when we transfer it to a different system, something goes awry and we start getting this:

Chris Rorden's dcm2niiX version v1.0.20200331 Clang11.0.3 (64-bit MacOS)
Found 1 DICOM file(s)
Please check slice thicknesses: Philips R3.2.2 bug can disrupt estimation (720 positions reported for 360 slices)

And a .nii is produced that is shifted in space by 1/2 voxel in X and Y compared to the one that gave no warning.

But, I can't find any differences in the geometry fields in the two files that would explain this. I was wondering what the logic is that leads to this warning and/or what I missed in terms of geometry data. Files are here - these are phantom images that can be shared:

https://www.dropbox.com/sh/5oj5ytjxmen3t13/AADtPEdjvcL8KDd1xQVdnzZga?dl=0

Thanks for suggestions if this rings a bell!

[neurolabusc]

@baxpr this is timely. Presumably, when you transferred the data to a different system, it was touched by an Agfa Impax system (or another PACS that also relies on dcm4che) that remapped the private manufacturer group tags. See here for an explanation and the consequences. The latest developmental release tells users to see issue 435:

Warning: PrivateCreator remapping detected. DICOMs are not archival quality (issue 435).

Running the developmental release of dcm2niix in logorrheic mode (-v 2) will reveal that private vendor groups 2005,10xx, 2005,14xx, 2005,15xx have been remapped to 2005,10xx, 2005,11xx, 2005,12xx respectively. You can see this by running dcmdump on your original and modified datasets:

Original Vendor Tags:

(2005,0010) LO [Philips MR Imaging DD 001] #  26, 1 PrivateCreator
(2005,0014) LO [Philips MR Imaging DD 005] #  26, 1 PrivateCreator
(2005,0015) LO [Philips MR Imaging DD 006] #  26, 1 PrivateCreator
(2005,100b) FL 110108.95                   #   4, 1 Unknown Tag & Data
(2005,100c) FL 0.024909576                 #   4, 1 Unknown Tag & Data
(2005,100d) FL 0                           #   4, 1 Unknown Tag & Data
(2005,100e) FL 0.021476135                 #   4, 1 Unknown Tag & Data
(2005,1011) CS [M]                         #   2, 1 Unknown Tag & Data
(2005,1061) CS [NO]                        #   2, 1 Unknown Tag & Data
(2005,1063) SS 1                           #   2, 1 Unknown Tag & Data
(2005,106e) CS [FFE]                       #   4, 1 Unknown Tag & Data
(2005,10a0) FL 0                           #   4, 1 Unknown Tag & Data
(2005,10a1) CS [SENSE]                     #   6, 1 Unknown Tag & Data
(2005,10a8) DS [0]                         #   2, 1 Unknown Tag & Data
(2005,10b0) FL 0                           #   4, 1 Unknown Tag & Data
(2005,10b1) FL 0                           #   4, 1 Unknown Tag & Data
(2005,10b2) FL 0                           #   4, 1 Unknown Tag & Data
(2005,1407) SS 1                           #   2, 1 Unknown Tag & Data
(2005,1412) IS [1]                         #   2, 1 Unknown Tag & Data
(2005,1413) IS [1]                         #   2, 1 Unknown Tag & Data
(2005,1429) CS (no value available)        #   0, 0 Unknown Tag & Data
(2005,1561) FL 0                           #   4, 1 Unknown Tag & Data
(2005,1568) IS [1]                         #   2, 1 Unknown Tag & Data
(2005,1572) FL 0                           #   4, 1 Unknown Tag & Data
(2005,1573) IS [0]                         #   2, 1 Unknown Tag & Data
(2005,1596) IS [0]                         #   2, 1 Unknown Tag & Data

Remapped:

(2005,0010) LO [Philips MR Imaging DD 001] #  26, 1 PrivateCreator
(2005,0011) LO [Philips MR Imaging DD 006] #  26, 1 PrivateCreator
(2005,0012) LO [Philips MR Imaging DD 005] #  26, 1 PrivateCreator
(2005,100b) FL 110108.95                   #   4, 1 Unknown Tag & Data
(2005,100c) FL 0.024909576                 #   4, 1 Unknown Tag & Data
(2005,100d) FL 0                           #   4, 1 Unknown Tag & Data
(2005,100e) FL 0.021476135                 #   4, 1 Unknown Tag & Data
(2005,1011) CS [M]                         #   2, 1 Unknown Tag & Data
(2005,1061) CS [NO]                        #   2, 1 Unknown Tag & Data
(2005,1063) SS 1                           #   2, 1 Unknown Tag & Data
(2005,106e) CS [FFE]                       #   4, 1 Unknown Tag & Data
(2005,10a0) FL 0                           #   4, 1 Unknown Tag & Data
(2005,10a1) CS [SENSE]                     #   6, 1 Unknown Tag & Data
(2005,10a8) DS [0]                         #   2, 1 Unknown Tag & Data
(2005,10b0) FL 0                           #   4, 1 Unknown Tag & Data
(2005,10b1) FL 0                           #   4, 1 Unknown Tag & Data
(2005,10b2) FL 0                           #   4, 1 Unknown Tag & Data
(2005,1161) FL 0                           #   4, 1 Unknown Tag & Data
(2005,1168) IS [1]                         #   2, 1 Unknown Tag & Data
(2005,1172) FL 0                           #   4, 1 Unknown Tag & Data
(2005,1173) IS [0]                         #   2, 1 Unknown Tag & Data
(2005,1196) IS [0]                         #   2, 1 Unknown Tag & Data
(2005,1207) SS 1                           #   2, 1 Unknown Tag & Data
(2005,1212) IS [1]                         #   2, 1 Unknown Tag & Data
(2005,1213) IS [1]                         #   2, 1 Unknown Tag & Data
(2005,1229) CS (no value available)        #   0, 0 Unknown Tag & Data

Can you provide the following information:

1. What PACS handled the transfer? ImplementationVersionName (0002,0013) reports dcm4che-2.0. dcm4che is used both as an open source tool and for professional Agfa tools (as it is LGPL).
2. I now have examples of Siemens XA and Philips data remapped by Agfa/dcm4che. Would it be possible for you to transfer a couple of DICOM datasets of different types through your system and send me the results. Specifically, it would be useful to see how renaming is applied to Siemens V and GE DICOMs. This repository contains a small set of DICOMs from those two systems.
3. Be aware that if you have any tools that inspect your DICOM data files using hard-coded dictionaries for vendor groups (e.g. 2005,14xx, 2005,15xx) they will not work correctly with data touched by your version of dcm4che. Because of this, I would not consider these remapped images as archival quality. The opportunity for unintended consequences seems high.
4. The dcm4che 2.0 toolkit is deprecated and old (v3.0 was released in 2012, v5.10 in 2017). If you are using a free implementation, does upgrading to dcm4che 5. resolve the renaming?

[neurolabusc]

The shifted in space and the fact that you see twice as many image positions as slices is a duplicate of issue 144. Philips uses the public tag 0020,0032 both as described in the DICOM standard as well as slightly differently for internal purposes. Therefore, each slice has two conflicting image position patient values associated with it. dcm2niix is aware of this, and will disregard the internal value. However, tools that attempt to clean the DICOMs can lose the nuance that the internal value is part of a private sequence. The good news is that the adjustment is small, and would not impact the starting estimates for any subsequent coregistration.

We can see this issue still exists with software 5.6.1, years after we raised alarms. It would be great if Philips could use a private tag to avoid unintended consequences. @drmclem any chance this potential source of confusion can be addressed in future software releases?

[baxpr]

@neurolabusc thanks! This particular file was transferred with dcm4che 2.0 dcmsnd, rather than a PACS. Sounds like that explains that. Presumably you already know what that does with the Siemens and GE files, but let me know if I can run some other tests.

Both of the previous files have been mangled one way or another by our systems. I'll try to get you the DICOM that came from the scanner.