Dwi2response failed

Ah, OK. In my experience, Bruker DICOM files are problematic on many levels. I’m surprised to hear you say you can find the information in the DICOM headers at all…

That doesn’t sound good…

I tried to calculate the response function now from the .nii file and it gave me a different, albeit similar error:

dwi2response: [ERROR] Command failed: mrconvert /home/dario/Desktop/20160708_232214_StructuralConnectivity_1_42_E4/7/dwi.nii - -stride 0,0,0,1 | dwiextract - /tmp/dwi2response-tmp-QMDCAA/dwi.mif
dwi2response: Output of failed command:
dwiextract: [ERROR] invalid diffusion gradient table dimensions
dwiextract: [ERROR] unable to get valid diffusion gradient table for image "/tmp/mrtrix-tmp-4ZimTD.mif"
dwi2response: Changing back to original directory (/home/dario/Desktop/20160708_232214_StructuralConnectivity_1_42_E4/7)
dwi2response: Script failed while executing the command: mrconvert /home/dario/Desktop/20160708_232214_StructuralConnectivity_1_42_E4/7/dwi.nii - -stride 0,0,0,1 | dwiextract - /tmp/dwi2response-tmp-QMDCAA/dwi.mif
dwi2response: For debugging, inspect contents of temporary directory: /tmp/dwi2response-tmp-QMDCAA/

OK, the first error is actually slightly misleading:
dwiextract: [ERROR] invalid diffusion gradient table dimensions
The second one is more telling:
dwiextract: [ERROR] unable to get valid diffusion gradient table for image "/tmp/mrtrix-tmp-4ZimTD.mif"

NIfTI images can’t include the diffusion gradient table in the header. So when you call dwi2response and provide a NIfTI image as input, the script has no way of knowing which volumes correspond to which directions & b-values - hence dwiextract (which is responsible for extracting the b-value shell of interest from the image series) fails. You need to either provide the gradient table from external file(s) using the -grad or -fslgrad options, or use an image format that can embed the gradient table in the image header.

Hello, I ran into a problem when using the dwi2mask command.“dwi2mask: [ERROR] Gradient encoding matrix does not represent a HARDI sequence
” The scanner is also bruker BioSpec. Can you teach me how to process the data from bruker BioSpec?

Hi @QinJiasheng,

That particular error suggests that the diffusion gradient scheme has been imported, but the b-values are not arranged in “shells” (i.e. volumes with the same diffusion sensitisation strength but different directions). This is typically the case for “DSI” acquisitions. So you’ll need to determine whether this is in fact the case for your acquired data, or whether something has gone wrong during the importing process that is leading to the error.

The best first step would be to post the output of mrinfo -dwgrad, and describe what you know about the acquisition.

Cheers
Rob

One of the issue with Bruker data is that their DICOM output is (in my experience) not consistent, at least in terms of the diffusion gradient table information. There is a script that now ships with MRtrix3 to convert their raw 2dseq format (convert_bruker, in the scripts/ folder) , but it isn’t perfect either, and can also get the directions wrong (although in this case it’s typically just a matter of inverting or swapping components of the direction vectors). It also doesn’t extract the image orientation, which might be problematic for oblique acquisitions. The other issue is that as far as I can tell from my (limited) research into the Bruker raw format, their conventions change routinely between software versions, making it very tricky to robustly interpret their header information. So the convert_bruker script is provided on a best-effort basis, in the hope that it may help users such as yourself - and if you find ways to improve it, feel free to let us know!

Thank you very much rsmith!!! I did the command and this is the result:
promote:~ admin$ mrinfo -dwgrad /Users/admin/Documents/MATLAB/DICOM
mrinfo: [done] scanning DICOM folder “/Users/admin/Documents/MATLAB/DICOM”
Select series (‘q’ to abort):
0 - 15 MR images unnamed (FLASH (pvm)) [65537]
1 - 12 MR images unnamed (RARE (pvm)) [131073]
2 - 9 MR images unnamed (RARE (pvm)) [196609]
3 - 128 MR images unnamed (FieldMap (pvm)) [262145]
4 - 700 MR images unnamed (DtiEpi (pvm)) [393217]
? 4
mrinfo: [100%] reading DICOM series “”
mrinfo: [ERROR] floating-point sequence specifier is empty
promote:~ admin$
If I used this command in the right way?:joy: Dose it means there are no b-value table in the header ? I can get the b-value table which is in the form of “.txt”

Thank you very much !!! I understand what you mean probably,but how can I use the script:joy:. I saw the script just now, should I just copy the script and then past it in the Terminal?

Yea right, I tried to covert the file in other format before, and it prompted me the data is not consistent

No, it should already be in your PATH if you installed MRtrix3 correctly. It produces a .mih file, which is a text header that MRtrix3 commands can understand, and will load the corresponding raw data given the information in that header. You can then mrconvert that to .mif or .nii if you wish (although the .nii format will lose the DW gradient table information unless you also export the bvecs/bvals using the -export_grad_fsl option).

What did you use to try converting before, just out of interest?

The only sensible point in the code that would throw this particular error message is here - which indeed would indicate that the DW gradient information is missing - or more precisely, the DICOM header contained appropriate tags to store that information, but either the tags were empty, or the information was badly formatted.

The simplest way to figure this out is to try:

mrinfo /Users/admin/Documents/MATLAB/DICOM -property dw_scheme

which will print out exactly what our DICOM importer managed to extract, without trying to interpret it in any way. Otherwise, you can use dcminfo -all DICOM_FILE, where DICOM_FILE is a single file within your DICOM folder that corresponds to one of the 700 frames from your DtiEpi series, and post the output of that so we can see what was actually written in the raw DICOM headers.

I tried this and the result is this:promote:~ admin$ mrinfo /Users/admin/Documents/MATLAB/DICOM -property dw_scheme
mrinfo: [done] scanning DICOM folder “/Users/admin/Documents/MATLAB/DICOM”
Select series (‘q’ to abort):
0 - 15 MR images unnamed (FLASH (pvm)) [65537]
1 - 12 MR images unnamed (RARE (pvm)) [131073]
2 - 9 MR images unnamed (RARE (pvm)) [196609]
3 - 128 MR images unnamed (FieldMap (pvm)) [262145]
4 - 700 MR images unnamed (DtiEpi (pvm)) [393217]
? 4
mrinfo: [100%] reading DICOM series “”
mrinfo: [WARNING] no “dw_scheme” entries found in “lyf1204depression1 (lyf1204depression1) [MR]” .And the result of the other 4 folder are the same

while the result of this is:
promote:~ admin$ dcminfo -all /Users/admin/Documents/MATLAB/DICOM/1/MRIm001
TYPE GRP ELEM VR SIZE OFFSET NAME CONTENTS


