Incorrect Slice/Vol Order After Site Updated Philips Software (Ingenia version 11.1) #809
Comments
|
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:
|
|
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 |
|
@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". |
|
@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): 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? |
|
@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 However, the DimensionIndexSequence suggests the first item is It is easy to get dcm2niix to convert your data correctly, by changing the '<' to a '>' 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. |
|
@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. 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. |
|
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? |
|
@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) |
|
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 ? |
|
@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! |
|
@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. |
|
Hi, I think this ticket probably needs to be reopened, although "support Philips 11" is more of a feature request than a bug report, and I realize @neurolabusc is in the middle of wrapping up the fall release. We have started receiving DWIs from a Philips 11 scanner in Boston, and dcm2niix is stacking the slices in the wrong order if the DICOM is enhanced. It reminds me of the early days of Siemens XA, i.e. there will be more data like this coming. If @drmclem, @sandeepganji, or anyone else at Philips could advise, I would really appreciate it. It seems like there might be a compatibility problem between Philips 11 and their older DICOM versions that will need to be acknowledged, but I don't have access to Philips 11 myself or the bandwidth to blindly reverse engineer it. Unenhancing it with dcuncat corrects the stacking, but it adds 7000 to the series number and messes up the "_ADC.nii" image a bit: Normally dcm2niix would kindly shunt the b shell averages ("traces") away from the main output .nii and into a ..._ADC.nii image. In this case (post-dcuncat) it is correctly writing the b = 0 + x, y, z b=1000 volumes to the main.nii, but writing all 5 volumes (ORIGINAL data + the DERIVED b = 1000 average) to the _ADC.nii. I can easily work around that since we never use the _ADC.nii anyway, but the series number change is annoying. dcuncat is completely to blame for that, but it probably has an option to prevent that that I just haven't found yet. But I'd hate to go back to dcuncatting enhanced DICOM; it looks like Philips 11 might have fixed the oververbosity problem. I can't share the data in hand, but we can probably get the site to scan a phantom if we need it and ask nicely. In the meantime I would be happy to run dcmdump, etc. on the DWIs we've received and report the results. For this 40 slice x (4 original + 1 derived) volume DWI, using the original enhanced DICOM, |
|
@drmclem, @sandeepganji, I do not have access to Philips 11 hardware, so we will need a shared dataset that exhibits the issue, or someone who does have access will need to make a pull request with a patch. I do think it is poor form to store |
|
To be fair, Philips is still not actually labeling the trace volume as DERIVED using (0008, 0008) Image Type. But to be fair, they should. |
|
Hi, we would like to reopen this, and I have talked to Spencer Waddle at Philips about helping. Hopefully we can locally scan a phantom with R11, but that is TBD. |
|
Rob, on MR61 at OPUS we have the following SW releases available on the scanner (R56, R57, R58, R11.1.1.0 and R12.1.0). |
|
Thanks, Sandeep. I had no trouble finding volunteers in Opus, so hopefully Spencer and I can get one scanned in the next few days. |
|
IM_0033.csv is a table of the b vector, Stack ID, etc. for each frame in an R11 enhanced DTI, in order of appearance. I agree with @neurolabusc 's comment on Mar. 30, 2024 that the way I thought slices were supposed to be indexed in enhanced DICOM is not working here. The Dimension Index Value has only two elements that vary; the 2nd one is the In-Stack Position Number which indexes z, and the 3rd is the b value, which crucially is not unique. (And not an index - that seems to violate https://dicom.innolitics.com/ciods/breast-projection-x-ray-image/breast-projection-x-ray-image-multi-frame-functional-groups/52009229/00209111/00209157 ). So some non-standard info is needed to break the degeneracy, like the Diffusion Gradient Orientation. I think @neurolabusc mentioned a private tag which could work like an easier to use index for that. @sandeepganji or @drmclem , is there a tag we should be using? @neurolabusc , the data we acquired does not include multiple b=0 volumes as you requested. I think that is actually impossible with Philips, for the related reason that they require every b vector (with magnitude) to be unique. To approximate multiple b = 0 volumes in ADNI we used a b = 0 + several b = 2 s/mm^2 vectors in a tiny dodecahedron. In hindsight I suppose we should have tried Nex > 1 with R11 to see what would happen, but I'd forgotten how this detail would interact with the problem. |
|
Here is an updated version of the same enhanced DICOM with columns added for I tried diffing two subsequent frames and found some other tags that vary, but they do not immediately indicate which volume a frame belongs to: |
|
Rob, just send a calendar invite to you for 1 pm your time today. It's a
zoom link.
-S
…On Fri, Feb 21, 2025 at 12:27 PM Rob Reid ***@***.***> wrote:
Here is an updated version of the same enhanced DICOM with columns added
for
(2005, 1113) MRImageGradientOrientationNumber and
(0020, 0013) InstanceNumber:
IM_0033.csv
<https://github.com/user-attachments/files/18913053/IM_0033.csv>
I tried diffing two subsequent frames and found some other tags that vary,
but they do not immediately indicate which volume a frame belongs to:
(0028, 1050): Window Center
(0028, 1051): Window Width
(0008, 0018): SOPInstanceUID (I wonder if dcuncat uses this)
(2001, 1004): Seems to be a weird letter code for each b vector
(2005, 100b): Unknown float
—
Reply to this email directly, view it on GitHub
<#809 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4QESSZB77RUQYBBMM474T2Q5OYNAVCNFSM6AAAAABRL5NMUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZVGE2DAMJQGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: captainnova]*captainnova* left a comment (rordenlab/dcm2niix#809)
<#809 (comment)>
Here is an updated version of the same enhanced DICOM with columns added
for
(2005, 1113) MRImageGradientOrientationNumber and
(0020, 0013) InstanceNumber:
IM_0033.csv
<https://github.com/user-attachments/files/18913053/IM_0033.csv>
I tried diffing two subsequent frames and found some other tags that vary,
but they do not immediately indicate which volume a frame belongs to:
(0028, 1050): Window Center
(0028, 1051): Window Width
(0008, 0018): SOPInstanceUID (I wonder if dcuncat uses this)
(2001, 1004): Seems to be a weird letter code for each b vector
(2005, 100b): Unknown float
—
Reply to this email directly, view it on GitHub
<#809 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4QESSZB77RUQYBBMM474T2Q5OYNAVCNFSM6AAAAABRL5NMUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZVGE2DAMJQGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@captainnova the latest commit to the development branch (v1.0.20250303) provides a kludge that attempts to accurately sort Philips DICOM DWI data from Philips 11.1 software. While this may work, it does only converts the images to NIfTI and does not attempt to patch the Dimension Index Values (0020,9157) in the source DICOMs. The raw DICOMs are clearly not of archival quality and you will want to work with the manufacturer to mitigate the source errors. The kludge is specific to Philips, but I have limited access to data from this vendor, so the opportunity for unintended consequences remains high. It would be great to work with Philips to work out the first and last software release to exhibit this issue, so the kludge can only be applied to the affected images and avoid impacting valid DICOM images from Philips scanners. Do please test this carefully with your large dataset. Thanks for the concrete examples and diagnosis. For the record, the affected images I have seen report: 
|
|
FWIW we experience the same issue with Philips enhanced DICOM. The tag (0002,0013) is 'Philips MR 57.0'.
|
git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix /path/to/DICOMs
|
Thank you @neurolabusc! That's a very pretty pineapple and agrees with non-Philips pineapple scans I've done. I also confirmed that the kludge works with human DWI data from A345. The directional diffusion is a bit clearer and more specific in humans, so it is good to see that it works too. It also resolved the missing .bval/.bvec problem we were having with that site. Unfortunately, and as expected, the kludge did not help with fMRI. A [64, 64, 48, 200] scan came out with the correct shape, but still in XYTZ order, so the 0th volume is 48 slices from the neck, the 1st volume 48 slightly later instances from the same slice, and so on, eventually making its way to the top of the head in the 199th volume. Apparently dcm2niix initially thought it was a DWI and said so, but by the time it got to the BidsGuess it knew it was an fMRI: |
Thanks for your suggestions!
|
|
Hi Chris and Rob et al., I am new to this discussion, but the same issue has just started to bite me as I try to deal with ASL data from the same MR studies in ADNI de-facing and subsequent converting de-faced nii back to dicom using the original DICOM.
While this is unconventional and making my life difficult too, I think it stems from an ambiguity in the DICOM standard where Philips is reading it differently than others.
The language is ambiguous in "the order of Dimension Index Pointers in Dimension Index Sequence". It could mean that we sort by Dimension Index Pointer, rather than use the ordering as-written. Using that interpretation, if we sort by the tag numbers in Dimension Index Pointer, their DICOM becomes self-consistent. Sorting by DimensionIndexPointer, we get first (0020,9056); (0020,9057); (0020,9128), which matches what they've put in DimensionIndexValues. I find the language a little ambiguous enough to support either meaning, honestly, but the "sort by DimensionIndexPointer" interpretation seems to be what Philips did. Would sorting Dimension Index Sequence by DimensionIndexPointer values break other DICOM? IF (and a big if...) everything else uses tag-number order to begin with, then perhaps this sort step would fix these images without hard-coding an ordering and without breaking others. Maybe? |
|
@CGSchwarzMayo the issue is not the precedence of the order, the challenge is that Philips does not disambiguate between slices in a series.So different slices are provided identical values. |
|
Interesting. It seems like the dMRMI/fMRI series are more broken than the ASLs I'm dealing with. I think at this point I'm just reporting the status with ASL. For my examples, DimensionIndexValues are While DimensionIndexSequence is The order differs, but sorting by tag number makes them self-consistent. Do you any opinion or insight from other vendors on which interpretation of the DICOM standard is more common/valid? (2005, 0029) is missing in these DICOM, but it's impossible for me to know in these ADNI images if I have DICOM as-written or this tag was lost in later anon/transfer steps. If (2005, 0029) was very recently invented then it's very likely LONI removed them during anon. Rob and I could work with LONI to confirm and fix for future uploads, if needed. Edit: I emailed LONI and I will update on what they say about this. For these images, dcm2niix v1.0.20240327 conflates the dimension ordering, and we get a nii where the first volume is the first half S/I and the second volume is the second half. dcm2niix after dcuncat works fine, as Rob reported for the other series. I have not yet tested whether a293cde fixes them, but I will do this once Rob returns and compiles it later this week. |
|
Minor update: Rob informed me of an existing build of v1.0.20250303 and these ASL's are still broken in the same way. Are you able to say whether dcm2niix would have read (2005, 0029) (referenced from DimensionIndexSequence) if it had existed? If it would have read that tag, probably these images would have worked if the tag weren't removed upstream. If not, then we might need to scan a phantom with the ASL and get that to you. |
|
Actually, a293cde was 3/4 and Rob gave me the build from 3/3, so really, nevermind for now... Sorry. |
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.
The text was updated successfully, but these errors were encountered: