Comments (11)
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.
from dcm2niix.
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
from dcm2niix.
@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".
from dcm2niix.
@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?
from dcm2niix.
@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.
from dcm2niix.
@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.
from dcm2niix.
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?
from dcm2niix.
@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
from dcm2niix.
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 ?
from dcm2niix.
@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!
from dcm2niix.
@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.
from dcm2niix.
Related Issues (20)
- Filename oddity in 20240202 for Philips DWI HOT 10
- GE UHP/7T Diffusion SliceTiming HOT 5
- Possible incorrect SliceTiming HOT 16
- Siemens conversion problems (Magnetom Altea) HOT 2
- error dcm2niix using dcm2bids HOT 1
- PET json information HOT 12
- Inquiry on DICOM to NIfTi HOT 4
- Siemens 2D epi TR is incorrect HOT 2
- dcm2niix is incorrectly attempting to use a JPEG:Lossless transfer syntax that was set inside an Original Attributes Sequence HOT 1
- GE AcquisitionDuration HOT 6
- Return status bug (incorrectly reported error) v1.0.20240202 HOT 12
- How does dcm2niix determine SBREF dicom files? HOT 3
- [Question] Image dimensions from the tags HOT 2
- -x flag not working on PAR file HOT 3
- Siemens XA60 conversion of diffusion data HOT 1
- multi-echo data not recognised
- Incorrect output files name for a duel echo image. HOT 1
- The whole image is inverted in the result of the dcm2nii.gz conversion HOT 3
- RepetitionTime is sometimes incorrectly calculated HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dcm2niix.