No bval file produced in DWI with multi-frame Enhanced DICOM files

[dagra]

Describe the bug

I tried to convert a DWI (trace images with b-values 50 & 800) composed of 2 multi-frame (Enhanced, Siemens syngo MR XA20) DICOM files. The nifti file is produced correctly, but there is no .bval (and no .bvec which should be all 0 though) file.

The b-values exist in the DICOM files and dcm2niix finds them correctly (as can be seen also from the conversion log below).

I tried to find the reason and I saw that the following condition is True, because numDTI=1 and nConvert=2:

dcm2niix/console/nii_dicom_batch.cpp

Line 2228 in bb3a6c3

if ((numDti < 3) && (nConvert < 3))

I changed the condition to if ((numDti < 3) && (nConvert < 2)) just to check if the .bval is produced correctly and indeed it does.

But I'm not sure which is the best solution.

To reproduce

Steps to reproduce the behavior:

1. Run the command dcm2niix -v 1 . on 2 multi-frame Siemens Enhanced DICOM files.
2. Observe in the logs that the b-values have been identified correctly.
3. See the converted files and observe that there is no .bval file.

Expected behavior

The .bval file is produced correctly.

Output log

Conversion log of the latest development branch:

$ ./dcm2niix -v 1 .
Chris Rorden's dcm2niiX version v1.0.20221127  (JP2:OpenJPEG) (JP-LS:CharLS) GCC9.4.0 x86-64 (64-bit Linux)
Found 2 DICOM file(s)
DICOM file: ./1.dcm
 patient position (0020,0032)	-105.284	-81.9885	-16.9748
 orient (0020,0037)	1	4.852e-12	6.61e-13	-4.897e-12	0.99084	0.135042
 acq 0 img 1 ser 8 dim 236x236x25x1 mm 0.847458x0.847458x3 offset 139316 loc 0 valid 1 ph 0 mag 1 nDTI 1 3d 0 bits 16 littleEndian 1 echo 1 coilCRC -859211986 TE 58 TR 4970
 DWI bxyz 50 0 0 0
Warning: interpolated protocol 'resolve_diff_b50_800_tra_p2' may be unsuitable for dwidenoise/mrdegibbs. ./1.dcm
DICOM file: ./0/0.dcm
 patient position (0020,0032)	-105.284	-81.9885	-16.9748
 orient (0020,0037)	1	4.852e-12	6.61e-13	-4.897e-12	0.99084	0.135042
 acq 0 img 2 ser 8 dim 236x236x25x1 mm 0.847458x0.847458x3 offset 139354 loc 0 valid 1 ph 0 mag 1 nDTI 1 3d 0 bits 16 littleEndian 1 echo 1 coilCRC -859211986 TE 58 TR 4970
 DWI bxyz 800 0 0 0
Converting ./1.dcm
Slice timing range appears reasonable (range 0..4772, TR=4970 ms)
Convert 2 DICOM as ./_resolve_diff_b50_800_tra_p2_20221125164851_8 (236x236x25x2)
Conversion required 0.014683 seconds (0.014672 for core code).

part of dcmdump output on the first file:

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 202                                      #   4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01                                    #   2, 1 FileMetaInformationVersion
(0002,0002) UI =EnhancedMRImageStorage                  #  28, 1 MediaStorageSOPClassUID
(0002,0003) UI [XXX] #  54, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianExplicit                    #  20, 1 TransferSyntaxUID
(0002,0012) UI [1.2.826.0.1.3680043.9.3811.2.0.2]       #  32, 1 ImplementationClassUID
(0002,0013) SH [PYNETDICOM_202]                         #  14, 1 ImplementationVersionName

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
(0008,0005) CS [ISO_IR 100]                             #  10, 1 SpecificCharacterSet
(0008,0008) CS [DERIVED\PRIMARY\DIFFUSION\TRACEW]       #  32, 4 ImageType
(0018,1020) LO [syngo MR XA20]                          #  14, 1 SoftwareVersions

Version

Please report the complete version string:

• dcm2niiX version v1.0.20201207 (JP2:OpenJPEG) (JP-LS:CharLS) GCC9.3.0 x86-64 (64-bit Linux)

Troubleshooting

Please try the following steps to resolve your issue:

• Is this the latest stable release? If not, does the latest stable release resolve your issue?
  • I tried the latest stable release and the issue is not resolved.
• If the latest stable version fails, and you are using macOS or Linux. Does the latest commit on the development branch resolve your issue?
  • I tried the latest commit on the development branch and this issue is still not resolved.

[neurolabusc]

This is the desired behavior. The bval and bvec files are designed for the raw diffusion data, that a user can process to create derived values such as TRACE, ADC, FA, etc. You are exporting derived images, not raw data, and therefore dcm2niix does not generate the bval/bvec files. In general, you can generate better derived images offline after post processing the raw data (eddy, dwidenoise, degibbs, etc).

[dagra]

Yes, I know that if I had the raw diffusion data I could derive all these images, but unfortunately that's how I receive them and I don't have any control over the export configuration.

But, even the trace images, along with their b-values, are useful, especially for clinical purposes (my use case). And I generally use dcm2niix to convert them with a lot of success from various manufacturers, i.e. I successfully convert trace DWI DICOM datasets with their b-values. E.g. if I convert these images to single frame, non enhanced DICOM files, then dcm2niix produces both the .nii and the .bval.

So, given that in the other cases dcm2niix produces the .bval, but it isn't in the enhanced format (which is the recommended), I think that this behavior is inconsistent. And I know that this isn't your main case, but that's why I opened it as a bug.

