unable to create bvac and bval file

[abhik9]

Dear Chris,
I had tried to convert my DTI DICOM data from Philips MRI (8 coils) to NIfTI but it is showing
Warning: No bvec/bval files created: only single value after ADC excluded
Also it forming nifti file with filename_real.nii and filename_real.json

I had used following command:

/home/fsluser/Downloads/mricrogl_lx/dcm2niix -f %n -o output_folder_path input_folder_path

I had also tried latest version on Linux by calling it on terminal and getting following warnings in terminal:

1. DICOM appears corrupt: first group:element should be 0x0002:0x0000
   '/home/fsluser/DTI/ASD_o_Epilepsy_ALL_ACQUIRED_DATA/Zakhir/DTI/IM_1819'

2. Slice positions repeated, but number of slices (2025) not divisible by number of repeats (33): missing
   images?

3. Dims 128 128 2025 1 33

4. Warning: Interslice distance varies in this volume (incompatible with NIfTI format).

5. swizzling 3rd and 4th dimensions (XYTZ -> XYZT), assuming interslice distance is 0.000000

6. Warning: No bvec/bval files created: only single value after ADC excluded

7. Philips Scaling Values RS:RI:SS = 6.32845:0:0.00160259 (see PMC3998685)

8. Convert 2025 DICOM as
   /home/fsluser/DTI/ASD_o_Epilepsy_ALL_ACQUIRED_DATA/Zakhir/o/ZAKIR_real (128x128x2025x1)

9. compress: "/usr/bin/pigz" -n -f -6

10 "/home/fsluser/DTI/ASD_o_Epilepsy_ALL_ACQUIRED_DATA/Zakhir/o/ZAKIR_real.nii"

11. Unable to equalize slice distances: slice number not consistent with slice position.

But when I was using the dcm2niix version before version 15-Dec-2017 (v1.0.20171215) than able to get both bvec and bval file.(I had used v1.0.20171204 )(On both windows and Linux)

But Linux when I am calling it on terminal than still getting following warnings on terminal:

1. Found 2040 DICOM image(s)

2. DICOM appears corrupt: first group:element should be 0x0002:0x0000
   '/home/fsluser/DTI/zzno_bvec/Zakhir/DTI/IM_1819'

3. Slice positions repeated, but number of slices (2025) not divisible by number of repeats (33): missing
   images?

4. Dims 128 128 2025 1 33

5. Warning: Interslice distance varies in this volume (incompatible with NIfTI format).

6. Note: 1 volumes appear to be ADC images that will be removed to allow processing

7. Saving 33 DTI gradients. Validate vectors.

8. Convert 2025 DICOM as /home/fsluser/DTI/zzno_bvec/Zakhir/o/ZAKIR (128x128x2025x1)

9. Philips Precise RS:RI:SS = 6.32845:0:0.00160259 (see PMC3998685)
   R = raw value, P = precise value, D = displayed value
   RS = rescale slope, RI = rescale intercept, SS = scale slope
   D = R * RS + RI , P = D/(RS * SS)
   D scl_slope:scl_inter = 6.32845:0
   P scl_slope:scl_inter = 623.991:0
   Using P values ('-p n ' for D values)

10. compress: "/usr/bin/pigz" -n -f -6 "/home/fsluser/DTI/zzno_bvec/Zakhir/o/ZAKIR_ADC.nii"

11. compress: "/usr/bin/pigz" -n -f -6 "/home/fsluser/DTI/zzno_bvec/Zakhir/o/ZAKIR.nii"

12. Unable to equalize slice distances: slice number not consistent with slice position.

I had called the command from MRIcroGL folder to run in both condition.
Result were same when I had used GUI interface of MRIcroGL

How should I proceed with my DICOM to NIfTI conversion.
Should I change the way I was calling command.
Waiting for your response.

[neurolabusc]

Can you share a full DICOM dataset with me. You can do this via Box or DropBox - you can share the image with me rather than the whole list. The two typically explanations for this are

1. You anonymized the images in such a way that borks the original DICOM images. Modern Philips enhanced images are very clever, but they tend to get misinterpreted by most anonymization strategies.
2. Is it possible that what you have is DICOM meta-data rather than proper DICOM images with a proper part 10 header?

Recent versions of dcm2niix are much better at handling the nuances of Philips enhanced images, but this necessarily makes these versions more sensitive to DICOM header manipulation.

[abhik9]

@neurolabusc https://www.dropbox.com/sh/x2jixoudi3wfszf/AACCDHAfWXDCp1ChIvVMApwWa?dl=0
Heres the link of my sample DICOM Dropbox data
Please check it.

[neurolabusc]

@abhik9 can you send me the raw DICOM files direct from the scanner console directly to me (without sharing publicly). I suspect your images have been contaminated by some DICOM-to-DICOM conversion. The header mentions that the data has been manipulated by DicomBrowser and ViewForum R7.2, though perhaps other tools have touched it.

@drmclem - do you have any insight into this dataset. The issue can be seen clearly by looking at the DICOM header (e.g. using dcmdump or any other tool that reports the header). Visual inspection shows these are MAGNITUDE images, and this is also what is reported by ImageType (\M\), but ComplexImageComponent reports the image data is REAL. These are classic DICOMs, but enhanced DICOMs can store multiple image types in a single image. Any idea why these images are marked as REAL?

ImageType (0008,0008) CS [ORIGINAL\PRIMARY\M_SE\M\SE]
ComplexImageComponent (0008,9208) CS [REAL]
MRSpectroComplexComponent (2005,1327) CS [REAL] 

[drmclem]

Hi - I don't have a good answer to this one - the Viewforum R7.2 is the dicom format for the "Extended Workspace" external workstation from Philips which is not a current product so I don't have one near by to test this on. I know that some sites have used this to output classic single frame dicom before you could choose which format on the scanner to export and perhaps this process has messed it up due to the differences in format between the EWS release and the scanner release.

The only other thing I could think of is if some intermediate tool has recreated a complex image from the magntude data by dumping it in the real channel but I doubt it.

So no real answers I'm afraid.

[neurolabusc]

@drmclem thanks for your rapid response. If @abhik9 could provide the raw data it could clear this up.

@abhik9 the second issue with your DWI dataset is that it explicitly reports this is NOT diffusion data, as DiffusionDirectionality is set to NONE, whereas we would expect this to be DIRECTIONAL or BMATRIX. It is important for dcm2niix to detect this, as it helps us remove derived ISOTROPIC images from the diffusion datasets. This is described in the dcm2niix Philips documentation. I could always make a kludge that counts NONE as a form of directional. However, this may have unintended consequences and since I have never seen this before it provides more evidence that your images have been tampered with.

(0018,9075) CS [NONE]                                   #   4, 1 DiffusionDirectionality
(0018,9087) FD 1000                                     #   8, 1 DiffusionBValue
(0018,9089) FD 0.70710194110870361\-0.47248554229736328\-0.52608382701873779 #  24, 3 DiffusionGradientOrientation

While it is easy to make a kludge to handle your images (with the potential for unintended consequences), I think a far better approach is for you to work out the providence of these images and determine how they were contaminated. This will help ensure you are storing archival quality data. When your data explicitly reports that the directionality is NONE, it is unreasonable for a converter to assume your data is directional. A clear tenet of dcm2niix is that it tries not to second guess what the DICOM file explicitly reports: if someone put a tag in the DICOM header it was probably for good reason.

[abhik9]

Hi is this your email id.

…

On Wed, 16 Jan, 2019, 22:27 Chris Rorden ***@***.*** wrote: @drmclem <https://github.com/drmclem> thanks for your rapid response. If @abhik9 <https://github.com/abhik9> could provide the raw data it could clear this up. @abhik9 <https://github.com/abhik9> the second issue with your DWI dataset is that it explicitly reports this is NOT diffusion data, as DiffusionDirectionality is set to NONE, whereas we would expect this to be DIRECTIONAL or BMATRIX. It is important for dcm2niix to detect this, as it helps us remove derived ISOTROPIC images from the diffusion datasets. This is described in the dcm2niix Philips documentation <https://github.com/rordenlab/dcm2niix/tree/master/Philips>. I could always make a kludge that counts NONE as a form of directional. However, this may have unintended consequences and since I have never seen this before it provides more evidence that your images have been tampered with. (0018,9075) CS [NONE] # 4, 1 DiffusionDirectionality (0018,9087) FD 1000 # 8, 1 DiffusionBValue (0018,9089) FD 0.70710194110870361\-0.47248554229736328\-0.52608382701873779 # 24, 3 DiffusionGradientOrientation While it is easy to make a kludge to handle your images (with the potential for unintended consequences), I think a far better approach is for you to work out the providence of these images and determine how they were contaminated. This will help ensure you are storing archival quality data. When your data explicitly reports that the directionality is NONE, it is unreasonable for a converter to assume your data is directional. A clear tenet of dcm2niix is that it tries not to second guess what the DICOM file explicitly reports: if someone put a tag in the DICOM header it was probably for good reason. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#256 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMJpuZudHfpdn1Q9SFoq9FhEdTfynbNqks5vD1nmgaJpZM4Z-SiG> .

[neurolabusc]

@abhik9 you can send an dropbox invitation to my gmail.com account: crorden6. You will find that the latest developmental build will generate bvecs and bvals from your data. It will still assert these are "phase" images as that is explicitly claimed in the DICOM header (though visual inspection suggests this is an error in your raw DICOM data).

@captainnova: the latest version on the developmental branch (v1.0.20190116) includes a tiny change that might have unintended consequences. Specifically, the function you created set_directionality0018_9075() will now accept NONE as a valid directional image. Since you have a huge Philips dataset, and I do not have access to any Philips hardware, I would be grateful if you could test this out. This is not an urgent request, I think this is a pretty rare case and I am not in a rush to make a new stable release.

[captainnova]

