Dwipreproc - eddy ERROR


#10

If you are able to go back to the original DICOMs and run eddy without a problem, it would be useful for us to get an example of your images. If indeed some anonymisation process is preventing the correct conversion of Siemens DICOMs, this error should preferably be raised well before dwipreproc gets to the point of invoking eddy. I would also be curious to know exactly what type of input image is able to survive mrconvert but cause a segmentation violation in eddy (FMRIB may also be interested to see such an image).


#11

@rsmith: the problem is that the DICOM data were provided in mosaic format. If you strip out the Siemens CSA info, MRtrix3 can’t reformat these into 3 volumes - they remain as 2D slices with all the slices in a single large montage. If the user also provides the DW gradient info manually (which they did), then I guess eddy is the first command that will actually fail (no topup used on this invocation). There’s a good chance the mask produced by dwi2mask will also be empty, given that the cleanup operations operate at a 3D level, and this is likely to cause eddy to then crash out - but dwi2mask probably won’t itself crash (might be a idea for it to raise an error if the mask is empty, though…).

So either an empty mask, or the fact that eddy's been presented with a single slice, which means even trilinear interpolation can’t be done, for example, or there can’t be any through-slice gradients for registration, or any number of other related problems…


#12

Hi, I also encountered the same problem that dwipreproc doesn’t work during eddy command.
I tried to do dwipreproc from DICOM and NIFTI after mrconvert respectively, still have the same error. When I tried to convert DICOM to NIFTI by MRICron and run dwipreproc, it does work.

I found that dimensions of the nifti files from the two different ways are a little different. Actually, this data should be 128 x 128 x 75 x 33. But I’m not sure if this is an important problem for that eddy doesn’t work.

From MRICron
Dimensions: 128 x 128 x 75 x 33
Voxel size: 2 x 2 x 2 x 10.0674
Data strides: [ -1 2 3 4 ]
Format: NIfTI-1.1 (GZip compressed)
Data type: signed 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 2.5892550945281982
Transform: 0.9939 -0.1092 0.01662 -114.9
0.1103 0.988 -0.1081 -124.4
-0.004625 0.1092 0.994 -85.37
comments: TE=91.52799988;sec=73829.0400

From MRtrix
Dimensions: 128 x 128 x 75 x 34
Voxel size: 2 x 2 x 2 x ?
Data strides: [ -1 -2 3 4 ]
Format: NIfTI-1.1 (GZip compressed)
Data type: unsigned 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 2.5892550945281982
Transform: 0.9939 -0.1092 0.01662 -114.9
0.1103 0.988 -0.1081 -124.4
-0.004625 0.1092 0.994 -85.37
mrtrix_version: 3.0_RC2-2-gca446aad


#13

OK, that sounds like a different problem again from the others mentioned in this thread…

My guess is your data come from a Philips scanner…? They have a habit of adding an additional image at the end of the series, which I think is a mean DWI image, computed from the acquired data. Clearly this is not an actual diffusion-weighted image, and typically its DW encoding entry looks ‘odd’ - on our scanners, it shows up as a 0 0 0 1000: a zero vector with a non-zero b-value… This is clearly going cause all manner of confusion for any downstream processing. You could verify this by inspecting the bvecs & bvals files to see if that is the case here (i.e. last column of bvecs contains zeros, but last entry of bvals is non-zero).

Assuming that is indeed the problem, you’ll probably find that updating your installation to the latest version, freshly released a few days ago, fixes the issue since it contains improved handling of DICOM data that should actually be able to deal with precisely these types of data (since the additional computed image shows up with a different ImageType entry in the DICOM headers)…


#14

Thanks for your response
Yes, the data come from a Philips scanner. Their data is as your said.
I build the MRtrix (RC2-2-gca446aad) at Aug 9 2017. I guess that is new version.
I will try again


#15

Hello

I have had a similar issue to the above. When I run dwipreproc -rpe_none DWI_denoise.mif -fslgrad bvecs bvals DWI_eddy.mif -pe_dir AP I get an error,

[ERROR] Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy (dwipreproc:467)

If I invoke the failing eddy command in the temporary folder it works. You suggested a buggy python or interference from locale settings. Whilst not an mrtrix issue I was wondering if you knew of how I could go about fixing this? Or given that eddy is running in the temporary folder should I just use the eddy command manually in a script if that’s easier?

Thanks for your help!

Paul


#16

Paul: Can you provide the full error message? The earlier mention in this thread of the locale settings was only a hypothesis, and as far as I can see there was no confirmation from any user that this was indeed the cause of their problem. This thread now has a range of different issues reported, so we really need to see the full details in order to narrow down our suggestions.


#17

Of course.

Command:  mrconvert /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/DWI_dn.mif /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/dwipreproc-tmp-VBJUWX/dwi.mif -fslgrad /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/bvecs /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/bvals
dwipreproc: Changing to temporary directory (/home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/dwipreproc-tmp-VBJUWX/)
dwipreproc: [WARNING] Total readout time not provided at command-line; assuming sane default of 0.1
Command:  mrinfo dwi.mif -export_grad_mrtrix grad.b
Command:  dwi2mask dwi.mif - | maskfilter - dilate - | mrconvert - mask.nii -datatype float32 -stride -1,+2,+3
Command:  mrconvert dwi.mif -import_pe_table dwi_manual_pe_scheme.txt dwi.nii -stride -1,+2,+3,+4 -export_grad_fsl bvecs bvals -export_pe_eddy eddy_config.txt eddy_indices.txt
Command:  eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
dwipreproc: 
dwipreproc: **[ERROR]** Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy (dwipreproc:467)
dwipreproc: Output of failed command:
I'm thrown
terminate called after throwing an instance of 'EDDY::KMatrixException'
  what():  KMatrixException: msg=MultiShellKMatrix::SetDiffusionPar: Data not shelled
dwipreproc: Changing back to original directory (/home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628)
dwipreproc: Script failed while executing the command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
dwipreproc: For debugging, inspect contents of temporary directory: /home/trackhd/Desktop/TrackStorage/Paul/connect/trackon_noddi/NIFTI_ORIG_All/028502628/dwipreproc-tmp-VBJUWX/

Then by invoking eddy manually in the temp folder like so; eddy --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_eddy it works to produce an eddy corrected file.

Thanks for your help


#18

The actual error is here:

Your b-values are not sufficiently consistent for each shell, and eddy throws out the data in case they were not acquired using a multi-shell scheme. If you know your data are multi-shell (not DSI), you can force eddy to accept your data with the right option - see the FSL wiki for details. You should be able to pass that option using the -eddy_options option to dwipreproc.

As to why your manual eddy call works, I’m guessing this is because your eddy and eddy_openmp are from different versions of FSL, and one of them is more strict than the other. On my system, FSL 5.0.8 only provides eddy, while 5.0.9 provides eddy_openmp and eddy_cuda - no eddy as such…


#19

One other possibility of what might be going on here, since I’ve seen a couple of people being forced to use the --data_is_shelled option:

In MRtrix3, we run a clustering algorithm in order to group volumes into shells according to b-value, which accounts for the fact that the b-values of those volumes may not be precisely equivalent. In addition to the b-values that are provided in the DICOMs, these values may additionally be perturbed by MRtrix3 when it normalises each diffusion gradient direction and applies the corresponding scaling to the b-value. Therefore, if eddy does not account for the possibility of small variations in b-value, it’s possible that a bvecs / bvals pair created by an MRtrix3 command (e.g. in the middle of dwipreproc) may cause eddy to stumble, whereas using the “original” bvecs / bvals and invoking eddy directly may work.

Just a hypothesis right now… Wouldn’t explain why @uclpz was able to run eddy directly from within the script temporary directory, that’s more likely an eddy version mismatch as @jdtournier suggested. But just putting the idea out there in case many people are encountering this “Data not shelled” issue.


#20

Yeah, depending on your FSL version, the definition of “shelled” (or not) may be rather strict. This discussion was historically started somewhere here, if I recall correctly: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=fsl;9bfdeaed.1510

Note that there’s also criteria on numbers of directions per shell, and especially these used to be (or are still) rather strict, resulting in rejection of even quite “common” protocols. I’m not sure what their exact constraints/heuristics currently are, or whether these are explicitly documented somewhere though…


#21

Thanks for your help on this. My data is definitely multishell. I did inspect my bvalues which are consistent for each shell - 0, 700, 2000. Curiously if I use the data is shelled option using the command;

dwipreproc DWI_dn.mif DWI_eddy_bval.mif -rpe_none -pe_dir AP -fslgrad bvecs bvals -eddy_options "--data_is_shelled " 

I now get the following error below. Any ideas to the cause of this? Thanks again for all your help.

Traceback (most recent call last):
  File "/midas-data/software/mrtrix3_25.5.17/bin/dwipreproc", line 506, in <module>
    run.command('mrconvert dwi_post_eddy' + fsl_suffix + ' result.mif' + stride_option + ' -fslgrad ' + bvecs_path + ' bvals')
  File "/midas-data/software/mrtrix3_25.5.17/lib/mrtrix3/run.py", line 61, in command
    shebang = _shebang(line[0])
  File "/midas-data/software/mrtrix3_25.5.17/lib/mrtrix3/run.py", line 329, in _shebang
    path = find_executable(exeName(item))
  File "/usr/lib64/python2.6/distutils/spawn.py", line 191, in find_executable
    if not os.path.isfile(executable):
  File "/usr/lib64/python2.6/genericpath.py", line 29, in isfile
    st = os.stat(path)
TypeError: stat() argument 1 must be encoded string without NULL bytes, not str
[trackhd@pc8-024 060443961]$ dwipreproc DWI_dn.mif DWI_eddy_bval.mif -rpe_none -pe_dir AP -fslgrad bvecs bvals -eddy_options "--data_is_shelled "

