Incorrect Slice/Vol Order After Site Updated Philips Software (Ingenia version 11.1)

[wtmccuddy]

Ever since our site updated our Philips 3T Ingenia to version 11.1, dcm2niix has been unable to accurately convert functional scans. Each volume contains one slice location across 40 different TRs instead of 40 slices comprising the whole brain at a single TR (e.g., in the image below, scrolling through the axial slices does not change location of the slice, just the time). I have noticed this with fMRI and DTI data sets where, in the latter, the bvec files are also not ordered appropriately.

The DICOM data are sent in "enhanced" format from the scanner to dcm4chee and then to my workstation. From looking at prior issues on github, I've confirmed the manufacture information is present and there are not excessive missing dicom fields.

This issue is occurring with dcm2niix version v1.0.20240202 on linux (have not tested other versions or OS).

Has anyone else experienced this? I'm sure this is a philips problem and not a dcm2niix problem, but I'm curious to know if someone can figure out the issue and potentially provide a work around option or an update to accommodate the atypical dicom format used by philips.

[neurolabusc]

Can you share a sample dataset with my institutional email. dcm2niix validation uses many Philips enhanced DICOM validation datasets including dcm_qa_enh dcm_qa_philips_dwi and dcm_qa_philips.

I do not have much experience with dcm4che settings and versions, but I have been contacted by many users who have issues with its legal but unexpected renaming, documented here. I would make two suggestions:

• Do images direct from the scanner without dcm4che improves things?
• Does the development branch (v1.0.20240202) resolve your issue? I would not be surprised if dcm4che is the root cause for issue 795.

[wtmccuddy]

Hi Chris,

Thanks for getting back to me so quickly and offering to take a look at this. I acquired a DTI and fMRI series with a phantom this morning and transferred the dicoms to a flash drive directly from the scanner console (again in enhanced format). Running dcm2niix on these dicoms produced the same error as above. I just sent the dicoms to your institutional email (re: Philips Dicom Issue).

Thanks again for looking into this!

Travis

[neurolabusc]

@wtmccuddy thanks for the exemplar. Can you re-acquire the fMRI and DTI dataset with just a few volumes (e.g. for DTI one b=0 and six directions, for fMRI 7 timepoints). It is hard for a human to parse enhanced DICOMs for huge datasets where dcmdump generates 66mb of ASCII text. Ideally also make the number of slices in a volume a different small prime number. It would also be nice to have a brief description of what was expected, e.g. the fMRI series should have "the fmri dataset was acquired with 64x64 voxels in-plane, 5 slices and 7 timepoints".

[wtmccuddy]

@neurolabusc that's a good point. I was looking at the output of dcmdump (which i just learned about) and wondering how people parse through so much data. I will reacquire and send you a more manageable dataset with the relevant descriptives (hopefully before I leave today).

In my scavenging earlier, I did find a difference in the diffusion gradient ordinations when comparing DTI scans from pre and post scanner software update (see below; the first line is pre-update and second is post update):

1178c1094
(0018,9089) FD -0.77486002445220947-0.37935000658035278\0.50564998388290405 # 24, 3
(0018,9089) FD -0.37935000658035278\-0.77486002445220947\0.50564998388290405 #  24, 3 

It appears the x and y gradients have switched places. This would explain the bvec file issues with dcm2niix (if my understanding is correct). Maybe this is also the root of the issue altogether? If so, do you know if this can be changed at the scanner?

[neurolabusc]

@wtmccuddy I do think you should contact the Philips Clinical Scientist associated with your center. Either my interpetation of DICOM is wrong (possible) or the DimensionIndexSequence (0020,9222) is not specified correctly for your datasets.

The sample fMRI dataset you provided should have 40 slices and 120 timepoints. Looking at the variance DimensionIndexValues (0020,9157) the first item is Stack ID (no variance), the second is In-Stack Position Number (1..40) and the final item is the Temporal Position Index (1..120):

(0020,9056) SH [1]                                      #   2, 1 StackID
(0020,9057) UL 1                                        #   4, 1 InStackPositionNumber
(0020,9128) UL 1                                        #   4, 1 TemporalPositionIndex
(0020,9157) UL 1\1\1                                    #  12, 3 DimensionIndexValues
...
(0020,9056) SH [1]                                      #   2, 1 StackID
(0020,9057) UL 40                                       #   4, 1 InStackPositionNumber
(0020,9128) UL 120                                      #   4, 1 TemporalPositionIndex
(0020,9157) UL 1\40\120                                 #  12, 3 DimensionIndexValues

However, the DimensionIndexSequence suggests the first item is Temporal Position Index (0020,9128), the second is Stack ID (0020,9056) and the final is In-Stack Position Number (0020,9057)

