incorrect pixdim3 in nifti header for philips dwi data #546
Comments
|
Please provide exemplar |
|
Great, thanks. I sent an email linking to the data. |
|
@psadil I have never seen a Philips classic DICOM like this.
Your present data is easy to compensate for, but we should make sure that our decisions do not have unintended consequences. The issues are:
I think @sandeepganji is uniquely placed to resolve this. I actually think the data he already provided allows us to validate this. His series 23 is sort of the inverse of yours: it acquires multiple volumes with identical near zero b-values (b=2), but uses different gradient directions for each. This further supports the notion that Philips does not allow you to acquire two volumes with identical b-value and direction in the same series (which is good news for us, as it provides a method to extract them). I am committing a patch that illustrates the fix, but please consider it tentative until Sandeep confirms our questions and we decide on the order of sorting. I think that my current kludge will restore the diffusion volume order seen for classic DICOMs in prior releases, but has the consequence that it save volume order differently for classic and enhanced DICOMs. If we can confirm one of these orders is the correct temporal one, we can make both formats consistent. Worth notifying @captainnova as he is a world leader on these issues, and may have opinions. Below are the relevant DICOM tags for the first 36 slices (ordered by instance number) to provide a concrete example of the issue:
|
|
Ha, I would say I am more of a world follower. But this did pique my interest and I do have lots of opinions and questions. Since gradient cooling is apparently a big problem for wide-bore dMRI, I would not be surprised if Philips added an option to switch the b vectors between successive slices, as GE has already done. In that case each volume would have several GradientOrientationNumbers, and each GradientOrientationNumber would be scattered across several volumes. (Since that is controversial, it should be an option.) Or as @neurolabusc suggested, it could simply be a way to allow multiple b=0 volumes, which the one-to-one GradientOrientationNumber to volume scheme does not support (without using the small b trick). Either way, it seems like the days of the one-to-one GradientOrientationNumber to volume scheme are probably numbered. @psadil, do you have access to the enhanced DICOM version of this scan? Would that avoid the problem? If Philips is planning to add a scheme other than the one-to-one GradientOrientationNumber to volume scheme, they could help by
|
|
@captainnova Thanks for the insight! For this participant, it may be possible to get the enhanced DICOM version, though it isn't guaranteed. Unfortunately, for the rest of the data enhanced versions will not be available. But please let me know if the enhanced version of this example would help, e.g., validate a patch. |
|
@psadil seeing a single example of a scan with this setup in both classic and enhanced would help. |
|
@neurolabusc, okay. I'll check and will report back when I know whether a scan in both classic and enhanced versions could be available |
|
@psadil and @captainnova I am now ready to close this issue. For the Fall 2021 release, Philips enhanced DICOM diffusion volumes will be sorted as instructed by the Dimension Index Values (0020,9157). On the other hand, for classic DICOMs, volumes with identical b-value index (2005,1412) will be stored sequentially, with ties sorted based on gradient direction number (2005,1413). This order should be identical to prior releases of dcm2niix. However, the new release is robust against classic data where the instance number (0020,0013) is jumbled. The DICOM standard does not require meaningful instance numbers, though in my experience all other manufacturers and many tools do provide/expect sequential instance numbers. Since different algorithms are used, the order of volumes for Philips diffusion may differ depending on whether the data is stored as classic or enhanced DICOM. As @captainnova notes, for many sequences it is probable that neither order matches the true temporal order that data were acquired. Users of Philips data will need to be cautious if the processing tools make assumptions about head motion or T1 effects based on the order that data is stored to disk. This is a limitation of the Philips image data, not dcm2niix. Perhaps future releases of dcm2niix will be able to parse the data Philips stores in non-image DICOM files (though I am aware these often are not retained by PACS systems). Thanks to James Ford at Dartmouth for supplying an example of a sequence exhibiting these attributes that was saved as both classic and enhanced data. |
|
@sandeepganji noted that recent Philips software (from R5.6) includes a new tag 2005,1596 for diffusion data that provides the acquired temporal order of volumes. Thanks to Paul Morgan for providing a public validation dataset. This method is now used for both enhanced and classic DICOMs. The validation dataset includes text to describe how dcm2niix handles older data. |
* tag 'v1.0.20211006': Update dcm_qa submodule. Unify PASL JSON tags. Extract volume order for Philips DWI (from R5.6 onward) Version bump, describe issue 546 in documentation Remove warning for early GE HyperBand dataset after validation Handle enhanced DICOM using syntax 1.2.840.10008.1.2.4.70 Use both 2005,1412 and 2005,1413 to sort Philips DWI (rordenlab#546) GE early HyperBand Slice Times for early GE HyperBand fMRI Issue 544 (rordenlab#544) Yet another attempt to use packed structures for Windows MSVC 19 and UNIX. Support packed structs for Windows and Unix (https://newbedev.com/visual-c-equivalent-of-gcc-s-attribute-packed) Experimental support for MGH format export DWI vector removal detection (rordenlab#542) Verbose = 2 will report ProtocolBlockGE (0025,101B) for all GE scans (not only if slice timing is calculated) Typos found by codespell Never equalize slices if slices have been rotated issue 539 (rordenlab#539) Set repetitionTimePreparation for known ASL sequences, reduce verbosity of slice re-ordering, improve ECAT success/failure warnings. Update issue templates
Describe the issue
The release candidate constructs Philips DWI images strangely, but not previous stable version. It seems to be estimating pixdim3 incorrectly.
To reproduce
cmakedcm2niixv1.0.20210317andv1.0.20210928fsleyesandfslinfov1.0.20210317v1.0.20210928Expected behavior
In both cases, pixdim3 == 1.7
Output log
In the console output, I'm seeing a bunch of errors like
but from what I see only the DWI images end up with incorrect pixdim3
Output from previous stable version
And for release candidate:
Version
okay dwi: v1.0.20210317 GCC9.3.0 x86-64 (64-bit Linux) (e973e0f)
poor dwi: v1.0.20210928 GCC9.3.0 x86-64 (64-bit Linux) (001336f),
This was first observed because I was looking at using v1.0.202100811 for it's handling of GE fieldmap data. That version also produced niftis with incorrect pixdim3 on the Philips data.
Troubleshooting
If it would help, an example dataset may be shareable.
The text was updated successfully, but these errors were encountered: