Pre-processing in the absence of reversed phase encoding data

[Lestropie]

Utilising the Synb0-DisCo approach described in:

https://www.sciencedirect.com/science/article/pii/S0730725X18306179

, either using the existing histogram matching approach or by packaging the ML-based T1 -> b=0 image synthesis approach.

[ghost]

Dear Robert,
first of all, I would like to thank you for this wonderful app.

I am not really an expert in diffusion MRI, but I am trying to obtain structural connectomes on my dataset.

Unfortunately, I don't have fieldmap or reversed phase encoding acquisitions to obtain a state-of-the-art EPI distortion correction, and I was thinking of using the Synb0-DisCo as an alternative approach. I was wondering if there is a way to integrate this method (or other alternative approaches) while using MRtrix3_connectome.

Also, my idea is to exploit externally obtained brain parcellations in the T1w space for building the connectome, is there a way to do this in Mrtrix3_connectome?

[Lestropie]

Hi Giuseppe,

While I would very much like to integrate Synb0-DisCo into this tool, I'm being dragged in a million directions right now, and there's a lot of useful capabilities that simply fail to ever make their way to the top of my priority list. Indeed even within MRtrix3 itself, the capability to utilise the output of SynB0-DisCo has not yet made it into a public release (the code is written, but it's residing in the development branch that will eventually become version 3.1.0). So while you could theoretically proceed with your data, it would require getting your hands a little more dirty rather than using a tool intended to go from input data straight to result.

RE the use of unsupported brain parcellations: there's a couple of potential avenues here. One would be a feature request separate to this thread, wherein one can specify e.g. --parcellation external, and then there would be an additional command-line option that would allow the user to provide both the parcellation image and the template image on which it is based (as interpreting the former whilst making an assumption about the latter is not robust). The other would be to request (or even implement and propose as a Pull Request if it fits in neatly with the current code path) integration of the parcellation(s) of interest into this tool. I've opted for the latter thus far myself, particularly given that some of the parcellations currently supported require considerably different code paths, as opposed to simply being different parcellation images from which to access index data. If your alternatives are just parcellation images that require the usual register_to_template -> transform_parcellation_to_subject_space sequence, then the more generic first option is possible. Alternatively, it's nice to have the data bundled up in the package as per the second approach as it simplifies the command-line usage for the end user.

Cheers
Rob

[ghost]

Dear Robert,
thank you so much for your answer.

Regarding the external brain parcellations, my idea was to use a scheme that is not entirely "atlas-based" (i.e. using FSL FIRST to obtain deep gray matter nodes in the T1w space, along with a common atlas-based parcellation of the cortex) and would not fit with the classic "register_to_template -> transform_parcellation_to_subject_space" strategy.
Do you think that a feature request including this possibility would be appropriate?

Best,
Giuseppe

[Lestropie]

using FSL FIRST to obtain deep gray matter nodes in the T1w space, along with a common atlas-based parcellation of the cortex

Okay, that would require some modification of the code paths.

The MRtrix3 script labelsgmfix takes a brain parcellation, stripis out the sub-cortical nodes, runs FSL FIRST, and then inserts binary masks for those parcels back into the output image. However in this tool, this script is only utilised when the source of the cortical parcellation is FreeSurfer. It sounds like what you're looking for that script to be utilised in conjunction with a volumetric registration-based parcellation of the cortex. So the internal logic that determines whether or not the labelsgmfix script should or should not be invoked would need to be refined accordingly.

Are you wanting to use sub-cortical estimates from FIRST because you consider them to be more accurate than the corresponding parcels in your atlas following registration, or because such parcels are entirely absent from your atlas?

Either way it's an entirely reasonable feature request, and I don't think it would require a huge amount of effort. But I do think it'd be preferable to integrate those parcellations into the container. It would still be possible to use those parcellations if running outside of a container environment by using the -atlas_path option. But if using one of the containers, to me it makes more sense to embed those data within the container rather than requiring the user to specify the relevant paths to external data. Ultimately it would be preferable to instead be utilising a third-party database of parcellations; if I were to invest more effort in this tool I would probably do that, but given time constraints I'm happy to "patch in" requested parcellations for now.

Rob

[treanus]

Hi Robert,

I forked and tried to implement some solution.
I depends on the dev branch of mrtrix3 using your 'topup_files' option.
See https://github.com/treanus/MRtrix3_connectome#changes-relative-to-the-original-this-is-a-fork

Best, Stefan

[Lestropie]

Cheers @treanus.
Do you want to establish a draft PR so that we can easily see the diff?

A difficulty here from a theoretical perspective is ensuring that the two tools operate together correctly. Data coming from topup into eddy is only utilised correctly if the first volume in the image input to topup is the same as the first volume in the image input to eddy. If those first volumes are not identical, then the inhomogeneity field may be applied with an erroneous rigid-body offset from the data being processed.

https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046

There may be some risk of such occurring here especially if the DWI data do not have a b=0 volume as the first volume. dwifslpreproc internally permutes the first b=0 to be the first volume prior to running eddy (https://github.com/MRtrix3/mrtrix3/blob/3.0.3/bin/dwifslpreproc#L711-L727). If the user were to run Synb0-DISCO using a different b=0 volume as the first input volume, the topup-eddy common-first-volume assumption would be broken. Ideally there'd be a flag in eddy that would perform a rigid-body registration of the corrected DWIs to the corrected SE-EPIs that were utilised in topup and then re-compose the transformations, but in the absence of such this remains a potential trap. Obviously to facilitate your own processing you can deal with such guarantees yourself, but having dealt with distribution of software to a wider community these are the sort of edge cases I have to occupy my mind with :-/

[treanus]

Hi @Lestropie,

I created the pull request.

As for my own script running synb0, I try to get the first b0 from the dataset. In bash:

		# extract the B0
		# find dMRI
		if [ $number_of_bids_dmri_found -gt 1 ]; then
			kul_e2cl "   more than 1 dMRI b0 dataset, using first only for Synb0-disco" ${preproc}/${log}
		fi
		#echo $bids_dmri_found
		Synb0_dmri=${bids_dmri_found[0]}
		echo "The used dMRI for synb0-disco is $Synb0_dmri"
		dwi_base=${Synb0_dmri%%.*}

		mrconvert ${dwi_base}.nii.gz -fslgrad ${dwi_base}.bvec ${dwi_base}.bval \
			-json_import ${dwi_base}.json $synb0_scratch/dwi_p1.mif -strides 1:3 -force -clear_property comments -nthreads $ncpu
		dwiextract -quiet -bzero $synb0_scratch/dwi_p1.mif $synb0_scratch/dwi_p1_b0s.mif -force
		mrconvert $synb0_scratch/dwi_p1_b0s.mif -coord 3 0 $synb0_scratch/INPUTS/b0.nii.gz -strides -1,+2,+3,+4 -export_pe_table $synb0_scratch/topup_datain.txt

Is this ok?

Thx in advance,
Stefan