Dwipreproc (-rpe_header/ -rpe_all) errors

Dear All,

I have two sets acquired sequentially within the same scan session (each set contains 10 Xb=0 images acquired first in the respective set, then 60 dwi b=700; 1st set (70 vols) AP, 2nd set (70 vols) PA encode direction, 2x2x2 mm resolution).

For this command
dwipreproc -rpe_header predwi_denoised.mif predwi_denoised_preproc.mif

I get the following dwipreproc error:

mrconvert dwi_post_topup.nii.gz -grad grad.b - | dwi2mask - - | maskfilter - dilate - | mrconvert - mask.nii -datatype float32 -stride -1,+2,+3

dwi2mask: preloading data for "/tmp/mrtrix-tmp-fbdJeV.mif"...  [==================================================]
dwi2mask: [ERROR] number of studies in base image does not match that in diffusion gradient table
dwi2mask: [ERROR] unable to get valid diffusion gradient table for image "/tmp/mrtrix-tmp-fbdJeV.mif"
......

It turns out that the error stems from the mismatch between the no of volumes and the DW scheme of the output (/tmp/mrtrix-tmp-fbdJeV.mif) of the 1st leg command, mrconvert dwi_post_topup.nii.gz -grad grad.b - | ,
which in turn is due to the mismatch between no of volumes of the input dwi_post_topup.nii.gz (70 volumes) and grad.b table (140).
grad.b is linked to the input to the initial dwipreproc command, predwi_denoised.mif, which results among others from the concatenation of the two sets (1st AP, then 2nd PA):

     mrinfo predwi_denoised.mif
......
    Dimensions:        128 x 128 x 64 x 140
      Voxel size:        2 x 2 x 2 x ?
      Data strides:      [ -2 -3 4 1 ]
      Format:            MRtrix
      Data type:         32 bit float (little endian)
      Intensity scaling: offset = 0, multiplier = 1
      Transform:                    1           0          -0        -130
                                    0           1          -0      -106.4
                                   -0          -0           1      -44.28
      EchoTime:          0.083
    ......
      dw_scheme:         0,0,0,0
      [140 entries]      0,0,0,0
                         ...
                         -0.52680159,0.81120485,-0.25382492,700
                         0.6632604,-0.47897047,0.57504183,700
      mrtrix_version:    3.0_RC1-47-g3b789609
      pe_scheme:         0,-1,0,0.0512
      [140 entries]      0,-1,0,0.0512
                         ...
                         0,1,0,0.0512
                         0,1,0,0.0512

So grad.b has 140 entries, whereas dwi_post_topup.nii.gz:

     mrinfo dwi_post_topup.nii.gz`
    ......
      Dimensions:        128 x 128 x 64 x 70
      Voxel size:        2 x 2 x 2 x 1
      Data strides:      [ 1 2 3 4 ]
      Format:            NIfTI-1.1 (GZip compressed)
      Data type:         32 bit float (little endian)
      Intensity scaling: offset = 0, multiplier = 1
      Transform:                    1           0           0        -130
                                    0           1           0      -106.4
                                    0           0           1      -44.28
      comments:          FSL5.0

has 70 volumes. It seems that the output of the appytopup has recombined volumes of opposing PE but this did not translate in any PE table.

Please comment.

As an alternative, when trying
dwipreproc -rpe_all -pe_dir AP predwi_denoised.mif predwi_denoised_preproc.mif
I get the following error
'Unable to determine matching DWI volume pairs for reversed phase-encode combination'
although the PE dir are in the predwi_denoised.mif header’s pe scheme, as shown above.

I mention that the raw data is Siemens DICOMs, and the initial preprocessing steps have been standard:

mrconvert -datatype float32 /data/DWI1/ predwi_1.mif   # 1st set
mrconvert -datatype float32 /data/DWI2/ predwi_2.mif   # 2nd set
mrcat -axis 3 predwi_1.mif predwi_2.mif predwi.mif 
dwidenoise -noise noise.mif predwi.mif predwi_denoised.mif  

I also checked predwi_denoised.mif in mrview and it looks ok, as far as the succession of b-0 and epi images (10+60+10+60).

Octavian

Dear All/Rob,

Please address the above post if possible, I feel there may be smth wrong with dwipreproc and I am stuck.
Mine is I assume a common diffusion scheme with two sets of opposing PE and same diffusion gradient vectors, concatenated for preprocessing with topup/eddy. As intended, these could be processed with dwipreproc and -rpe_header or -rpe_all options.

If using the command (which I prefer):
dwipreproc -rpe_header predwi_denoised.mif predwi_denoised_preproc.mif

the applytopup command (line 450 in dwipreproc) generates (as it should) a 70-vol image, dwi_post_topup.nii.gz, resulting from the pairing of the corresponding 70+70 vols in the concatenated mif input, predwi_denoised.mif.
However, with the next command,
mrconvert dwi_post_topup.nii.gz -grad grad.b - |
a mismatch between the no of vols in the image, and the grad.b table (140 entries, see the end of the post), is introduced, generating the dwimask mismatch error (1st in my previous post).

If using command:
dwipreproc -rpe_all -pe_dir AP predwi_denoised.mif predwi_denoised_preproc.mif
instead,
grad_pairs output (line 233 in dwipreproc) looks like
[[0, 1], [0, 2], [0, 3], [0, 4], [0, 5], [0, 6], [0, 7], [0, 8], [0, 9], [0, 70], [0, 71], [0, 72], [0, 73], [0, 74], [0, 75], [0, 76], [0, 77], [0, 78], [0, 79], [11, 81], [12, 82], [13, 83], [14, 84], [15, 85], [16, 86], [17, 87], [18, 88], [19, 89], [20, 90], [21, 91], [22, 92], [23, 93], [24, 94], [25, 95], [26, 96], [27, 97], [28, 98], [29, 99], [30, 100], [31, 101], [32, 102], [33, 103], [34, 104], [35, 105], [36, 106], [37, 107], [38, 108], [39, 109], [40, 110], [41, 111], [42, 112], [43, 113], [44, 114], [45, 115], [46, 116], [47, 117], [48, 118], [49, 119], [50, 120], [51, 121], [52, 122], [53, 123], [54, 124], [55, 125], [56, 126], [57, 127], [58, 128], [59, 129], [60, 130], [61, 131], [62, 132], [63, 133], [64, 134], [65, 135], [66, 136], [67, 137], [68, 138], [69, 139]]
and len(grad_pairs) = 78, instead of 70 (140/2), hence the error 2 above.
Obviously, the correct grad_pairs should look like
[[0, 70], [1, 71], [2, 72], [3, 73], [4, 74], [5, 75], [6, 76], [7, 77], [8, 78], [9, 79],[10,80], [11, 81], [12, 82], [13, 83], [14, 84], [15, 85], [16, 86], [17, 87], [18, 88], [19, 89], [20, 90], [21, 91], [22, 92], [23, 93], [24, 94], [25, 95], [26, 96], [27, 97], [28, 98], [29, 99], [30, 100], [31, 101], [32, 102], [33, 103], [34, 104], [35, 105], [36, 106], [37, 107], [38, 108], [39, 109], [40, 110], [41, 111], [42, 112], [43, 113], [44, 114], [45, 115], [46, 116], [47, 117], [48, 118], [49, 119], [50, 120], [51, 121], [52, 122], [53, 123], [54, 124], [55, 125], [56, 126], [57, 127], [58, 128], [59, 129], [60, 130], [61, 131], [62, 132], [63, 133], [64, 134], [65, 135], [66, 136], [67, 137], [68, 138], [69, 139]]

So it seems that the -rpe_all option works correctly only if there is only one b=0 image for each DWI set of opposing PE dir.

With the risk of too long of a post (for which I apologize), I attach here the grad.b gradient file generated by dwipreproc via dwgrad. I can also ftp the input .mif (predwi_denoised.mif) if wanting to test it.

Thank you,
Octavian

0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0.9999665937 0.005779769848 0.005779769848 700.0000368
0.5875926931 0.3829750433 -0.7127867446 700.0002071
-0.8965316409 0.02854692621 -0.4420589213 700.000186
-0.7297876840999999 -0.4174306552 -0.5414439808 700.0000497
0.1536670776 0.9661813907 0.2070747437 699.9998396
-0.1157393372 0.7788450582999999 0.6164452781999999 699.9999132
-0.4077204677 0.4213358983 -0.8100864652 699.9999392
-0.2101675197 0.7588345748999999 -0.6164411583 699.9999357
0.09406538893999999 0.9714638658 0.2177375944 700.0001645999999
-0.1338656833 0.03835077523 -0.9902571367 700.0001743
0.1414193641 -0.7561122484 0.6389795233 700.0000583999999
0.6349663947999999 0.7495585392 0.1870285373 699.9999454
-0.07897827875000001 0.9735814178 -0.2142467137 699.9998449
0.1053177552 0.02634857879 0.9940894944000001 700.0000642
-0.2985741736 0.3936984116 -0.8693992314 700.0000299
-0.2061008557 0.8080201324 0.5519292553 699.9999612
0.330717313 0.04518756768 -0.9426474116 700.0000719
-0.8023465825 0.5941747345 -0.05653623948 700.000013
-0.3362168467 -0.7549717477 0.563006121 700.0000970999999
0.5904156618 0.7653146424 0.2563256608 699.9999956
-0.08771089305 0.4718639226 0.8772976904999999 700.0001109
-0.5275911142 0.4379350937 0.727915153 700.0001481
-0.3670493312 0.9283692136 0.05835573337 699.9999191000001
-0.310691844 0.9285377328 0.2031951203 700.0003426
0.6850654949 0.4457889702 0.5761574973 700.0000308
-0.02947340731 0.9686296317 -0.2467548475 700.0001276
0.3364008703 0.7499107038 0.5696212697 700.0001237
0.5762407491 0.02994827839 0.8167311061 700.0000752
0.2700293981 0.7533021311 0.5996832692 700.0001652
-0.935704635 -0.1912383069 0.2964536152 700.0000224
-0.8889692825 0.3163268711 0.3311660088 700.0002165
-0.8863728578 -0.03891974464 -0.4613332964 700.000193
-0.5446834922 0.592151255 0.5938659651 699.9999172
-0.3514880656 0.02077607915 0.9359618017 700.0000573
0.4139362044 0.9025600041 -0.1185000327 700.0000867
-0.7348035679 -0.008301839411 0.6782291619 700.0000993
-0.7375225303 -0.6167724619 0.2750495364 700.0000183
0.256068723 0.4135049094 0.8737519666 699.9997652
0.9173711924 0.3788423623 0.1221006136 699.9998437
-0.2561567026 -0.7709836178 0.5830677532 700.0000403
0.5895746762 0.4405645371 -0.6769819716 699.999914
-0.8920502727 -0.1924893606 0.4088938212 699.9999958
-0.6804012780000001 0.1484654387 0.7176434452 700.000107
-0.8800430634 0.3162582104 0.3542667793 700.0000423
-0.6197260936 0.7022418021 0.3504226311 700.0001953
-0.8948303882999999 -0.4363450894 -0.09424191772 700.0000338999999
0.1627313891 0.4241828577 -0.8908352251 700.0000077
-0.5060559555 0.7822293085000001 -0.363352004 699.9999847
-0.10541933 -0.4534475631 0.8850265942 699.9998669
-0.8818681135999999 0.4412505868 -0.1661521888 700.0000101000001
-0.5996046607 0.03527683298 -0.7995184776000001 699.9998816999999
-0.6934537158 0.7024538956 0.1602512667 700.0000286
0.3922631547 0.9029053048 -0.1757601432 700.0000545
-0.7614106176 0.4093902526 -0.5026464886000001 700.0000596
-0.2101465957 0.40228334 0.8910704364000001 699.9998955999999
0.3756599196 0.3857284298 0.8426702815 699.9999643
-0.7343735380999999 -0.6164237728 0.2841077944 700.0001751999999
-0.9866537536 0.1519988129 -0.05840146725 700.0000658
-0.5268015073 0.8112047227 -0.2538248802 700.0002197
0.6632603418 -0.4789704279 0.5750417795 700.0001229
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0.9999665937 -0.005779769848 0.005779769848 700.0000368
0.5875926931 0.3829750433 -0.7127867446 700.0002071
-0.8965316409 0.02854692621 -0.4420589213 700.000186
-0.7297876840999999 -0.4174306552 -0.5414439808 700.0000497
0.1536670776 0.9661813907 0.2070747437 699.9998396
-0.1157393372 0.7788450582999999 0.6164452781999999 699.9999132
-0.4077204677 0.4213358983 -0.8100864652 699.9999392
-0.2101675197 0.7588345748999999 -0.6164411583 699.9999357
0.09406538893999999 0.9714638658 0.2177375944 700.0001645999999
-0.1338656833 0.03835077523 -0.9902571367 700.0001743
0.1414193641 -0.7561122484 0.6389795233 700.0000583999999
0.6349663947999999 0.7495585392 0.1870285373 699.9999454
-0.07897827875000001 0.9735814178 -0.2142467137 699.9998449
0.1053177552 0.02634857879 0.9940894944000001 700.0000642
-0.2985741736 0.3936984116 -0.8693992314 700.0000299
-0.2061008557 0.8080201324 0.5519292553 699.9999612
0.330717313 0.04518756768 -0.9426474116 700.0000719
-0.8023465825 0.5941747345 -0.05653623948 700.000013
-0.3362168467 -0.7549717477 0.563006121 700.0000970999999
0.5904156618 0.7653146424 0.2563256608 699.9999956
-0.08771089305 0.4718639226 0.8772976904999999 700.0001109
-0.5275911142 0.4379350937 0.727915153 700.0001481
-0.3670493312 0.9283692136 0.05835573337 699.9999191000001
-0.310691844 0.9285377328 0.2031951203 700.0003426
0.6850654949 0.4457889702 0.5761574973 700.0000308
-0.02947340731 0.9686296317 -0.2467548475 700.0001276
0.3364008703 0.7499107038 0.5696212697 700.0001237
0.5762407491 0.02994827839 0.8167311061 700.0000752
0.2700293981 0.7533021311 0.5996832692 700.0001652
-0.935704635 -0.1912383069 0.2964536152 700.0000224
-0.8889692825 0.3163268711 0.3311660088 700.0002165
-0.8863728578 -0.03891974464 -0.4613332964 700.000193
-0.5446834922 0.592151255 0.5938659651 699.9999172
-0.3514880656 0.02077607915 0.9359618017 700.0000573
0.4139362044 0.9025600041 -0.1185000327 700.0000867
-0.7348035679 -0.008301839411 0.6782291619 700.0000993
-0.7375225303 -0.6167724619 0.2750495364 700.0000183
0.256068723 0.4135049094 0.8737519666 699.9997652
0.9173711924 0.3788423623 0.1221006136 699.9998437
-0.2561567026 -0.7709836178 0.5830677532 700.0000403
0.5895746762 0.4405645371 -0.6769819716 699.999914
-0.8920502727 -0.1924893606 0.4088938212 699.9999958
-0.6804012780000001 0.1484654387 0.7176434452 700.000107
-0.8800430634 0.3162582104 0.3542667793 700.0000423
-0.6197260936 0.7022418021 0.3504226311 700.0001953
-0.8948303882999999 -0.4363450894 -0.09424191772 700.0000338999999
0.1627313891 0.4241828577 -0.8908352251 700.0000077
-0.5060559555 0.7822293085000001 -0.363352004 699.9999847
-0.10541933 -0.4534475631 0.8850265942 699.9998669
-0.8818681135999999 0.4412505868 -0.1661521888 700.0000101000001
-0.5996046607 0.03527683298 -0.7995184776000001 699.9998816999999
-0.6934537158 0.7024538956 0.1602512667 700.0000286
0.3922631547 0.9029053048 -0.1757601432 700.0000545
-0.7614106176 0.4093902526 -0.5026464886000001 700.0000596
-0.2101465957 0.40228334 0.8910704364000001 699.9998955999999
0.3756599196 0.3857284298 0.8426702815 699.9999643
-0.7343735380999999 -0.6164237728 0.2841077944 700.0001751999999
-0.9866537536 0.1519988129 -0.05840146725 700.0000658
-0.5268015073 0.8112047227 -0.2538248802 700.0002197
0.6632603418 -0.4789704279 0.5750417795 700.0001229

Hi Octavian,

It seems that the output of the appytopup has recombined volumes of opposing PE …

the applytopup command (line 450 in dwipreproc) generates (as it should) a 70-vol image, dwi_post_topup.nii.gz, resulting from the pairing of the corresponding 70+70 vols in the concatenated mif input, predwi_denoised.mif.

Actually, it should not generate a 70-volume image: the applytopup call you refer to in the script explicitly requests Jacobian modulation rather than volume recombination. Can you report which version of FSL you have installed, in case a particular version is not honouring that command-line option?


Unable to determine matching DWI volume pairs for reversed phase-encode combination

This is the first time I’ve had anybody report encountering that error. While I test what I can when I make modifications to this script, the fact that its very intent is to deal with a massive potential range of inputs means that inevitably there will be possible cases that I haven’t yet considered.

Looking at the code, one possibility is that I haven’t added tolerance when looking for corresponding gradient directions, and therefore even just variance in text-to-number conversion or precision could potentially lead to an error. This is one case where having access to the data would most definitely help me reproduce the fault and therefore work through potential solutions.

grad_pairs output (line 233 in dwipreproc) looks like … So it seems that the -rpe_all option works correctly only if there is only one b=0 image for each DWI set of opposing PE dir.

OK, looks like I must have gotten that block of code working for the data set I have available for testing this code path, but indeed that must have only contained a single b=0 per phase encoding direction. As previously, if I could have access to an independent data set (rather than acquiring / manufacturing something myself), that would help me in trying to have this script accept and operate correctly on the widest possible range of data.


I feel there may be smth wrong with dwipreproc and I am stuck.

Ultimately, dwipreproc is merely a convenience script wrapping the functionality of topup / applytopup / eddy. So if you need to process data more urgently than I can potentially work through issues in the script, it may be necessary for you to instead interface with those commands directly. While I do my best to provide this script to ease others’ image pre-processing, it’s not actually the research I’m supposedly paid to do :-/

Rob

Dear All/Rob,

it goes without saying that we are trilled to work with the mrtrix3 team and greatly impressed by the level of assist and promptness on this forum.

  1. As to the -rpe-all error, I changed dwipreproc a little to get the correct image pairs based on identical gradient directions. The lines below assume (as -rpe_all does) that 1/2 half volumes are one PE, and the 2nd half the reversed PE with exactly the same gradient direction sequence from one vol to another; it accommodates multiple b=0 images, also multiple dwi images with identical gradient directions (if that unlikely situation arises).
    At line 223-233, instead of
  elif PE_design == 'All':
    grad_matchings = [ num_volumes ] * num_volumes
    grad_pairs = [ ]
    for index1 in range(num_volumes):
      if grad_matchings[index1] == num_volumes: # As yet unpaired
        for index2 in range(index1+1, num_volumes):
          if grad_matchings[index2] == num_volumes: # Also as yet unpaired
            if grad[index1] == grad[index2]:
              grad_matchings[index1] = index2;
              grad_matchings[index2] = index1;
              grad_pairs.append([index1, index2])

the following:

      elif PE_design == 'All':
        grad_matchings = [ num_volumes ] * num_volumes
        grad_pairs = [ ]
        for index1 in range(num_volumes/2):  # CHANGED 
            for index2 in range(num_volumes/2, num_volumes):  # CHANGED 
             if grad_matchings[index1] == num_volumes: # CHANGED  LOCATION
              if grad_matchings[index2] == num_volumes: # Also as yet unpaired
                if grad[index1] == grad[index2]:
                  grad_matchings[index1] = index2;
                  grad_matchings[index2] = index1;
                  grad_pairs.append([index1, index2])
  1. I use FSL 5.09 after patch. It is one of the latest versions. Reproducing from the current fsl wiki
    https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/topup/ApplyTopupUsersGuide
    "applytopup --imain=my_blipup,my_blipdown --datain=my_parameters --inindex=1,2 --topup=my_field --out=my_good_images where my_blipup is a 4D file containing volumes acquired with positive phase-encode blips and my_blipdown contains volumes acquired with negative blips. The resulting undistorted file will be a combination of the two input volumes, where the details of that combination depends on the --method parameter. Hence, the two files must contain data that is identical save for the acquisition parameters. If e.g. my_blipup consists of a b0 volume followed by three dwis with diffusion gradients [1 0 0], [0 1 0] and [0 0 1], then my_blipdown must contain a b0 volume followed by dwis corresponding to [1 0 0], [0 1 0] and [0 0 1]. The output (my_good_images) will then contain a single copy of a b0 followed by [1 0 0], [0 1 0] and [0 0 1] dwis.

When using --method=jac it is in principle possible to generate one unwarped volume per input volue. However, all files specified together for --imain will be combined into a single output file. If one would want separate distortion corrected images (e.g. if one has scanned different sets of diffusion gradients for the two acquisitions) one can obtain that by applytopup --imain=my_blipup --datain=my_parameters --inindex=1 --topup=my_field --method=jac --out=my_good_blipup_images applytopup --imain=my_blipdown --datain=my_parameters --inindex=2 --topup=my_field --method=jac --out=my_good_blipdown_images If one specifies more than two input files they will all be combined into a single output file. Let us say e.g. one has acquired two repeats with blipup and one repeat with blipdown one can run
applytopup --imain=my_blipup1,my_blipup2,my_blipdown --datain=my_parameters --inindex=1,2,3 --topup=my_field --out=my_good_images in which case my_good_images will represent a combination of all three inputs. "

So I modified line 450

  run.command(applytopup_cmd + ' --imain=' + ','.join(applytopup_image_list) + ' --datain=applytopup_config.txt --inindex=' + ','.join(applytopup_index_list) + ' --topup=field --out=dwi_post_topup' + fsl_suffix + ' --method=jac')

to

run.command(applytopup_cmd + ' --imain=' + applytopup_image_list[0] + ' --datain=applytopup_config.txt --inindex=' + applytopup_index_list[0] + ' --topup=field --out=dwi_post_topup' +  applytopup_index_list[0] + fsl_suffix + ' --method=jac')  # ADDED 
run.command(applytopup_cmd + ' --imain=' + applytopup_image_list[1] + ' --datain=applytopup_config.txt --inindex=' + applytopup_index_list [1] + ' --topup=field --out=dwi_post_topup' + applytopup_index_list[1] + fsl_suffix + ' --method=jac')  # ADDED 
run.command('mrcat -axis 3 dwi_post_topup' + applytopup_index_list[0] + fsl_suffix + ' dwi_post_topup' + applytopup_index_list[1] + fsl_suffix + ' dwi_post_topup' + fsl_suffix) # ADDED 

I guess if one has more than two sets one can loop over

for ind in range(applytopup_index_list)
run.command(applytopup_cmd + ' --imain=' + applytopup_image_list[ind] + ' --datain=applytopup_config.txt --inindex=' + applytopup_index_list[ind] + ' --topup=field --out=dwi_post_topup' +  applytopup_index_list[ind] + fsl_suffix + ' --method=jac')  
run.command('mrcat -axis 3 dwi_post_topup[' + ','.join(applytopup_index_list) + ']' + fsl_suffix + ' dwi_post_topup' + fsl_suffix)

(haven’t tested the latter though)

Thank you, please let me know what you think, again, I am more that happy to share the mif input to dwipreproc or the source dicom files.

Octavian

Octavian

Thanks for the suggestions and the references. Given the ongoing discussion is likely to remain fairly technical, I’d like to move the discussion over to the relevant GitHub issue so as not to pollute everybody’s inboxes with even more Python :innocent:

Cheers
Rob

Not to drag this back up from the depths, but I seem to be hitting the same or similar issue on a dataset.

i have two acquisition ( a->p, p->a ) with identical gradient tables. i’ve generated mifs and concatenated them, but when i try dwipreproc i hit the same error.

my command:
/usr/local/packages/mrtrix3/bin/dwipreproc dwi.mif dwi_corr.mif -rpe_all -pe_dir AP -readout_time 0.740 -debug

the part of the log with error:
dwipreproc: [DEBUG] phaseEncoding.direction() (from dwipreproc:258): ap -> [0, -1, 0]
dwipreproc: [DEBUG] (from dwipreproc:259) 'manual_pe_dir' = [0.0, -1.0, 0.0]
dwipreproc: [DEBUG] (from dwipreproc:263) 'manual_trt' = 0.74
dwipreproc: [DEBUG] (dwipreproc:341): Commencing gradient direction matching; 184 volumes
dwipreproc: [DEBUG] (dwipreproc:350): Matched volume 0 with 92: [0.0, 0.0, 0.0, 0.0] [0.0, 0.0, 0.0, 0.0]
dwipreproc: [DEBUG] (dwipreproc:350): Matched volume 1 with 93: [0.0, 0.0, 0.0, 0.0] [0.0, 0.0, 0.0, 0.0]
dwipreproc: [ERROR] Unable to determine matching reversed phase-encode direction volume for DWI volume 2

info about the cat’d file

tesla:mrt cmp12$ mrinfo dwi.mif 
************************************************
Image:               "dwi.mif"
************************************************
  Dimensions:        147 x 147 x 92 x 184
  Voxel size:        1.5 x 1.5 x 1.5 x 0
  Data strides:      [ -1 2 3 4 ]
  Format:            MRtrix
  Data type:         32 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0           0        -103
                               -0           1           0      -67.53
                               -0           0           1      -73.87
  command_history:   mrconvert "-fslgrad" "../bvecs" "../bvals" "../dwi.nii.gz" "dwiO.mif"  (version=3.0_RC3-109-g03394dd5)
                     mrresize "-vox" "1.5" "dwiO.mif" "dwi.mif" "-force"  (version=3.0_RC3-109-g03394dd5)
  dw_scheme:         0,0,0,0
  [184 entries]      0,0,0,0
                     ...
                     -0.035,0.691,0.722,3000
                     0.333,-0.606,0.722,3000
  mrtrix_version:    3.0_RC3-109-g03394dd5

i also tried to throw away 1 B0 from each of the acquisitions like mentioned above, but hit the same error.

mrtrix_version: 3.0_RC3-109-g03394dd5
fsl-6.0.0

When i try with 1 B0 each acquisition

Command:  dirstat dwi.mif -output asym
          dirstat: [INFO] reading config file "/etc/mrtrix.conf"...
          dirstat: [INFO] opening image "dwi.mif"...
          dirstat: [INFO] image "dwi.mif" opened with dimensions 147x147x92x182, voxel spacing 1.5x1.5x1.5x0, datatype Float32LE
          dirstat: [INFO] found 182x4 diffusion gradient table
          dirstat: [INFO] b-values will be scaled by the square of DW gradient norm
          dirstat: [INFO] Diffusion gradient encoding data clustered into 2 non-zero shells and 2 b=0 volumes
dwipreproc: [WARNING] sampling of b=1500 shell is moderately asymmetric; distortion correction may benefit from use of: -eddy_options " ... --slm=linear ... "
dwipreproc: [WARNING] sampling of b=3000 shell is moderately asymmetric; distortion correction may benefit from use of: -eddy_options " ... --slm=linear ... "
dwipreproc: [DEBUG] phaseEncoding.direction() (from dwipreproc:258): ap -> [0, -1, 0]
dwipreproc: [DEBUG] (from dwipreproc:259) 'manual_pe_dir' = [0.0, -1.0, 0.0]
dwipreproc: [DEBUG] (from dwipreproc:263) 'manual_trt' = 0.74
dwipreproc: [DEBUG] (dwipreproc:341): Commencing gradient direction matching; 182 volumes
dwipreproc: [DEBUG] (dwipreproc:350): Matched volume 0 with 91: [0.0, 0.0, 0.0, 0.0] [0.0, 0.0, 0.0, 0.0]
dwipreproc: [ERROR] Unable to determine matching reversed phase-encode direction volume for DWI volume 1

Gradients table on the concatenated:

0 0 0 0
0 0 0 0
0.707107 0 0 3000
0.323148 0.629325 0 3000
-0.187383 0.342947 0.589727 3000
0.662559 -0.200818 0.142836 3000
0.044548 -0.569928 0.415779 3000
-0.480126 -0.066468 0.514774 3000
0.485782 0.197283 0.474469 3000
-0.164756 0.671751 0.147785 3000
0.65266 0.126572 0.241831 3000
-0.078489 -0.692965 -0.115966 3000
-0.093338 -0.603869 -0.355675 3000
0.259508 -0.543765 -0.369817 3000
-0.205768 -0.49851 0.457498 3000
-0.478004 0.504874 0.130815 3000
-0.423557 0.055154 -0.563564 3000
-0.518309 -0.480126 0.027577 3000
0.565685 -0.152735 -0.395273 3000
0.394566 -0.241123 -0.534573 3000
-0.307591 -0.423557 -0.475176 3000
-0.555079 0.421436 -0.120208 3000
0.350725 0.559321 0.252437 3000
-0.46669 0.306884 -0.434164 3000
0.595384 -0.10253 0.367696 3000
0.101823 0.304056 0.630032 3000
-0.213546 0.199404 -0.644174 3000
0.161927 -0.658316 0.200818 3000
0.666802 0.008485 -0.236174 3000
0.007778 -0.017678 0.707107 3000
0.284964 0.599627 -0.243952 3000
0.651952 0.274357 -0.007071 3000
0.028284 0.344361 -0.616597 3000
-0.210011 0.103238 0.667509 3000
-0.264458 -0.11738 -0.644881 3000
-0.201525 -0.155563 0.659731 3000
-0.605283 -0.22486 0.2885 3000
-0.638517 0.270822 0.137886 3000
0.381131 -0.515481 0.298399 3000
-0.337997 0.62084 -0.028284 3000
0.540937 0.375474 0.257387 3000
-0.366988 -0.301935 0.523259 3000
0.473054 0.429214 -0.303349 3000
-0.073539 -0.688015 0.144957 3000
-0.46669 0.403051 0.346482 3000
-0.024749 0.488611 0.510531 3000
0.235467 -0.428507 0.510531 3000
1 0 0 3000
0.457 0.89 0 3000
-0.265 0.485 0.834 3000
0.937 -0.284 0.202 3000
0.063 -0.806 0.588 3000
-0.679 -0.094 0.728 3000
0.687 0.279 0.671 3000
-0.233 0.95 0.209 3000
0.923 0.179 0.342 3000
-0.111 -0.98 -0.164 3000
-0.132 -0.854 -0.503 3000
0.367 -0.769 -0.523 3000
-0.291 -0.705 0.647 3000
-0.676 0.714 0.185 3000
-0.599 0.078 -0.797 3000
-0.733 -0.679 0.039 3000
0.8 -0.216 -0.559 3000
0.558 -0.341 -0.756 3000
-0.435 -0.599 -0.672 3000
-0.785 0.596 -0.17 3000
0.496 0.791 0.357 3000
-0.66 0.434 -0.614 3000
0.842 -0.145 0.52 3000
0.144 0.43 0.891 3000
-0.302 0.282 -0.911 3000
0.229 -0.931 0.284 3000
0.943 0.012 -0.334 3000
0.011 -0.025 1 3000
0.403 0.848 -0.345 3000
0.922 0.388 -0.01 3000
0.04 0.487 -0.872 3000
-0.297 0.146 0.944 3000
-0.374 -0.166 -0.912 3000
-0.285 -0.22 0.933 3000
-0.856 -0.318 0.408 3000
-0.903 0.383 0.195 3000
0.539 -0.729 0.422 3000
-0.478 0.878 -0.04 3000
0.765 0.531 0.364 3000
-0.519 -0.427 0.74 3000
0.669 0.607 -0.429 3000
-0.104 -0.973 0.205 3000
-0.66 0.57 0.49 3000
-0.035 0.691 0.722 3000
0.333 -0.606 0.722 3000
0 0 0 0
0 0 0 0
0.707107 0 0 3000
0.323148 0.629325 0 3000
-0.187383 0.342947 0.589727 3000
0.662559 -0.200818 0.142836 3000
0.044548 -0.569928 0.415779 3000
-0.480126 -0.066468 0.514774 3000
0.485782 0.197283 0.474469 3000
-0.164756 0.671751 0.147785 3000
0.65266 0.126572 0.241831 3000
-0.078489 -0.692965 -0.115966 3000
-0.093338 -0.603869 -0.355675 3000
0.259508 -0.543765 -0.369817 3000
-0.205768 -0.49851 0.457498 3000
-0.478004 0.504874 0.130815 3000
-0.423557 0.055154 -0.563564 3000
-0.518309 -0.480126 0.027577 3000
0.565685 -0.152735 -0.395273 3000
0.394566 -0.241123 -0.534573 3000
-0.307591 -0.423557 -0.475176 3000
-0.555079 0.421436 -0.120208 3000
0.350725 0.559321 0.252437 3000
-0.46669 0.306884 -0.434164 3000
0.595384 -0.10253 0.367696 3000
0.101823 0.304056 0.630032 3000
-0.213546 0.199404 -0.644174 3000
0.161927 -0.658316 0.200818 3000
0.666802 0.008485 -0.236174 3000
0.007778 -0.017678 0.707107 3000
0.284964 0.599627 -0.243952 3000
0.651952 0.274357 -0.007071 3000
0.028284 0.344361 -0.616597 3000
-0.210011 0.103238 0.667509 3000
-0.264458 -0.11738 -0.644881 3000
-0.201525 -0.155563 0.659731 3000
-0.605283 -0.22486 0.2885 3000
-0.638517 0.270822 0.137886 3000
0.381131 -0.515481 0.298399 3000
-0.337997 0.62084 -0.028284 3000
0.540937 0.375474 0.257387 3000
-0.366988 -0.301935 0.523259 3000
0.473054 0.429214 -0.303349 3000
-0.073539 -0.688015 0.144957 3000
-0.46669 0.403051 0.346482 3000
-0.024749 0.488611 0.510531 3000
0.235467 -0.428507 0.510531 3000
1 0 0 3000
0.457 0.89 0 3000
-0.265 0.485 0.834 3000
0.937 -0.284 0.202 3000
0.063 -0.806 0.588 3000
-0.679 -0.094 0.728 3000
0.687 0.279 0.671 3000
-0.233 0.95 0.209 3000
0.923 0.179 0.342 3000
-0.111 -0.98 -0.164 3000
-0.132 -0.854 -0.503 3000
0.367 -0.769 -0.523 3000
-0.291 -0.705 0.647 3000
-0.676 0.714 0.185 3000
-0.599 0.078 -0.797 3000
-0.733 -0.679 0.039 3000
0.8 -0.216 -0.559 3000
0.558 -0.341 -0.756 3000
-0.435 -0.599 -0.672 3000
-0.785 0.596 -0.17 3000
0.496 0.791 0.357 3000
-0.66 0.434 -0.614 3000
0.842 -0.145 0.52 3000
0.144 0.43 0.891 3000
-0.302 0.282 -0.911 3000
0.229 -0.931 0.284 3000
0.943 0.012 -0.334 3000
0.011 -0.025 1 3000
0.403 0.848 -0.345 3000
0.922 0.388 -0.01 3000
0.04 0.487 -0.872 3000
-0.297 0.146 0.944 3000
-0.374 -0.166 -0.912 3000
-0.285 -0.22 0.933 3000
-0.856 -0.318 0.408 3000
-0.903 0.383 0.195 3000
0.539 -0.729 0.422 3000
-0.478 0.878 -0.04 3000
0.765 0.531 0.364 3000
-0.519 -0.427 0.74 3000
0.669 0.607 -0.429 3000
-0.104 -0.973 0.205 3000
-0.66 0.57 0.49 3000
-0.035 0.691 0.722 3000
0.333 -0.606 0.722 3000

my issues is coming up with the GE gradient table hack for mult-shell with the grads_match function and using the dot_product of the gradients. To get a mutli-shell scan on GE without just replicating the same gradient table GE will use a modified table where the dot_product will return half ( or a different percentage ) to get a new bvalue.

In the gradient table above a bval of 3000 is returning me shells of 0,1500,3000.

ipdb> grad[index1]
[0.707107, 0.0, 0.0, 3000.0]
ipdb>  grad[index2]
[0.707107, 0.0, 0.0, 3000.0]
ipdb> grads_match(grad[index1], grad[index2])
False

Because of the table configuration the dot_product in our case will be .500 ( which is our 1500 bval )

> /usr/local/packages/mrtrix3/bin/dwipreproc(280)grads_match()
    278     dot_product = one[0]*two[0] + one[1]*two[1] + one[2]*two[2]
    279     if abs(dot_product) < 0.999:
--> 280       return False


ipdb> abs(dot_product)
0.5000003094490001

I’m testing dwipreproc with this change

    if abs(dot_product) < 0.999:
        if abs(one[0]-two[0] + one[1]-two[1] + one[2]-two[2]) > 0:
            return False

Ok, I think this stems from my attempts at preserving the DW scheme exactly as it was in the DICOM headers, and delaying the scaling by b-value and unit normalisation until the point of use. We are going to change this behaviour as it causes too many issues – see discussion here.

One way to fix this is to use mrinfo -export_grad_mrtrix to write out the DW scheme with all modifications applied, at which point you should have the correct b-values and unit normalised gradients. Then re-import them, either using mrconvert -grad to generate a new dwi.mif with the updated DW scheme (my recommendation), or by passing the DW scheme file to dwipreproc directly with the -grad option.

Hopefully that’ll allow you to proceed for now. I’m hoping this won’t be an issue in the future once we fix this up and release the next version…

Great, thanks for the info … I’ll update my processing stream here and share info with others