Mrview: unknown option / unrecognized argument

Hi, all,

I meet two problems.

When I type the command “mrview”, the output shows as below:

mrview HARDI150.mif -odf.load_sh HARDI150_fod.mif
mrview: unknown option “-odf.load_sh”

I used to use this command to check whether my odf image is right or not.

Then I checked mrtrix version:

$ mrconvert -version
== mrconvert 3.0_RC2-24-gfc18ca90 ==
64 bit release version, built Sep 4 2017, using Eigen 3.2.92
Author(s): J-Donald Tournier (
Copyright © 2008-2017 the MRtrix3 contributors.


dwipreproc -rpe_none AP HARDI150_denoise.mif HARDI150_denoise_preproc.mif

the output shows:

Error: unrecognized arguments: HARDI150_denoise_preproc.mif
Usage: dwipreproc input output [ options ]
(Run dwipreproc -help for more information)

Can someone give some advice?


  1. not sure what’s going on, but the first thing to do is verify that the version of mrview being invoked is actually the right one - you’re showing the output of mrconvert -version, try mrview -version to rule out any issues on that front. Otherwise I can’t see anything wrong with your command.

  2. dwipreproc now expects the phase-encode direction to be provided via the -pe_dir option (see help page for details). This change was introduced in version 3.0_RC1.

Hi, Donald,

The problem may not list here for laking-pe_dir option. Maybe I missed some tips.:
It seems that it can not recognize the output file:

dwipreproc -rpe_none AP DTI_30_average-6_denoise.mif -pe_dir j- DTI_30_average-6_denoise_preproc.mif

 Error: unrecognized arguments: DTI_30_average-6_denoise_preproc.mif
 Usage: dwipreproc input output [ options ]
       (Run dwipreproc -help for more information)

And, here is the information of the current data:

> mrinfo DTI_30_average-6.mif

Image:               "DTI_30_average-6.mif"
  Dimensions:        128 x 128 x 44 x 186
  Voxel size:        2 x 2 x 3 x ?
  Data strides:      [ -1 -2 3 4 ]
  Format:            MRtrix
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:               0.9989    -0.03139     0.03407      -123.1
                          0.03463      0.9945    -0.09911      -107.2
                         -0.03077      0.1002      0.9945      -43.39
  EchoTime:          0.093
  PhaseEncodingDirection: j-
  TotalReadoutTime:  0.0531
  command_history:   mrconvert "DTI_30_average-6/" "DTI_30_average-6.mif"  (version=3.0_RC2-24-gfc18ca90)
  comments:          LIU YAN (8888) [MR] DTI_30_average-6
                     study: head Union Hospital [ ORIGINAL PRIMARY M ND MOSAIC ]
                     DOB: 13/11/1961
                     DOS: 13/11/2008 21:06:36
  dw_scheme:         0,0,0,0
  [186 entries]      0.20387258,0.52022557999999997,-0.82933800999999996,1000
  mrtrix_version:    3.0_RC2-24-gfc18ca90


The problem is indeed with your usage as @jdtournier described:

dwipreproc -rpe_none AP DTI_30_average-6_denoise.mif -pe_dir j- DTI_30_average-6_denoise_preproc.mif

Here you are providing the phase-encoding direction twice: once as the first input argument “AP”, and again using the “-pe_dir j-” option.

If we strip away the command-line options, and only show the positional arguments, this is what your invocation looks like:

dwipreproc AP DTI_30_average-6_denoise.mif DTI_30_average-6_denoise_preproc.mif

That is, you have provided three arguments:

  1. AP
  2. DTI_30_average-6_denoise.mif
  3. DTI_30_average-6_denoise_preproc.mif

The command, however, expects two positional arguments:

Usage: dwipreproc input output

So the command thinks that “AP” is the input image, “DTI_30_average-6_denoise.mif” is the output image, and “DTI_30_average-6_denoise_preproc.mif” is … something that it doesn’t know what to do with. Unfortunately the error message is not as useful as it could be; but I can’t fix this without entirely removing the dependence of the MRtrix3 Python scripts on the argparse module and writing a command-line parser from scratch.

The misunderstanding also comes from the fact that the dwipreproc script used to require three arguments. In an earlier version, manually specifying the phase-encoding direction was not an optional parameter as it is now, but a compulsory command-line argument, which needed to appear before the path to the input file. So whatever is informing you to add “AP” to the start of the instruction is out-of-date.


Hi, Rob,

Thanks for your patience! The problem has been solved.

It is indeed my own fault, I should read the script more carefully.