ENH: Generate the eddy QC report

[MichielCottaar]

This should add the single-subject QC report to the HCP pipelines. I am still testing this locally, but that requires rerunning eddy, so it will probably not be finished before the AHM.

[MichielCottaar]

One thing to think about is whether we want the QC report to be in its default location (${subject}/Diffusion/eddy/eddy_unwarped_images.qc/). It might be nice to move it to a location easier to find (e.g. ${subject}/QC/Diffusion/).

[glasserm]

I would move it to an easier to find location. Thanks for the pull request.

[mharms]

It's not technically in the "T1w" space, but I wonder if we shouldn't copy it to ${subject}/T1w/Diffusion/eddylogs since that is a directory that we are already exposing publicly.

[glasserm]

Is it images or a QC report? If it is images, why not resample them to T1w space and do that?

[MichielCottaar]

It is just a QC report (no NIFTI files). The report does contain pngs of the brain, which would of course not be showing the brain in T1-weighted space, but that should not be an issue. So I think the eddylogs is a good place to put the report.

Another issue is: there are some text files with the movement, average residual, etc. per volume. Due to the resampling of two volumes into one after eddy, these can no longer be used as confound regressors (that is true both in the original diffusion space and the T1-weighted space). I don't see an obvious fix for this (and of course having the report itself would still be useful anyway).

[mharms]

That said, while eddy_quad is more "report" (with png's) than images, perhaps we should be resampling the cnr maps generated by eddy (--cnr_maps flag) into the T1w space? I believe that @MichielCottaar raised as a possible addition previously?

[MichielCottaar]

Transforming some of the output maps from eddy to T1-weighted space (in particular the CNR maps) would be easy to do. I agree with Jesper that it is probably not very useful, but we might as well.

[mharms]

One other random thought: I don't suppose that eddy --json generates an output text file of the form that would be appropriate for the slspec format? If so, then obviously we could use that file as the slspec file for QUAD.

[MichielCottaar]

TBH, it would not be very hard to include a python script to do that conversion from json to slspec ourselves (I don't think eddy does so).

[MichielCottaar]

Ok, this version works. I've attached the produced QC report for reference.

qc.pdf

What I haven't implemented:

• passing in slspec (either from user or converted from json)
• converting CNR maps. There seemed to be a lot of steps to do this properly (first convert to undistorted diffusion space in eddy_postproc, keeping the unwarped version and then converting to Structural space in Diffusion2Structural.sh). It does not seem worth it to me to add so much code for a file that people probably won't use. There are already CNR summary measures in the report.

[mharms]

Perhaps I'm missing it, but where does the output of QUAD get copied/moved to T1w/Diffusion/eddylogs ?

[mharms]

Now that we've figured out the spline resampling/masking issues, isn't it just a matter of a couple lines in eddy_postproc.sh and DiffusionToStructural.sh to get the CNR maps into the T1w space? I actually think they would be quite a nice addition.

[glasserm]

I agree with Mike about the CNR maps.

[MichielCottaar]

Ok, this version appears to work both with and without gradient distortion correction

[mharms]

If we want to consolidate the code a bit, we could define warpedDir=${datadir}/warped and then use ${warpedDir} throughout the following.

[mharms]

Did you intentionally choose trilinear rather than spline interpolation here?

[MichielCottaar]

No, that should have been spline interpolation

[mharms]

Thanks for adding the CNR maps into the T1w space.

[mharms]

Looks good to me. Are you running one more quick test, just to make sure the latest changes didn't break anything?

[MichielCottaar]

Indeed, the test will probably not finish today, but I'll let you know if it works.

[MichielCottaar]

This version seems to work both with and without gradient-distortion correction

[glasserm]

I would merge this when the conflicts are resolved

[mharms]

What conflicts? The PR is reporting that it has no conflicts and merging can be performed automatically.

[glasserm]

This branch cannot be rebased due to conflicts
Rebasing the commits of this branch on top of the base branch cannot be performed automatically due to conflicts encountered while reapplying the individual commits from the head branch.

[coalsont]

It conflicts for the rebasing merge mode, which I asked him to use. If @MichielCottaar can rebase this branch onto master and manually resolve any conflicts, that should fix it. However, if he has been merging in the latest master at several points, then we may have to use the merge commit mode.

[glasserm]

I am letting Tim handle any PR that does not Rebase and merge automatically since he has asked me not to use the other modes.

[MichielCottaar]

Sorry, I did use merge onto master. If you prefer, I could just squash all of the history, which would allow a rebase to work. However, that would hide the history anyway, so I think it makes more sense to just use merge commit mode for this branch.