Qsiprep - Distortion correction not applied to eddy_corrected image?

[jhau]

Summary of what happened:

Hello!

I am running qsiprep preprocessing on dwi data acquired with reversed phase-encoding directions (AP and PA), each with 93 diffusion directions. It completes successfully. My topup results look good (are corrected for susceptibility distortions), but my eddy results don’t appear to be corrected for these distortions, and likely neither the eddy current distortions. See screenshots below.

I have tried running qsiprep both with and without the --distortion-group-merge flag (set to average) and get similar results. What am I missing?

Command used (and if a helper script was used, a link to the helper script or the command generated):

docker run -ti --rm --gpus all \
	-v /usr/local/freesurfer/7.4.1/license.txt:/opt/freesurfer/license.txt:ro \
	-v $bids_dir:/data:ro \
	-v $eddy_config_file:/sngl/eddy/eddy_config.json:ro \
	-v $out_dir:/out \
	-v $out_dir:/scratch \
	pennbbl/qsiprep:0.20.0 /data /out participant \
	--eddy-config /sngl/eddy/eddy_config.json \
	--output-resolution $res --pepolar-method TOPUP \
	--distortion-group-merge average \
	--bids-database-dir $bids_dir \
	-w /scratch 

Version:

qsiprep 0.20.0

Environment (Docker, Singularity / Apptainer, custom installation):

Docker

Data formatted according to a validatable standard? Please provide the output of the validator:

PASTE VALIDATOR OUTPUT HERE

Relevant log outputs (up to 20 lines):

PASTE LOG OUTPUT HERE

Screenshots / relevant information:

eddy_corrected image from the qsiprep_wf/single_subject_0001_wf/dwi_preproc_wf/hmc_sdc_wf/eddy directory:

topup_imain_corrected image from the qsiprep_wf/single_subject_0001_wf/dwi_preproc_wf/hmc_sdc_wf/topup directory:

---

[Steven]

Hi @jhau,

It would probably be better to look at the quality of the final preprocessed images, including screenshots in the html.

Best,
Steven

[jhau]

Hi @Steven,

From the html, here is a screenshot of the topup results:

and a screenshot of the b0 ref image before correction, which already looks odd - the after image is identical just cropped to the blue outline:

Thanks for your help.

Best,
Jan

[mattcieslak]

It looks to me like there might be a problem with the PhaseEncodingDirection in the sidecars. Are there separate AP/PA images in your fmap directory? It’s possible that topup is working, but the flipped PE Direction for the dwi images is causing the wrong correction to be applied during eddy.

[jhau]

Hi @mattcieslak,
I have my dir-AP and dir-PA images, labelled correspondingly, in the dwi directory. No fmap directory as I don’t think that’s needed in this case, correct? The json files show the PhaseEncodingDirection field to be j- for the AP and j for the PA images, which I believe are correct.

As an additional check, I tried swapping the AP and PA labels (i.e., I renamed the AP nii/bval/bvec/json files to PA and PA nii/bval/bvec/json files to AP) and reran qsiprep. I get the same results as before - the topup results look good, but the b0 ref is not uncorrected for distortions. Based on this, I don’t think the results are due to my PE Directions being flipped. Any other ideas?

[jhau]

Following up on this. Has anyone encountered this type of issue with eddy before?

My topup results look great but my eddy_corrected image looks bad (oddly stretched and shows some ghosting which isn’t present in the raw data and actually looks worse than the raw data).

I can’t figure out what is amiss in my eddy step. I’ve checked the eddy_acqp.txt and eddy_index.txt and those correspond with my input image (merge__merged) and the brain mask looks fine. I also ran eddy swapping the PE of the rows in my eddy_acqp.txt but it gives even worse results. I know it’s doing some sort of susceptibility distortion correction but why am I not getting results in my dwi image that look like the topup corrected b0? Maybe something is off in the estimation of the eddy current distortions?

[mattcieslak]

Hi @jhau, could you please try with the most recent version (0.21.4)? We fixed two topup-related bugs that could sometimes result in something like this.

[jhau]

@mattcieslak, I did run it with the latest version QSIPrep 0.21.5.dev0+g36b93fe.d20240507 and still get the same results unfortunately.

[mattcieslak]

Are you using a new working directory each time?

[jhau]

Yes, I’m using a new output and working directory each time.

I ran eddy using the --topup flag specifying the field coefficient and movement parameters and that produced good results (matches topup_imain_corrected). The issue I am having must be with the --field and --field_mat input. FSL notes some caveats when using --field and recommends using --topup. I’ve triple-checked my inputs to eddy (acqp/index settings and concatenated dwi file) and they appear to be correct so I don’t know what is causing the --field and --field_mat to give wonky results. Would it be possible to use the --topup flag instead of --field when running topup to avoid this situation?

Command:
eddy_cuda10.2 --ol_nstd=4 --ol_type=both --cnr_maps --estimate_move_by_susceptibility --imain=qsiprep_wf/single_subject_0426_wf/dwi_preproc_wf/pre_hmc_wf/rpe_concat/merge__merged.nii.gz --index=qsiprep_wf/single_subject_0426_wf/dwi_preproc_wf/hmc_sdc_wf/gather_inputs/eddy_index.txt --mask=qsiprep_wf/single_subject_0426_wf/dwi_preproc_wf/hmc_sdc_wf/transform_mask_to_eddy/topup_imain_corrected_avg_trans_mask_trans_flirt.nii.gz --acqp=qsiprep_wf/single_subject_0426_wf/dwi_preproc_wf/hmc_sdc_wf/gather_inputs/eddy_acqp.txt --bvals=qsiprep_wf/single_subject_0426_wf/dwi_preproc_wf/pre_hmc_wf/rpe_concat/merge__merged.bval --bvecs=qsiprep_wf/single_subject_0426_wf/dwi_preproc_wf/pre_hmc_wf/rpe_concat/merge__merged.bvec --out=qsiprep_wf/single_subject_0426_wf/dwi_preproc_wf/hmc_sdc_wf/eddy/eddy_corrected_topup_base --repol --residuals --json=qsiprep_wf/single_subject_0426_wf/dwi_preproc_wf/pre_hmc_wf/merge_plus/merge_dwis/merged_metadata.json --topup=qsiprep_wf/single_subject_0426_wf/dwi_preproc_wf/hmc_sdc_wf/topup/topup_imain_base