Hi Chris, I will try testing it this week. I'm not sure I'd call the Phillips test suite I've gathered huge, but at least since I wrote the function I can also ponder the likely theoretical ramifications of the change. As far as access to Phillips hardware, there is one in the building now, but it hasn't been turned over for use yet. Rob

…

On Wed, Jan 16, 2019, 5:47 PM Chris Rorden ***@***.*** wrote: @abhik9 <https://github.com/abhik9> you can send an dropbox invitation to my gmail.com account: crorden6. You will find that the latest developmental build will generate bvecs and bvals from your data. It will still assert these are "phase" images as that is explicitly claimed in the DICOM header (though visual inspection suggests this is an error in your raw DICOM data). @captainnova <https://github.com/captainnova>: the latest version on the developmental branch (v1.0.20190116) includes a tiny change that might have unintended consequences. Specifically, the function you created set_directionality0018_9075() will now accept NONE as a valid directional image. Since you have a huge Philips dataset, and I do not have access to any Philips hardware, I would be grateful if you could test this out. This is not an urgent request, I think this is a pretty rare case and I am not in a rush to make a new stable release. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#256 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APHk6Qx71O9pMKcvlewQoNeTVy51tBdnks5vD7oBgaJpZM4Z-SiG> .

[captainnova]

I'm afraid something has broken since 20181009. dcm2niix v1.0.20190116 is not producing .bval and .bvec files for diffusion MR DICOM from Siemens XA10 (enhanced) and Philips 3.2.3 (unenhanced). Also, for Philips 5.3 enhanced and a custom diffusion gradient table, it discarded the b=0 volume without warning:

$ dcm2niix -o . /mnt/mrimages/test_image_data/dicom_to_nii/DTB_N/phi/5.3enhanced/dicom/
Chris Rorden's dcm2niiX version v1.0.20190116 (JP2:OpenJPEG) GCC4.8.5 (64-bit Linux)
Found 1 DICOM file(s)
Note: B0 not the first volume in the series (FSL eddy reference volume is 3)
Warning: Saving 35 DTI gradients. Validate vectors (image slice orientation not reported, e.g. 2001,100B).
Philips Scaling Values RS:RI:SS = 2.37363:0:0.00823404 (see PMC3998685)
Convert 1 DICOM as ./dicom_Axial_DTI_20171024132140_601 (128x128x82x36)
Conversion required 1.438159 seconds (0.510000 for core code).
$ less dicom_Axial_DTI_20171024132140_601.bval
1000 1000 1000 2 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 2 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 2 1000 1000 1000 1000 1000 1000 1000

The true (or 20181009) b values are:
1000 1000 1000 2 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 2 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 2 1000 1000 1000 1000 1000 1000 1000 0

IIRC, the b=0 volume was actually acquired first, but as noted that's just a minor issue to remember when correcting eddy currents and head motion.

Philips 2, 4 and 5 (unenhanced) worked.

It does not seem to be recognizing the Siemens XA10 and Philips 3.2.3 scans as diffusion data:
$ dcm2niix -o . /mnt/mrimages/test_image_data/dicom_to_nii/DTB_N/sie_XA10/dicom
Chris Rorden's dcm2niiX version v1.0.20190116 (JP2:OpenJPEG) GCC4.8.5 (64-bit Linux)
Found 20 DICOM file(s)
slices stacked despite varying acquisition numbers (if this is not desired recompile with 'mySegmentByAcq')
Convert 20 DICOM as ./dicom_DBSI-2000-19_20170928144550_29 (128x128x60x20)
Conversion required 0.686655 seconds (0.180000 for core code).

// Includes a "Trace" volume that would normally be removed if it had been detected.
$ dcm2niix -o . /mnt/mrimages/test_image_data/dicom_to_nii/DTB_N/phi/3.2.3unenhanced/dicom/
Chris Rorden's dcm2niiX version v1.0.20190116 (JP2:OpenJPEG) GCC4.8.5 (64-bit Linux)
Found 2720 DICOM file(s)
swizzling 3rd and 4th dimensions (XYTZ -> XYZT), assuming interslice distance is 2.000000
Convert 2720 DICOM as ./dicom_WIP_Axial_DTI_SENSE_20170906114911_701 (128x128x80x34)
Conversion required 9.112959 seconds (3.590000 for core code).

[neurolabusc]

@abhik9 I am closing this issue. The sample images you provided are borked:

• Diffusion Directionality (0018,9075) reports NONE. It looks to me like this should be DIRECTIONAL.
• DICOM tags report this is REAL but it looks like MAGNITUDE to me.

I did try a hack where I counted NONE as DIRECTIONAL if B-values were specified. However, as @captainnova noted this caused problems for legitimate Philips images. I think there might be some way around this by setting B-value to zero at the end of each SQ, but that might cause other unintended problems. I strongly suspect that these images were corrupted at some stage. Please check the providence of these images. The raw data from the equipment should be fine.

If you do want to develop your own patch for this, feel free to submit a pull request to share your solution. However, please make sure your solution works with legitimate DICOM images. David Clunie has shared a Philips Enhanced IHE DWI phantom that looks like a nice reference for what an enhanced Philips DICOM dataset should look like.