#22

I think you have to add one whitespace character after your double quotes, i.e.
" –data_is_shelled "


#23

Given this output:

It seems to me more likely that the problem might be due to using python version 2.6. As stated in the docs, we require at least version 2.7, at least for the configure & build steps… Worth trying with version 2.7 or 3.X, it might be as simple as that.


#24

Hello all,

I am having a similar issue with the ones mentioned above. When running " dwipreproc data_denoise.mif/ dwi_preprocessed.mif -rpe_none -pe_dir j- " I get the following error:

[ERROR] Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy (dwipreproc:518)
dwipreproc: Output of failed command:
eddy: msg=AcqPara::AcqPara: Unrealistic read-out time
terminate called after throwing an instance of 'EDDY::EddyException'
  what():  eddy: msg=AcqPara::AcqPara: Unrealistic read-out time
dwipreproc: Changing back to original directory (/home/suminiky/Downloads/MRTRIX)
dwipreproc: Script failed while executing the command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
dwipreproc: For debugging, inspect contents of temporary directory: /home/suminiky/Downloads/MRTRIX/dwipreproc-tmp-Y06916/

Afterwards, when running eddy in the temp folder I get this:

eddy: msg=AcqPara::AcqPara: Unrealistic read-out time
terminate called after throwing an instance of 'EDDY::EddyException'
  what():  eddy: msg=AcqPara::AcqPara: Unrealistic read-out time
Aborted (core dumped)

Any ideas on what the issue could be?

Best,
Sabina


#25

Hi Sabina,

This is in fact an unrelated error, which has been reported here. This is not an error within dwipreproc, but something that is generated within eddy that dwipreproc is simply passing along. It claims that the EPI total readout time of your data is not “realistic”, and hence there must have been some kind of error made during your data preparation.

Due to the relationship between readout time, field inhomogeneity estimation, and geometric correction of EPI distortions, you should simply be able to e.g. halve the readout times in all of your images, and processing should operate as expected. The mrconvert -set_property option should be useful for this, in addition to this development-branch documentation page (not yet part of the main documentation, but will be soon).

Rob


#26

Hi Rob,

The answer you gave me worked last time, so thank you! However, now I need to analyze a new set of data and I am yet again receiving an error, but a different one:

dwipreproc: [ERROR] Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy (dwipreproc:518)
dwipreproc: Output of failed command:
I’m thrown
terminate called after throwing an instance of ‘EDDY::KMatrixException’
what():
dwipreproc: Changing back to original directory (/home/suminiky/Documents/DATA/Menzel_preop)
dwipreproc: Script failed while executing the command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy

What could be wrong this time?

Best,
Sabina


#27

Hello all,

I am having a similar issue with the ones mentioned above. When running “dwipreproc dwi_denoised.mif dwi_processed.mif -pe_dir AP -rpe_all -readout_time 0.124” I get the following error:

Command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --out=dwi_post_eddy
dwipreproc:
dwipreproc: [ERROR] Command failed: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --out=dwi_post_eddy (dwipreproc:518)
dwipreproc: Output of failed command:
dwipreproc: Changing back to original directory (/home/wpy/Desktop/FBA/p01)
dwipreproc: Script failed while executing the command: eddy_openmp --imain=dwi.nii --mask=mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --topup=field --out=dwi_post_eddy
dwipreproc: For debugging, inspect contents of temporary directory: /home/wpy/Desktop/FBA/p01/dwipreproc-tmp-L9W43S/

Do you have any ideas of what could be wrong?

Regards,
Pinyi Wang


#28
I’m thrown
terminate called after throwing an instance of ‘EDDY::KMatrixException’
what():

This error is entirely internal to eddy; MRtrix3’s dwipreproc script is simply passing this error message from the underlying command to the user. So I can really only suggest going into the temporary directory that was preserved by the script, and attempting to invoke eddy directly. You can also manually inspect all of the files that are being provided as input to eddy, and ensure that they are sensible according to the usage of that command. If that seems to be the case, then your question should instead be posed on the FSL mailing list, as it is independent of MRtrix3.

Note: If you say to FSL that you’ve encountered this issue when trying to run an MRtrix3 script, they won’t help you. You must validate yourself that the issue is indeed with eddy, and not with MRtrix3’s wrapping thereof, and then report it as such. Alternatively, if your investigation shows that dwipreproc is providing inappropriate data to eddy, then this is precisely the information that needs to be provided here in order for the issue to be fixed within MRtrix3.

dwipreproc: Output of failed command:
dwipreproc: Changing back to original directory (/home/wpy/Desktop/FBA/p01)

In your case @PinyiWang, eddy appears to not be providing any error message to the terminal whatsoever. Nevertheless, even in this case, the same instructions as given above to @Sabina_R apply to your case also.


#29

Thanks for your response!
I will try it!

Best,
Pinyi