Issues with Spinal Cord Scans

[duettwe]

Describe the bug
We have a user encountering an issue with spinal cord scans on more recent versions of dcm2niix. He's tested it on 2 different scans. I can privately provide the DICOM files by box link. Here's the information he provided:

Any scan that has "dti_2min_b1000" is the brain. Scan numbers 9 and 10. These all work good. I can grab DICOM directly, or any of the 4 DCM2NII conversions on gstudy. All work perfectly.

Any scan that has "DTI_1.1med_ovs" is spinal cord. A good example to test would be scan 07 (or 701 depending on conversion). This "should" be a mix of 1b0, 16 b=1000, 16 b=2000. I have tried my own DCM2NIIX, as well as the 3 on gstudy. All give very weird results (meaning seperating into 3 scans, none actually indicate a b=2000, some have 6 b0's, some have 10 b=1000 and nothing else). However, the vintage conversion works great! I have no idea why this is...but the vintage conversion gives me one NII, one b-value set, and one b-vector set...all seem correct!

To Reproduce
Steps to reproduce the behavior:

$ /scratch/<user>/v1.0.20210317/console/dcm2niix /scratch/<user>/DICOM
Chris Rorden's dcm2niiX version v1.0.20210317  GCC4.8.5 x86-64 (64-bit Linux)
Found 2 DICOM file(s)
Note: B0 not the first volume in the series (FSL eddy reference volume is 64)
Warning: Saving 65 DTI gradients. Validate vectors (image slice orientation not reported, e.g. 2001,100B).
Philips Scaling Values RS:RI:SS = 3.61612:0:0.0134806 (see PMC3998685)
Convert 1 DICOM as /scratch/<user>/DICOM/DICOM_WIP_dti_2min_b1000app_20210401143125_901 (128x128x70x65)
Warning: This diffusion series does not have a B0 (reference) volume
Warning: Saving 9 DTI gradients. Validate vectors (image slice orientation not reported, e.g. 2001,100B).
Philips Scaling Values RS:RI:SS = 1.43516:0:0.374569 (see PMC3998685)
Convert 1 DICOM as /scratch/<user>/DICOM/DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t190 (256x256x20x9)
Philips Scaling Values RS:RI:SS = 1.43516:0:0.374569 (see PMC3998685)
Convert 1 DICOM as /scratch/<user>/DICOM/DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t496 (256x256x20x11)
Philips Scaling Values RS:RI:SS = 1.43516:0:0.374569 (see PMC3998685)
Convert 1 DICOM as /scratch/<user>/DICOM/DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t343 (256x256x20x13)
Conversion required 1.803227 seconds (1.440000 for core code).

$ cd /scratch/<user>/DICOM/
$ ls
1.3.46.670589.11.17240.5.0.5656.2021040114312537000-701-1-85pte6.dcm   
1.3.46.670589.11.17240.5.0.5656.2021040114312537000-901-1-1nwmekv.dcm  
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t190.bval
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t190.bvec                     
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t190.json 
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t190.nii  
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t343.bval   
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t343.bvec 
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t343.json
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t343.nii
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t496.bval
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t496.bvec
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t496.json
DICOM_WIP_DTI_1.1med_ovs_20210401143125_701_t496.nii
DICOM_WIP_dti_2min_b1000app_20210401143125_901.bval
DICOM_WIP_dti_2min_b1000app_20210401143125_901.bvec
DICOM_WIP_dti_2min_b1000app_20210401143125_901.json
DICOM_WIP_dti_2min_b1000app_20210401143125_901.nii

Expected behavior
This "should" be a mix of 1b0, 16 b=1000, 16 b=2000.

Output Log
See Above

** Version (please complete the following information):**

• dcm2niix version string, e.g. dcm2niiX version v1.0.20201207 Clang12.0.0 ARM (64-bit MacOS) The version string is always the first line generated when dcm2niix is run.
  See above
• Is this the latest stable release? If not, does the latest stable release resolve your issue?
  See above
• If the latest stable version fails, and you are using macOS or Linux. Does the latest commit on the development branch resolve your issue?
  No

[baxpr]

Dimensions are labeled as diffusion related:

(0020,9222) DimensionIndexSequence
    (0020,9421) LO [Stack ID]
    (0020,9421) LO [In-Stack Position Number]
    (0020,9421) LO [Diffusion b-Value]
    (0020,9421) LO [Diffusion Gradient Orientation]

But this DICOM also has:

        (0020,9153) FD 343                                      #   8, 1 NominalCardiacTriggerDelayTime
        (0018,1060) DS [343]                                    #   4, 1 TriggerTime

The trigger time field may be related to some custom pulse sequence program? Not sure. Maybe dcm2niix is prioritizing the trigger time to split volumes, but we need it to prioritize the diffusion info?

[neurolabusc]

The sequence is labeled as a WIP (work in progress) not a product sequence. These often have all sorts of custom interpretations of the DICOM standard. I am assuming this is from a Philips scanner. As @baxpr notes, it does look like the sequence does define that different volumes use a different trigger times. It does seem appropriate to segment volumes by trigger time, right? Feel free to send me a sample. My sense is that these scans explicitly report different trigger times, so dcm2niix is separating based on this feature.

[neurolabusc]

Your images do specify different trigger times in 0018,1060 and 0020,9153. The expected behavior in these cases is to segment the scans, which is admittedly a tough task with these enhanced DICOMs. This looks very similar to issue 395 where changing dcm2niix to handle single customer solutions which are not part of the Philips product would lead to widespread unintended consequences.

I would suggest you consider one of two solutions:

1. Fork dcm2niix and modify it to handle your images. You would do this by adding two lines of code, though you would need to be careful where trigger time was a meaningful value:

case kTriggerTime: {
	if (d.manufacturer == kMANUFACTURER_PHILIPS) break;//issue499
...
case kTriggerDelayTime: { //0x0020+uint32_t(0x9153<< 16 ) //FD
	if (d.manufacturer == kMANUFACTURER_PHILIPS) break;//issue499

2. Remove the offending tags from these sequences. If these tags are erroneous, they should be removed from the images:

gdcmanon --dumb --empty 0018,1060 --empty 0020,9153 in.dcm out.dcm

[baxpr]

@neurolabusc thanks much! We can apply either of those solutions, so that gets us past the hurdle.

What do you think about something like an --ignore_trigger_times command line option for dcm2niix? Is that likely to be generally useful, or would it just be addressing this one weird edge case?

[neurolabusc]

@baxpr and @duettwe can you test out the latest development version (v1.0.20210403). It includes experimental support for the --ignore_trigger_times option:

./dcm2niix --ignore_trigger_times ~/Neuro/issue499                      
Chris Rorden's dcm2niiX version v1.0.20210403  Clang12.0.0 ARM (64-bit MacOS)
ignore_trigger_times may have unintended consequences (issue 499)
Found 1 DICOM file(s)
Note: B0 not the first volume in the series (FSL eddy reference volume is 30)
Note: 2 volumes appear to be ADC or trace images that will be removed to allow processing
Warning: Saving 31 DTI gradients. Validate vectors (image slice orientation not reported, e.g. 2001,100B).
Philips Scaling Values RS:RI:SS = 1.43516:0:0.374569 (see PMC3998685)
Convert 1 DICOM as /Users/chrisrorden/Neuro/issue499/issue499_WIP_DTI_1.1med_ovs_20210401143125_701 (256x256x20x33)
Conversion required 0.369031 seconds (0.290848 for core code).

[drmclem]

Hi @duettwe - I would be interested to know how the sequence is set up - I assume you are using cardiac triggering to minimise phsyiological noise in the spinal cord due to pulseatile flow - we can set up dual triggered scans as part of the default software but haven't seen this use case in the wild - would be good to know if this is a custom feature or not.

[baxpr]

@drmclem from Seth Smith, his best, and -

This is a cardiac triggered sequence, so no funny business. The trigger is being used as a true trigger. However, there are 3 NSA so it is possible that each NSA reports a trigger time. Single trigger, not dual. Trigger set to 127ms delay post max.

Please reach out directly if you have more questions.