b-value is 0 for 6 different slices

[olirwin]

I am running into a slight problem using the program.
I tried converting a 20x11 dicom folder, each series with a different b-value
The b-values should be 0 10 20 30 40 50 80 100 200 400 800
What I get in bval files is 0 0 0 0 0 0 80 100 200 400 800

The files don't seem to be the problem here, I've double checked, and I can't find a missing fields in the incriminated files

[neurolabusc]

You are not giving me much to work with here. Can you tell me the vendor (Siemens, Philips or GE) and confirm you are running the latest release (v1.0.20200331)? Also, can you report the output generated during conversion. There seem to be two options:

1. If dcm2niix generates the warning Assuming volumes without gradients are actually B=0 this means that your scanner did report b-values of 10, 20, 30, 50 but that each of these volumes reported a b-vector of [0,0,0]. Therefore, the b-value is provided without context. A non-zero scalar b-value without a direction does not make sense.
2. If this error was not generated, it suggests that your scanner recorded the b-value as 0 for the low b-value sequences. As I recall, the Siemens product DWI sequences tends to zero small requested b-values (reporting b-value = 0), in contrast the CMRR sequences report the applied gradient (e.g. a user might request 0, but CMRR will report the applied value of 5, 10, 15 and can also report variability of b-values across gradient directions).

In brief, I expect this reflects inherent properties of the DICOM data. Each vendor uses its own tags to report diffusion gradients, but I suspect that if you look at the combination of reported b-value and diffusion direction it will explain the behavior of dcm2niix.

[olirwin]

Sorry for the lack of information, I wrote this issue quickly before leaving the office.

Vendor is Siemens, I am running version v1.0.20200331

Conversion output is as follows :

Compression will be faster with 'pigz' installed
Chris Rorden's dcm2niiX version v1.0.20200331  (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.5.0 (64-bit Linux)
Saving defaults file /home/user/.dcm2nii.ini
Found 220 DICOM file(s)
Image Decompression is new: please validate conversions
Warning: Slice timing appears corrupted (range 0..0, TR=4210 ms)
Convert 20 DICOM as anfdata/dcm_11b_20001a (144x144x20x1)
Warning: Slice timing appears corrupted (range 109465..109465, TR=4210 ms)
Convert 20 DICOM as anfdata/dcm_11b_20003a (144x144x20x1)
Warning: Slice timing appears corrupted (range 126305..126305, TR=4210 ms)
Convert 20 DICOM as anfdata/dcm_11b_20005a (144x144x20x1)
Warning: Slice timing appears corrupted (range 143148..143148, TR=4210 ms)
Warning: This diffusion series does not have a B0 (reference) volume
Convert 20 DICOM as anfdata/dcm_11b_20007a (144x144x20x1)
Warning: Slice timing appears corrupted (range 117885..117885, TR=4210 ms)
Convert 20 DICOM as anfdata/dcm_11b_20004a (144x144x20x1)
Warning: Slice timing appears corrupted (range 269452..269452, TR=4210 ms)
Warning: This diffusion series does not have a B0 (reference) volume
Convert 20 DICOM as anfdata/dcm_11b_20010a (144x144x20x1)
Warning: Slice timing appears corrupted (range 134725..134725, TR=4210 ms)
Convert 20 DICOM as anfdata/dcm_11b_20006a (144x144x20x1)
Warning: Slice timing appears corrupted (range 244190..244190, TR=4210 ms)
Warning: This diffusion series does not have a B0 (reference) volume
Convert 20 DICOM as anfdata/dcm_11b_20009a (144x144x20x1)
Warning: Slice timing appears corrupted (range 185248..185248, TR=4210 ms)
Warning: This diffusion series does not have a B0 (reference) volume
Convert 20 DICOM as anfdata/dcm_11b_20008a (144x144x20x1)
Warning: Slice timing appears corrupted (range 294712..294712, TR=4210 ms)
Warning: This diffusion series does not have a B0 (reference) volume
Convert 20 DICOM as anfdata/dcm_11b_20011a (144x144x20x1)
Warning: Slice timing appears corrupted (range 101045..101045, TR=4210 ms)
Convert 20 DICOM as anfdata/dcm_11b_20002a (144x144x20x1)
Conversion required 5.807106 seconds (0.963896 for core code).

This is my first time using the tool, I may not be using it at 100% of it's possibilities, and I might be missing an option. (Sidenote, is it possible to join all the nifti files into one 4D file ?)
My colleague however confimed that we have in the dicom header

(0019,100C) : IS   Len: 2      <Unknown Tag>                  Value: [10]

It might be the "Unknown tag" though, but it is so for all the files, and the last 5have no problem beeing read... What does seem strange to me is that for b-values over 80, it works fine, but not the first six files

[neurolabusc]

Given that the private tag 0019,100c stores the B-Value I am going assume your data is from a Siemens system. For your B=10 image, Is the gradient direction tag 0019,100e present and reporting a unit vector?

(0019,100c) IS [10]
(0019,100e) FD [0.41, -0.40, -0.81]

If not, this explains the behavior of dcm2niix.

Regardless, the output makes me concerned that the DICOM data is insufficient for conversion.

1. If this data is from a Siemens XA10 or XA11 series system, you will need to re-export the data as enhanced DICOM, as classic DICOMs are stripped of most meta data.

