No phase-encoding contrast in input DWIs or fmap

[elella1]

Hi!

I have a question about the BIDS-Apps/MRtrix3_connectome Docker. I have organized my dcm images in accordance with the BIDS specification. In my bids_dir I have the sub- folder containing the anat and the dwi folder. The dwi folder contains the json file, the 4D nifti, the .bvec and .bval files. When I run the docker I get the following error: [ERROR] Inadequate data for pre-processing of subject 'sub-': No phase-encoding contrast in input DWIs or fmap/ directory What I'm doing wrong?

Thanks a lot!

[Lestropie]

Hi @elella1,

Since the BIDS Apps are also on GitHub, issues specific to those apps can be posted there directly using a GitHub account; this is the main MRtrix3 repository, so is best reserved for questions that are specific to the software itself.

Nevertheless: The reason for the error is that the script is predicated on the ability to correct EPI susceptibility-induced distortions. This is a pre-requisite for the use of Anatomically-Constrained Tractography (ACT). The only way that these distortions can be corrected is if either:

• Spin-echo images with different phase encoding directions / readout times are provided in the fmap/ directory;

• The dwi/ directory itself contains more than one DWI series, and those series have different phase encoding directions / readout times.

I refer to this as phase encoding contrast. Images with different geometric distortions due to differences in phase encoding are necessary to enable estimation of the susceptibility field, and hence correction of those geometric distortions. Without the ability to correct those distortions, the script cannot proceed. In the future we may release a method that attempts to correct these distortions using the subject's T1-weighted image, but this is not yet available.

Rob

[elella1]

Dear Rob,

thank you for your answer. I solved that problem. Now I have another problem with the dwipreproc step: run.py: [ERROR] Command failed: dwipreproc dwi_unring.mif dwi_preprocessed.mif -rpe_header (run.py:248) dwipreproc: [ERROR] No phase encoding information found in DWI image header. As far as I know, this information can be imported from the .json file that accompanies the dwi images. In the error file I can read that the json is imported in the mrvonvert command:

Command: mrconvert /bids_dataset/sub-003_S_0908/dwi/sub-003_S_0908_dwi.nii -fslgrad /bids_dataset/sub-003_S_0908/dwi/sub-003_S_0908_dwi.bvec /bids_dataset/sub-003_S_0908/dwi/sub-003_S_0908_dwi.bval -json_import /bids_dataset/sub-003_S_0908/dwi/sub-003_S_0908_dwi.json /run.py-tmp-VIFX2R/dwi1.mif

So the .mif should contain an header with the phase encoding information. I have no idea on how to solve this problem. Please, can you help me?

It's really important for me.

I send to you in attachement the screenshot of the error file and of my json file created by means of Dcm2Bids (the json seems to be ok).

Thank you very much.

Eufemia

Il 24 aprile 2018 alle 5.21 Robert Smith notifications@github.com ha scritto:

Hi @elella1 https://github.com/elella1 ,

Since the BIDS Apps are also on GitHub, issues specific to those apps can be posted there directly using a GitHub account; this is the main MRtrix3 repository, so is best reserved for questions that are specific to the software itself.

Nevertheless: The reason for the error is that the script is predicated on the ability to correct EPI susceptibility-induced distortions. This is a pre-requisite for the use of Anatomically-Constrained Tractography (ACT). The only way that these distortions can be corrected is if either:

    * Spin-echo images with different phase encoding directions / readout times are provided in the fmap/ directory;

    * The dwi/ directory itself contains more than one DWI series, and those series have different phase encoding directions / readout times.

I refer to this as phase encoding contrast. Images with different geometric distortions due to differences in phase encoding are necessary to enable estimation of the susceptibility field, and hence correction of those geometric distortions. Without the ability to correct those distortions, the script cannot proceed. In the future we may release a method that attempts to correct these distortions using the subject's T1-weighted image, but this is not yet available.

Rob

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MRtrix3/mrtrix3/issues/1303#issuecomment-383790965 , or mute the thread https://github.com/notifications/unsubscribe-auth/Akv2v9Pi95K1atq555mS3EgHCCGqvRNnks5trpofgaJpZM4Tb6Cu .

[Lestropie]