(0020,9222) SQ (Sequence with undefined length #=3)     # u/l, 1 DimensionIndexSequence
  (fffe,e000) na (Item with undefined length #=4)         # u/l, 1 Item
    (0020,9164) UI [1.3.46.670589.11.71739.5.0.8132.20240329122138181] #  50, 1 DimensionOrganizationUID
    (0020,9165) AT (0020,9128)                              #   4, 1 DimensionIndexPointer
    (0020,9167) AT (0020,9111)                              #   4, 1 FunctionalGroupPointer
    (0020,9421) LO [Temporal Position Index]                #  24, 1 DimensionDescriptionLabel
  (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
  (fffe,e000) na (Item with undefined length #=4)         # u/l, 1 Item
    (0020,9164) UI [1.3.46.670589.11.71739.5.0.8132.20240329122138181] #  50, 1 DimensionOrganizationUID
    (0020,9165) AT (0020,9056)                              #   4, 1 DimensionIndexPointer
    (0020,9167) AT (0020,9111)                              #   4, 1 FunctionalGroupPointer
    (0020,9421) LO [Stack ID]                               #   8, 1 DimensionDescriptionLabel
  (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
  (fffe,e000) na (Item with undefined length #=4)         # u/l, 1 Item
    (0020,9164) UI [1.3.46.670589.11.71739.5.0.8132.20240329122138181] #  50, 1 DimensionOrganizationUID
    (0020,9165) AT (0020,9057)                              #   4, 1 DimensionIndexPointer
    (0020,9167) AT (0020,9111)                              #   4, 1 FunctionalGroupPointer
    (0020,9421) LO [In-Stack Position Number]               #  24, 1 DimensionDescriptionLabel
  (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem

It is easy to get dcm2niix to convert your data correctly, by changing the '<' to a '>'

if (stackPositionItem < maxVariableItem)

However, it will now fail with every previous enhanced DICOM dataset I have seen, including these from Siemens, Canon and Philips. I also note that the independently developed dicm2nii also fails with your fMRI and DTI image. So if this DICOM is legal, it is extremely unconventional and I would not consider it archival quality.

[neurolabusc]

@wtmccuddy the DTI data is even more problematic. The DimensionIndexValues (0020,9157) do not distinguish between different directions of b-weighted images. This scan should have 48 slices and 49 volumes (one b=0, 48 b=1000). However, for each b=1000 slice there are 48 images that share the identical DimensionIndexValues. This is especially problematic for Philips, where the order of images stored to disk are often completely jumbled.

        (0020,9056) SH [1]                                      #   2, 1 StackID
        (0020,9057) UL 1                                        #   4, 1 InStackPositionNumber
        (0020,9128) UL 1                                        #   4, 1 TemporalPositionIndex
        (0020,9157) UL 1\1\0\0                                  #  16, 4 DimensionIndexValues
        ...
        (0020,9056) SH [1]                                      #   2, 1 StackID
        (0020,9057) UL 48                                       #   4, 1 InStackPositionNumber
        (0020,9128) UL 1                                        #   4, 1 TemporalPositionIndex
        (0020,9157) UL 1\48\1000\0                              #  16, 4 DimensionIndexValues

The only way I can see to salvage this would be to track the private tag MRImageGradientOrientationNumber (2005,1113) across all slices. Again, I really do not think these are archival quality. Adding support for this edge case would degrade the maintainabilty of dcm2niix, and I would be reluctant to do it without insight from a Philips engineer (in particular, if a diffusion image is acquired with multiple b-zeros or multiple samples of each b-weighted image, is the private tag 2005,1113 repeated across identical values or unique. If it is repeated, I am again at a loss as to how to reconstruct images where all slices from a single volume were acquired sequentially.

[wtmccuddy]

This is very helpful. I just sent our Philips contact an email. Thank you for helping better characterize the problem. I think dcm2niix is a very nifty ;) tool which has helped me streamline a number of imaging tasks. I appreciate you pointing me to the line in the script to make a change that will allow it to continue working for now.

From your experience working with the different MRI vendors, is this an issue you think might be addressed? Or are vendors typically more reluctant to make changes to the DICOM structure like this?

[neurolabusc]

@wtmccuddy thanks for the new smaller dataset. This clearly shows that 0020,9157 does not distinguish between volumes. The data should have 17 slices and 7 volumes, but only slice number is incremented with all 7 volumes for each slice sharing an identical 0020,9157. It does seem like one could use MRImageGradientOrientationNumber (2005,1413) to sort this, but this exhibits problems with valid Philips enhanced DICOM DTI data like this one. Your issue mirrors problems with Philips enhanced DICOMs reported for issue 546 - the solution there was to use the new private tag 2005,1596 that was added to Philips software (from R5.6) even though your software reports software version (0002,0013) Philips MR 111.0. Maybe @sandeepganji can provide some insight. However, I can not work out a way to seamlessly read your data without unintended consequences for existing Philips datasets.

        (0020,9056) SH [1 ]                                       # 2,1 Stack ID
        (0020,9057) UL 1                                          # 4,1 In-Stack Position Number
        (0020,9128) UL 1                                          # 4,1 Temporal Position Index
        (0020,9157) UL 1\1\0                                      # 12,1-n Dimension Index Values
...
        (0020,9056) SH [1 ]                                       # 2,1 Stack ID
        (0020,9057) UL 17                                         # 4,1 In-Stack Position Number
        (0020,9128) UL 1                                          # 4,1 Temporal Position Index
        (0020,9157) UL 1\17\0                                     # 12,1-n Dimension Index Values

[drmclem]

Hi - I would also be interested in looking into this data set or get your philips contact to contact me as well if they are already dealing with it - could you contact me directly on my philips adresss - matthew dot clemence at philips dot com ?

[wtmccuddy]

@drmclem thanks for offering to look into this. I've sent the dataset to your philips address and cc'd our hosptial Philips consultant who was recently made aware of this issue.

@neurolabusc thanks for helping me diagnose the issue and providing the info needed to move forward. Much appreciated!

[neurolabusc]

@wtmccuddy I am going to close this issue. I acknowledge that dcm2niix has issues with Philips R11.1 data. However, I believe this is because the DICOM images are not truthful. Supporting these images would likely elicit unintended consequences for legitimate data, would be vulnerable to breaking if Philips corrects their images, and would increase the burden of maintaining this codebase. I am happy to meet with the Philips engineers to resolve this and get insights into pro-active solutions. However, this needs up stream support.