[DCM] 0002 0000 UL 4 132 FileMetaInformationGroupLength [ 192 ]
[DCM] 0002 0001 OB 2 144 FileMetaInformationVersion unknown data type
[DCM] 0002 0002 UI 26 158 MediaStorageSOPClassUID [ 1.2.840.10008.5.1.4.1.1.4 ]
[DCM] 0002 0003 UI 48 192 MediaStorageSOPInstanceUID [ 2.16.756.5.5.100.3611295486.1479.1480816577.1.0 ]
[DCM] 0002 0010 UI 20 248 TransferSyntaxUID [ 1.2.840.10008.1.2.1 ]
[DCM] 0002 0012 UI 28 276 ImplementationClassUID [ 1.2.276.0.7230010.3.0.3.5.4 ]
[DCM] 0002 0013 SH 16 312 ImplementationVersionName [ OFFIS_DCMTK_354 ]
[DCM] 0008 0008 CS 22 336 ImageType [ ORIGINAL PRIMARY OTHER ]
[DCM] 0008 0012 DA 8 366 InstanceCreationDate [ 20161204 ]
[DCM] 0008 0013 TM 6 382 InstanceCreationTime [ 122301 ]
[DCM] 0008 0016 UI 26 396 SOPClassUID [ 1.2.840.10008.5.1.4.1.1.4 ]
[DCM] 0008 0018 UI 48 430 SOPInstanceUID [ 2.16.756.5.5.100.3611295486.1479.1480816577.1.0 ]
[DCM] 0008 0020 DA 8 486 StudyDate [ 20161204 ]
[DCM] 0008 0022 DA 8 502 AcquisitionDate [ 20161204 ]
[DCM] 0008 0030 TM 6 518 StudyTime [ 085144 ]
[DCM] 0008 0032 TM 6 532 AcquisitionTime [ 092458 ]
[DCM] 0008 0050 SH 0 546 AccessionNumber [ ]
[DCM] 0008 0060 CS 2 554 Modality [ MR ]
[DCM] 0008 0070 LO 24 564 Manufacturer [ Bruker BioSpin MRI GmbH ]
[DCM] 0008 0080 LO 30 596 InstitutionName [ Southeast University, Nanjing ]
[DCM] 0008 0090 PN 0 634 ReferringPhysicianName [ ]
[DCM] 0008 1010 SH 14 642 StationName [ PharmaScan 7T ]
[DCM] 0010 0010 PN 18 664 PatientName [ lyf1204depression1 ]
[DCM] 0010 0020 LO 18 690 PatientID [ lyf1204depression1 ]
[DCM] 0010 0030 DA 0 716 PatientBirthDate [ ]
[DCM] 0010 0040 CS 2 724 PatientSex [ M ]
[DCM] 0010 1030 DS 2 734 PatientWeight [ 5 ]
[DCM] 0018 0020 CS 2 744 ScanningSequence [ RM ]
[DCM] 0018 0021 CS 4 754 SequenceVariant [ NONE ]
[DCM] 0018 0022 CS 0 766 ScanOptions [ ]
[DCM] 0018 0023 CS 2 774 MRAcquisitionType [ 2D ]
[DCM] 0018 0024 SH 12 784 SequenceName [ DtiEpi (pvm) ]
[DCM] 0018 0050 DS 4 804 SliceThickness [ 0.8 ]
[DCM] 0018 0080 DS 8 816 RepetitionTime [ 6500.001 ]
[DCM] 0018 0081 DS 6 832 EchoTime [ 28.66 ]
[DCM] 0018 0083 DS 2 846 NumberOfAverages [ 2 ]
[DCM] 0018 0084 DS 12 856 ImagingFrequency [ 300.3371139 ]
[DCM] 0018 0085 SH 2 876 ImagedNucleus [ 1H ]
[DCM] 0018 0088 DS 4 886 SpacingBetweenSlices [ 0.8 ]
[DCM] 0018 0089 IS 2 898 NumberOfPhaseEncodingSteps [ 84 ]
[DCM] 0018 0091 IS 2 908 EchoTrainLength [ 21 ]
[DCM] 0018 0094 DS 4 918 PercentPhaseFieldOfView [ 100 ]
[DCM] 0018 0095 DS 8 930 PixelBandwidth [ 1953.125 ]
[DCM] 0018 1020 LO 14 946 SoftwareVersions [ ParaVision 5.1 ]
[DCM] 0018 1030 LO 30 968 ProtocolName [ EPI-diffusion-tensor-RAT_6sta ]
[DCM] 0018 1310 US 8 1006 AcquisitionMatrix [ 84 0 0 256 ]
[DCM] 0018 1312 CS 4 1022 InPlanePhaseEncodingDirection [ COL ]
[DCM] 0018 1314 DS 2 1034 FlipAngle [ 90 ]
[DCM] 0018 5100 CS 4 1044 PatientPosition [ HFS ]
[DCM] 0020 000D UI 50 1056 StudyInstanceUID [ 2.16.756.5.5.100.3611295486.30024.1480812704.4611 ]
[DCM] 0020 000E UI 46 1114 SeriesInstanceUID [ 2.16.756.5.5.100.3611295486.1479.1480816577.1 ]
[DCM] 0020 0010 SH 16 1168 StudyID [ lyf1204depressio ]
[DCM] 0020 0011 IS 6 1192 SeriesNumber [ 393217 ]
[DCM] 0020 0012 IS 2 1206 AcquisitionNumber [ 1 ]
[DCM] 0020 0013 IS 2 1216 InstanceNumber [ 1 ]
[DCM] 0020 0032 DS 16 1226 ImagePositionPatient [ -15.9 -17.2 -6.9 ]
[DCM] 0020 0037 DS 68 1250 ImageOrientationPatient [ 1 6.123031769e-17 9.295486608e-33 -6.123031769e-17 1 1.550163777e-16 ]
[DCM] 0020 0052 UI 54 1326 FrameOfReferenceUID [ 2.16.756.5.5.100.3611295486.1479.1480816577.1.6.15.18 ]
[DCM] 0020 1002 IS 4 1388 ImagesInAcquisition [ 700 ]
[DCM] 0020 1040 LO 0 1400 PositionReferenceIndicator [ ]
[DCM] 0020 1041 DS 4 1408 SliceLocation [ -6.9 ]
[DCM] 0028 0002 US 2 1420 SamplesPerPixel [ 1 ]
[DCM] 0028 0004 CS 12 1430 PhotometricInterpretation [ MONOCHROME2 ]
[DCM] 0028 0010 US 2 1450 Rows [ 128 ]
[DCM] 0028 0011 US 2 1460 Columns [ 128 ]
[DCM] 0028 0030 DS 10 1470 PixelSpacing [ 0.25 0.25 ]
[DCM] 0028 0100 US 2 1488 BitsAllocated [ 16 ]
[DCM] 0028 0101 US 2 1498 BitsStored [ 16 ]
[DCM] 0028 0102 US 2 1508 HighBit [ 15 ]
[DCM] 0028 0103 US 2 1518 PixelRepresentation [ 1 ]
[DCM] 0028 0106 US 2 1528 SmallestImagePixelValue [ 115 ]
[DCM] 0028 0107 US 2 1538 LargestImagePixelValue [ 32766 ]
[DCM] 0028 1050 DS 6 1548 WindowCenter [ 16441 ]
[DCM] 0028 1051 DS 6 1562 WindowWidth [ 32652 ]
[DCM] 0028 1055 LO 6 1576 WindowCenterWidthExplanation [ MinMax ]
[DCM] 7FE0 0010 OW 32768 1590 PixelData unknown data type
What does this mean :joy:

Thank you very very much!!!

And I tried the command “convert_bruker” the result is:
promote:~ admin$ convert_bruker /Users/admin/Documents/MATLAB/DICOM
usage: convert_bruker 2dseq header.mih
And what should I do mrconvert to then. I cannot find the .mih file :joy:

It means that the DICOM files contain no information whatsoever about the DW gradient encoding… There’s no point trying to use the DICOM unless you have the gradient table from some other source…

Yes, the help page on that script is admittedly a bit brief… The header.mih file is the output of that script - it’ll be a simple text file that can be used as an input image to any MRtrix3 command. The 2dseq file will reside somewhere within your raw data folder. For example, for the data I have on my system at the moment, they might be in data_folder/22/pdata/1/2dseq or something like that. So you could just type:

convert_bruker data_folder/22/pdata/1/2dseq data.mih

and then:

mrinfo data.mih
mrview data.mih
mrconvert data.mih data.mif

etc.

If I get the gradient table,there are command to import it in the header right?
Only if I import the gradient table in, could I output the .mif file,right? Because there are no file when I searched “.mif” on my computer :sweat_smile:

Yes, although it’s a bit more flexible than that. I note we don’t actually have a section on DW gradient handing in the documentation, I’ll make a note to fix that.

Basically, any commands that requires the DW gradient information will provide these options (this is exactly what you’ll see in the help page for any of these commands, e.g. dwi2fod:

  • -grad encoding
    specify the diffusion-weighted gradient scheme used in the acquisition. The program will normally attempt to use the encoding stored in the image header. This should be supplied as a 4xN text file with each line is in the format [ X Y Z b ], where [ X Y Z ] describe the direction of the applied gradient, and b gives the b-value in units of s/mm².

  • -fslgrad bvecs bvals
    specify the diffusion-weighted gradient scheme used in the acquisition in FSL bvecs/bvals format.

  • -bvalue_scaling mode
    specifies whether the b-values should be scaled by the square of the corresponding DW gradient norm, as often required for multi-shell or DSI DW acquisition schemes. The default action can also be set in the MRtrix config file, under the BValueScaling entry. Valid choices are yes/no, true/false, 0/1 (default: true).

If these options are not used, then the application will look for the DW information in the header of the image. The only formats that currently support the inclusion of this information in the image headers are DICOM and .mif/.mih - but there’s no requirement that the information actually be present (as you saw from your own DICOM data).

You can also insert this information into the image header using these options with mrconvert, but note this will only work if the output image format can store that information, which means using the .mif format (or .mih if you want a split text header / binary data format).

I’m not entirely sure what you mean here, but I think my previous point answers that question…? Although there’s nothing stopping you from outputting a .mif without importing the gradient table, it just wouldn’t be much use to you here. But .mif is the only output format that can be used to store the gradient table internally (along with .mih; DICOM can also store it, but is read-only).

:confused: I don’t get your question here…

First off, .mif refers to the file suffix, you would actually produce images called something.mif - you’d need to search for *.mif to locate them. More to the point, you won’t find any such images if you haven’t created them yourself - it’s an image storage format specific to MRtrix

Hello, I get the gradient table now which is in the format of .txt. But when I use “-grad encoding” it’s result is this:promote:~ admin$ mrconvert -grad encoding /Users/admin/Documents/MATLAB/DICOM1 /Users/admin/Documents/MATLAB/DICOM
mrconvert: [ERROR] input file “encoding” not found (required for option “-grad”)
How can I make the txt file useful? Is there any format or filename requirements ?

So I’m not sure how you generated your file, but it should consist of pure ASCII text, one line per volume in your DWI image, with each line containing 4 numeric values corresponding to [ X Y Z b ]. This might look something like this for a 60 DW direction image:

60 DW scheme encoding file
          0           0           0           0
 -0.0509541   0.0617551    -0.99679        2950
   0.011907    0.955047    0.296216        3000
  -0.525115    0.839985    0.136671        3000
  -0.785445     -0.6111  -0.0981447        3000
   0.060862   -0.456701    0.887536        3000
   0.398325    0.667699      0.6289        3000
  -0.680604    0.689645   -0.247324        3000
   0.237399    0.969995   0.0524565        3000
   0.697302    0.541873   -0.469195        3000
  -0.868811    0.407442     0.28135        3000
          0           0           0           0
   -0.88246    0.428719   -0.193558        3000
  -0.772105    0.632136    0.065248        3000
  -0.820078   -0.428548   -0.379234        3000
   0.190381   -0.885335    0.424191        3000
  -0.664145    0.223122   -0.713532        3000
   0.337998    0.871812    0.354544        3000
   0.346179   0.0918307    0.933663        3000
  -0.976625  -0.0105742   -0.214691        3000
  -0.206214    0.717329    0.665518        3000
  -0.470762    0.725362   -0.502228        3000
          0           0           0           0
   0.101531    0.808512    0.579654        3000
   0.616496    0.690774    0.377842        3000
  -0.421397    0.888206    -0.18307        3000
   -0.20103    0.690746   -0.694591        3000
   0.141178    0.879996   -0.453515        3000
  -0.865201   -0.232157    0.444443        3000
  -0.976839    0.209936    0.041383        3000
   0.634006    0.111568    0.765238        3000
  -0.667955   -0.719616    0.189711        3000
  -0.737938     0.34521    0.579895        3000
          0           0           0           0
   0.395534     0.48966   -0.777037        3000
  -0.981843   -0.106924    0.156687        3000
  -0.869147   -0.454224    0.195611        3000
  -0.730282    0.029222    0.682521        3000
  -0.943768   -0.317546  -0.0920093        3000
  0.0679404    0.276316    0.958662        3000
  -0.656448    0.649973    0.382897        3000
   0.351965    0.412539    0.840198        3000
  -0.230572    0.127174    0.964709        3000
  0.0608661    0.576937    0.814518        3000
          0           0           0           0
  -0.850915   -0.124053   -0.510446        3000
   0.654847    0.300024   -0.693657        3000
   0.130149    0.680999   -0.720626        3000
   0.478546   0.0819228   -0.874232        3000
    0.62804    0.425953    0.651253        3000
   -0.70613    0.489396   -0.511734        3000
   -0.86993    0.208211   -0.447069        3000
-0.00136964    0.985371   -0.170418        3000
   0.208133    0.265902   -0.941263        3000
  -0.516489     0.25358    0.817885        3000
          0           0           0           0
  -0.496738    0.556882    0.665683        3000
   0.539734    0.837193   0.0882899        3000
  -0.319767    0.245293   -0.915194        3000
  -0.462573    0.489319   -0.739319        3000
  -0.244511    0.446006    0.860984        3000
   0.386928    0.893086   -0.229529        3000
  -0.227682    0.971352    0.068087        3000
  -0.302223    0.872377    0.384212        3000
  -0.906492    0.103374    0.409373        3000
          0           0           0           0
   0.426684     0.72678   -0.538267        3000

There’s no filename requirements, as long as the name you supply is the right name. If I call this file grad.b, I can use it as -grad grad.b. The error message you get suggests that the filename you supplied (encoding) isn’t the right filename for your text file - it can’t find any file called encoding at the current location. What did you call your file?

One last note: I notice you’re trying to convert from a DICOM folder directly into what I assume is another DICOM folder? That won’t work, MRtrix3 only support DICOM for reading, not writing. You’d need to convert into a .mif file for this to work (it’s the only format that’ll store the DW gradient information currently).

Dear experts:
I am processing marmoset bruker data. I have the following question:
At running time, the command below shows bval = 3000
convert_bruker 14_3000/pdata/1/2dseq 14_1.mih

('mat_size', ['128', '128'])
('wtype', '_16bit_sgn_int')
('byteorder', 'littleendian')
('nacq', 130)
('nslices', '30')
('bval', ['27.7435214952211', '27.7435214952211', '3041.34969512408', '3042.13463916172', '3040.52913696742', '3037.26465422457', '3034.50949667129', '3031.95300802412', '3033.45431483667', '3032.07797167266', '3032.94386894491', '3031.7640794336', '3031.52176911671', '3029.62884640284', '3038.61577834699', .....

After checking the conversion, bvals are now 800 ? Is that ok ?

mrinfo 14_1.mih

mrinfo: [WARNING] transform matrix contains invalid entries - resetting to sane defaults


Image: “14_1.mih”


Dimensions: 128 x 128 x 30 x 130
Voxel size: 0.35 x 0.35 x 0.7 x ?
Data strides: [ 1 2 3 4 ]
Format: MRtrix
Data type: signed 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 1 0 0 -22.22
0 1 0 -22.22
0 0 1 -10.15
dw_scheme: [ 130 entries ]

mrinfo 14_1.mih -dwgrad

mrinfo: [WARNING] transform matrix contains invalid entries - resetting to sane defaults
0 0 -0 0
0 0 -0 0
0.140172 -0.0160717 -0.989997 815.871
-0.0833783 0.0328269 -0.995977 816.081
-0.030411 -0.194607 -0.98041 815.65
0.374817 -0.0492301 -0.925791 814.775
0.0799311 0.214485 -0.973451 814.036
-0.145629 0.267416 -0.952513 813.35
-0.299452 0.0815808 -0.950617 813.753
-0.24298 -0.16266 -0.956296 813.383
0.0795599 -0.37395 -0.92403 813.616
0.233021 -0.222001 -0.946793 813.299

My guess as to what is happening is that the the gradient vectors do not have unit amplitude. If you look at this post, you’ll see that by default MRtrix3 will scale the b-values according to the amplitude of the gradient vectors (this is to support multi-shell schemes on certain scanners). You should be able to confirm using the mrinfo 14_1.mih -dwgrad -raw_dwgrad. If you’re confident that your b-values were 3000, use the -bvalue_scaling 0 option to disable this in those commands that support it.

mrinfo 14_1.mih -dwgrad

mrinfo: [WARNING] transform matrix contains invalid entries - resetting to sane defaults
0 0 -0 0
0 0 -0 0
0.140172 -0.0160717 -0.989997 815.871
-0.0833783 0.0328269 -0.995977 816.081
-0.030411 -0.194607 -0.98041 815.65
0.374817 -0.0492301 -0.925791 814.775
0.0799311 0.214485 -0.973451 814.036
-0.145629 0.267416 -0.952513 813.35
-0.299452 0.0815808 -0.950617 813.753
-0.24298 -0.16266 -0.956296 813.383
0.0795599 -0.37395 -0.92403 813.616
0.233021 -0.222001 -0.946793 813.299

Another reason I’d be taking a very close look at your scheme: the first 10 directions out of 130 are all quite close to the z-axis. It might be OK, it could be sweeping down in elevation and spinning in azimuth; but even if that’s the case it’s common to randomise the order of the directions to reduce long-term eddy currents. Just thought I’d raise in case there’s something more fundamentally wrong with the gradient import process.