Given the mrconvert call correctly imports the JSON file, the issue is likely the contents of the JSON file itself. Both the PhaseEncodingDirection and TotalReadoutTime fields need to be present, and with the correct capitalisation, for MRtrix3 to identify those fields as containing phase encoding information and interpreting them as such; if those strings are not perfectly matched, then MRtrix3 will instead interpret those data as generic image header key-value pairs, and hence dwipreproc will not be able to find the phase encoding information it requires.

Copy & pasting the contents of the DWI JSON file here may provide an answer. I don't see anything in my logs on the development branch regarding fixing of any related issue... Unfortunately I haven't been able to put any time into this script as the focus has been the MRtrix3 3.0_RC3 update, but if there's a major flaw that's preventing execution I can get all of the data from you and try to replicate.

[elella1]

Dear Rob,

thank you very much, you are very kind in helping me. I think I have some problems with phase encoding information, my .json file doesn’t contain the PhaseEncodingDirection field. I copy it here:

{

   "Manufacturer": "GE",

   "ManufacturersModelName": "Signa_HDxt",

   "AcquisitionNumber": 1,

   "InstitutionName": "USC_Department_of_Radiology",

   "DeviceSerialNumber": "6S0r8hsTs5Lt7JmRDT06cyU",

   "SoftwareVersions": "24_LX_MR_Software_release:HD16.0_V02_1131.a",

   "ScanningSequence": "EP_SE",

   "SequenceVariant": "NONE",

   "SeriesDescription": "Axial_DTI",

   "ProtocolName": "Axial_DTI",

   "ImageType": ["ORIGINAL", "PRIMARY", "OTHER"],

   "AcquisitionTime": "14:08:33.000000",

   "MagneticFieldStrength": 3,

   "FlipAngle": 90,

   "EchoTime": 0.0684,

   "RepetitionTime": 13,

   "PhaseEncodingLines": 128,

   "ConversionSoftware": "dcm2niix",

“ConversionSoftwareVersion": "v1.0.20170724 GCC4.4.7”

}

To obtain it I have run the command:

dcm2bids -d ../dcm1 -p 003_S_0908 -c conf.json --forceDcm2niix

on my dcm directory containing both the structural mri dcms and the dwi dcms of one subject of my dataset.

You can find dcm1 directory at this link:

https://drive.google.com/open?id=1u8UguufY7duKhD9hdZKkrJheS6RmBGgi

and the output MY_BIDS_DIR at this link: https://drive.google.com/open?id=1I28HkhxX2CRiSkU4t9HMw29hOEat1nGn

the conf.json file I used is in the MY_BIDS_DIR.

(I also added manually a directory named fmap but of course it didn’t solve my problem with PE info).