Can you perhaps help me understand what is the logic of that condition? And what would be the consequences if it changed to if ((numDti < 3) && (nConvert < 2))?

Also thanks for your immediate response and all your hard work! dcm2niix is a great tool!

[neurolabusc]

I suggest you make a personal fork of dcm2niix with the changes you suggest. Including this change in the main branch would have unintended consequences on BIDS creation tools that use the bvec and bval files to detect that a image includes raw diffusion data. If you have exemplars where dcm2niix generates bvec and bval files for derived data I would encourage you to either suggest a method to detect these or (if possible) share them with me via my institutional emali so we can correctly classify them. While Siemens dominates the research space, the clinical community benefits from many competing manufacturers. Unfortunately, my hospital only has Siemens equipment, and therefore support for other manufacturers is not yet perfect. Thanks for your kind words!

[dagra]

Ok, I see. Unfortunately I don't have any suggestion right now to detect these and I can't share these datasets.

So, I will go with a personal fork then. Just to be certain, because I don't have a full understanding of the code, the only consequence of that change will be that .bval & .bvec files are gonna be produced even when the number of source DICOM files is 2, right? Because nConvert signifies the number of DICOM files and numDti the discovered (until that point) number of volumes of the DTI?

[neurolabusc]

Reviewing this, I do think the behavior of dcm2niix has become inconsistent across sequences and manufacturers since we added this patch in response to your issue 405. Historically, dcm2niix would consistently not store bval/bvec files for derived images. Now it will save bvec and bval files if there are at least 3 volumes.

I wonder if the most parsimonious solution is to change the conditional to read:

if ((numDti < 2) && (nConvert < 2)) 

This will ensure that bvec/bval files are not created for the common case where a user acquires just a single volume b=0 volume spin echo sequence to undistort a gradient echo sequence, yet still help you identify the b-value for derived datasets.

I suspect this change will have little change on most research uses. However, I wonder if large clinical users like @captainnova have any thoughts.

[captainnova]

Hi, I had noticed and been mildly annoyed by this, but had not gotten around to doing much of anything about it.

Many studies acquire a shorter scan with flipped phase encoding to correct EPI distortion. One study, against my advice, boiled it down to just the b=0 volume(s), which works for the purpose but produces a diffusion weighted scan that isn't diffusion weighted. If there's no .bval and .bvec it can be hard to find these and match them up with the long dMRI they are supposed to correct.

OTOH, XA has started producing average (TRACE) images for each b > 0 shell, and annoying as that is when the main intent was to acquire a DTI, or DKI, etc., I agree with @dagra that dcm2niix should produce .bval and .bvec files for them, with the .bvec set to 0 0 0. @neurolabusc is correct that they should be ignored when the full data is available, but that is often not the case for DWIs, and DWIs are sometimes used in research. My understanding is that prostate exams often acquire many 3 direction b "shells", and only use the trace images, and because there are so many different bs the .bval is important. In dementia research they are used to check for edema and hemorrhaging in drug studies, especially since amyloid clearing drugs have those side effects in about 20% of participants, at least at current doses. To facilitate frequent monitoring with a large cohort, typically the participants interleave ~annual research quality exams at a major academic center with quick safety exams at small local clinics every few months. DWIs are more cost effective than DTIs for checking for edema, and minimizing the protocol and data transfer wrangling with the non-research sites is well worth it. They always want the derived images, because they do not have the software and inclination to deal with dMRI pipelines, and they typically discard the 4D data if the scanner even writes it.

In practice it comes down to running a type guesser to catch scanner derived series like TRACE and ADC, and then checking for the given study whether it's OK to ignore them. Because of the short flipped encoding scans, we can't assume that short scans are clinical DWIs. It's better to check whether the first word of (0008, 0008) (ImageType) is DERIVED, but unfortunately Philips breaks that rule, or at least they used to.

[dagra]

I wonder if the most parsimonious solution is to change the conditional to read:

Yes, in my understanding this is a good solution.

The commit seems good, thank you for resolving it!

A couple of FYI notes regarding the inconcistencies:

I do think the behavior of dcm2niix has become inconsistent across sequences and manufacturers since we added this patch in response to your #405.

I want to note on this, that the inconsistency was not introduced by the patch required for issue 405. More specifically, I had tested some trace datasets from various manufacturers (Siemens, GE, Philips) with 2 versions of dcm2niix at that time, the v1.0.20190410 (which I cannot find in the releases) and the v1.0.20200331. In the release v1.0.20190410 there were no bvals/bvecs for the trace datasets, but in the release v1.0.20200331 bvals/bvecs were produced for the GE and Siemens (single-frame, not enhanced) datasets, but not for the Philips.

Now it will save bvec and bval files if there are at least 3 volumes

This is also not entirely correct, because, as I mentioned in the previous comment, if the DICOM files are single-frame, then the bvals/bvecs will be produced, even for 2 volumes, because nConvert can be greater than 3 (e.g. if there are 20 frames for each volume, then there will be 40 files and nConvert=40). The "at least 3 volumes" is true, as far as I can tell, only when the data are exported in the Enhanced multi-frame format, where the number of files equals the number of volumes.

Again, thank you for reviewing and resolving it!

[neurolabusc]

@dagra In the future it might be worth adding a command line switch that generates bval files for derived images. I think we are overdue for a new release, so I want to defer that until when we are earlier in the development cycle.

[dagra]

Yes, I agree that a command line option would probably be the best solution, since only a fraction of the users is interested in it.

I'd be happy to help, however I can, whenever you schedule this, so feel free to mention me.