2. If this is a V-series system (e.g VB17, VE11, etc), the CSA header is missing. This would explain the lack of slice timings reported, but would also remove additional critical meta data. This presumably reflects an over-aggressive anonymization stage. The solution would be to convert DICOMs where the CSA header is intact.

Both of these scenarios suggest a limitation of the DICOM images, not of dcm2niix.

Feel free to send a sample dataset to me via Box, DropBox, Google drive to the email in my avatar.

[olirwin]

The data is from a Siemens XA11 series system, I'll have to see with the physicist to reexport the data if that is the problem.

For the B=10 image, I get this in the dicom dump :

 | (0019,100C) : IS   Len: 2      <Unknown Tag>                  Value: [10]
 | (0019,100D) : CS   Len: 8      <Unknown Tag>                  Value: [BMATRIX ]
 | (0019,100E) : FD   Len: 24     <Unknown Tag>                  Value: [-0.577350 0.577350 0.577350 ]

I don't have a vector for b=0 though

(sorry if this feels like stupid, it's my first time handling dicom and nii files)

[neurolabusc]

1. For Siemens XA it is crucial that you export data in enhanced format. This is not a limitation of my software, but of the impoverished DICOM images created with any other selection. As Siemens notes we highly recommend that the Enhanced DICOM format be used. This is because this format retains far more information in the header. You should contact your Siemens Research Collaboration manager and lobby them to provide the meta data required for comprehensive analysis. I have been advocating for this since 2017, but do not have an XA system at my site. Further, I would make future software upgrade payments contingent on better support (e.g. rich meta data should either be stored in a DICOM image or users should be provided with a dialog that ensures they are aware that their export selection will result in impoverished data). I am aware that many sites have lost data with the current implementation.

2. For your aim of examining different B-values using the Siemens product DWI sequence, it is crucial that you either
   a. acquire all the images in a single series (which will export to a single NIfTI file, which you requested), e.g. such that a single series includes B=0,10,20...800.
   b. ensure that each series has some values of the maximum B-value (e.g. 800 in this case). Siemens will conduct sequence optimizations that are limited by the maximum b-value. Therefore, a B=0 image acquired on its own will be different from an identical sequence acquired with both B=0 and B=2000. You can see this with the British BioBank sequence diff_PA_MPopt_MB3_3b0_lowflip. In this case, the intention is to acquire a B=0 series with P>A phase encoding polarity to match the directional A>P diff_AP_MPopt_MB3_50b1000_50b2000_8b0_lowflip sequence which has b-values up to 2000. Even though only the B=0 images are desired for the P>A sequence, it includes a few B=2000 volumes to ensure equivalent images. In your example, you would need to pad each series with a set of B=800 images, and of course my software will save each series as a separate file so you would want to call fslmerge as well as merging the resulting bval and bvec files. This is more complicated and acquisition will be slower than the previous option.

In brief, you will want to reacquire this dataset. When you export the data, save it as Enhanced format. Ensure that every user at your center is advised (as I document here and here):

1. All data MUST be exported as Enhanced data without "Anonymize as..." selected and in non-mosaic form. Any other option will lead to images that can not be analyzed effectively.
2. If the data is exported in classic format, the data will be impoverished.
3. If the data is exported as anonymized, the data will be impoverished.
4. If the data is exported as mosaics, it retains no spatial information and is worthless. As Siemens considers X-series mosaics are secondary capture images intended for quality assurance only. Indeed, the mosaic scans lack several "Type 1" DICOM properties, and are therefore technically DICOM objects not valid DICOM images.

Even when you follow all these rules, be aware that the Siemens X-series DICOMs contain much less meta information than the Siemens V-series DICOMs. Sequence details and software stepping is not provided. The resulting BIDS JSON files will therefore be impoverished. This reflects inherent limitations of the DICOM images, not my software.

[mharms]

Excellent summary @neurolabusc. As a suggestion, it might be helpful if you mentioned this fundamental problem on the README of the main landing page, and linked to this comment, or the other similar comments that you have embedded over time as part of other "Issues". That would make it more prominent, and make it easier to find for those that want to refer back to your summary of the situation.

[neurolabusc]

Future releases of dcm2niix will alert users for all Siemens XA conversions:

Warning: Siemens XA DICOM inadequate for robust conversion (issue 236)

Data stored from the console in classic, anonymized or mosaic formats can not be salvaged. Data stored in the enhanced data will have impoverished BIDS data. This reflects limitations of the Siemens DICOM data, not my software.

[neurolabusc]

This issue persists in Siemens XA70 data. The DICOM standard suggests that all images in a series should share a StudyInstanceUID (0020,000d), SeriesNumber (0020,0011), SeriesTime (0008,0031), and StudyInstanceUID (0020,000d). However, Siemens XA systems creating interoperable (e.g. classic) DICOMs generate a separate StudyInstanceUID for each volume in the series. The easy kludge for users is to export data in enhanced mode (which saves one 3D volume per file, rather than one 2D slice dramatically reducing demands on PACS transfers).

While dcm2niix extends a kludge to combine these images to XA70, this may lead to unintended consequences and will impact other tools that assume valid and truthful DICOM images. Users who experience these issues should lobby their Siemens Research Collobration Manager to fix this problem. This is a limitation of the images created by the scanner, not dcm2niix.