The dwi folder contains more than one DWI series and I tried to run (out of the MRtrix3_connectome https://github.com/BIDS-Apps/MRtrix3_connectome pipeline) only the dwidenoise and dwi preprocessing passing the dwi dcms directory. I completed the dwiprocessing step without errors. So I think that the required information are present in the data but I need to understand how to pass this information to the MRtrix3_connectome https://github.com/BIDS-Apps/MRtrix3_connectome pipeline.

Thank you very much.

I'm looking forward to hearing from you.

Best regards.

Eufemia

Il 26 aprile 2018 alle 13.16 Robert Smith notifications@github.com ha scritto:

Given the mrconvert call correctly imports the JSON file, the issue is likely the contents of the JSON file itself. Both the PhaseEncodingDirection and TotalReadoutTime fields need to be present, and with the correct capitalisation, for MRtrix3 to identify those fields as containing phase encoding information and interpreting them as such; if those strings are not perfectly matched, then MRtrix3 will instead interpret those data as generic image header key-value pairs, and hence dwipreproc will not be able to find the phase encoding information it requires.

Copy & pasting the contents of the DWI JSON file here may provide an answer. I don't see anything in my logs on the development branch regarding fixing of any related issue... Unfortunately I haven't been able to put any time into this script as the focus has been the MRtrix3 3.0_RC3 update, but if there's a major flaw that's preventing execution I can get all of the data from you and try to replicate.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MRtrix3/mrtrix3/issues/1303#issuecomment-384603284 , or mute the thread https://github.com/notifications/unsubscribe-auth/Akv2v_fDeLjl9BKMtCTVdMDcYAEYLfBWks5tsax6gaJpZM4Tb6Cu .

[elella1]

Dear Rob,

I had some problems with my mail server, so I think some mails may have been lost. Maybe my last mail didn't reach you or maybe you answered me, but I did not receive any mail. I attach below my last mail again. Please, in the case you sent me a reply, could you send me your response again? You can find in cc my institutional mail address too.

Thank you!

Eufemia

[Lestropie]

Hi @elella1,

Fundamentally the issue traces all the way back to use of a GE scanner :-/ Neither GE nor Philips provide enough information within the DICOM headers for software to be able to determine the requisite phase encoding information from the data. As such, dcm2bids fails to write this information to the JSON file(s), and I'm unable to determine this information using MRtrix3 either (though if you happen to know where this information may be available within the data, please let me know).

One way to successfully process such data using a script like MRtrix3_connectome that requires such information is to manually insert that information into the BIDS data. You will need to determine the phase encoding direction, and ideally the data necessary to calculate the total readout time, and insert that information into the relevant JSON file(s), ensuring that the fields are named precisely as they are defined in the BIDS standard.

Alternatively, you could perform DWI pre-processing manually using the relevant underlying MRtrix3 commands, using the command-line interface of the dwipreproc script to manually specify the phase encoding information and acquisition design, store the resulting pre-processed data in BIDS format, and then run the MRtrix3_connectome script using the --preprocessed option, which skips the relevant DWI pre-processing section and therefore doesn't require the phase encoding information.

Though I should also note that the data you have provided here only contains a single DWI series. The fundamental requirement for the MRtrix3_connectome script is that b=0 volumes must be available with differences in phase encoding; this can come either from having multiple DWI series in the dwi/ directory, or from explicitly-acquired spin-echo EPI images stored in the fmap/ directory.

Rob

[elella1]

Hi Rob,

thank you very much for your answer! I think that the best solution for my case would be to run the DWI-preprocessing manually. I'have already tried to run preprocessing on my own data using the MRtrix3 command line interface and I had no problem. I have just two questions:

1. If I run the MRtrix3_connectome script using --preprocessing option, will it skip only the preprocessing step or also the dwidenoise and unring steps? In other words, I have to run manually only the dwi preprocessing step or the denoise and the unring steps too?

2. This is a question not related to preprocessing. In the MRtrix3_connectome script there is an inter-modal registration step. Is it needed to manually pre-register the dwi and anatomical images, e.g. to the MNI152 standard-space, or the inter-modal registration step would be sufficient for the probabilistic tractography and structural connectome construction?

Thank you again.

Eufemia

Il 5 maggio 2018 alle 11.51 Robert Smith notifications@github.com ha scritto:

Hi @elella1 https://github.com/elella1 ,

Fundamentally the issue traces all the way back to use of a GE scanner :-/ Neither GE nor Philips provide enough information within the DICOM headers for software to be able to determine the requisite phase encoding information from the data. As such, dcm2bids fails to write this information to the JSON file(s), and I'm unable to determine this information using MRtrix3 either (though if you happen to know where this information may be available within the data, please let me know).

One way to successfully process such data using a script like MRtrix3_connectome that requires such information is to manually insert that information into the BIDS data. You will need to determine the phase encoding direction, and ideally the data necessary to calculate the total readout time, and insert that information into the relevant JSON file(s), ensuring that the fields are named precisely as they are defined in the BIDS standard.

Alternatively, you could perform DWI pre-processing manually using the relevant underlying MRtrix3 commands, using the command-line interface of the dwipreproc script to manually specify the phase encoding information and acquisition design, store the resulting pre-processed data in BIDS format, and then run the MRtrix3_connectome script using the --preprocessed option, which skips the relevant DWI pre-processing section and therefore doesn't require the phase encoding information.

Though I should also note that the data you have provided here only contains a single DWI series. The fundamental requirement for the MRtrix3_connectome script is that b=0 volumes must be available with differences in phase encoding; this can come either from having multiple DWI series in the dwi/ directory, or from explicitly-acquired spin-echo EPI images stored in the fmap/ directory.

Rob

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MRtrix3/mrtrix3/issues/1303#issuecomment-386793849 , or mute the thread https://github.com/notifications/unsubscribe-auth/Akv2v7v6fTladmI2NgMmKGPynI0pnJfmks5tvXYxgaJpZM4Tb6Cu .

[Lestropie]

1. The --preprocessed option indicates that all DWI pre-processing has already been performed, and therefore no processes that fall under the banner of "pre-processing" will be applied. This definition extends beyond the scope of the "dwipreproc" script, for which the name is admittedly problematic for this reason, but we have been unable to settle on a superior alternative. You can see in the script itself which commands are skipped and which are executed when `--preprocessed`` is provided.

2. There is no need to pre-register image data. Even in `--preprocessed`` is supplied, the inter-modal, intra-subject registration step still takes place. If data are required from e.g. MNI152 space, then a registration step will be performed, and that data transformed from template space into subject space; it is recommended to avoid direct transformation of subject data into template space in order to perform tractography. Admittedly however the registration to MNI space is currently affine only; I'm working on methods that will allow me to improve this in the next version of the connectome script.

[elella1]

Dear Rob,

thank you for your help. Thanks to your suggestions I finally succeeded to obtain the connectome.csv for my data. The problem was in the dcm2bids output. In the end I performed DWI pre-processing manually using the MRtrix3 commands and I also converted the T1 from dcm to nifti using mricron and I manually added it in the BIDS dir.

I have just a doubt now. The matrix I obtained has no zero diagonal elements. I see that in the script the -zero_diagonal option is not set and so it is normal that I can obtain no zero diagonal elements and I think that I could put the diagonal elements of the output.csv to zero, cause I'm not interested in the self connections. But my doubt concerns the fact that the diagonal elements have great values. Is it normal?

I send to you in attachment an example of my output.csv.

Thank you.

Best regards,

Eufemia

Il 5 maggio 2018 alle 11.51 Robert Smith notifications@github.com ha scritto:

Hi @elella1 https://github.com/elella1 ,

Fundamentally the issue traces all the way back to use of a GE scanner :-/ Neither GE nor Philips provide enough information within the DICOM headers for software to be able to determine the requisite phase encoding information from the data. As such, dcm2bids fails to write this information to the JSON file(s), and I'm unable to determine this information using MRtrix3 either (though if you happen to know where this information may be available within the data, please let me know).

One way to successfully process such data using a script like MRtrix3_connectome that requires such information is to manually insert that information into the BIDS data. You will need to determine the phase encoding direction, and ideally the data necessary to calculate the total readout time, and insert that information into the relevant JSON file(s), ensuring that the fields are named precisely as they are defined in the BIDS standard.

Alternatively, you could perform DWI pre-processing manually using the relevant underlying MRtrix3 commands, using the command-line interface of the dwipreproc script to manually specify the phase encoding information and acquisition design, store the resulting pre-processed data in BIDS format, and then run the MRtrix3_connectome script using the --preprocessed option, which skips the relevant DWI pre-processing section and therefore doesn't require the phase encoding information.

Though I should also note that the data you have provided here only contains a single DWI series. The fundamental requirement for the MRtrix3_connectome script is that b=0 volumes must be available with differences in phase encoding; this can come either from having multiple DWI series in the dwi/ directory, or from explicitly-acquired spin-echo EPI images stored in the fmap/ directory.

Rob

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MRtrix3/mrtrix3/issues/1303#issuecomment-386793849 , or mute the thread https://github.com/notifications/unsubscribe-auth/Akv2v7v6fTladmI2NgMmKGPynI0pnJfmks5tvXYxgaJpZM4Tb6Cu .

[Lestropie]

The problem was in the dcm2bids output. In the end I performed DWI pre-processing manually using the MRtrix3 commands and I also converted the T1 from dcm to nifti using mricron and I manually added it in the BIDS dir.

• If this is something that is reproducible within dcm2bids, and is provably incorrect with respect to BIDS (and not just the reading of such data by my script), I'm sure its developer would appreciate the feedback.

• MRtrix3 itself is capable of converting from DICOM if one is going to manually arrange data into BIDS format. The mrconvert command has command-line options -json_export and -export_grad_fsl, which will generate the required JSON and bvecs/bvals files respectively.

But my doubt concerns the fact that the diagonal elements have great values. Is it normal?

Yes, entirely normal. Any streamline for which both endpoints are assigned to the same node will appear on the diagonal. With ACT, very short connections can be generated (the default minimum length criterion is twice the voxel size, much shorter than other dMRI packages), and such short pathways are in fact prevalent in the human brain; see this manuscript. So if the grey matter parcels are any larger than a couple of voxels in size, there will be plenty of self-connections reconstructed.