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 
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 
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).
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.