`--correct-slice-timing` flag can have no effect (doc?)

[psadil]

Looking at the inputs and outputs for a run that included the --correct-slice-timing flag, and it seems like no correction is being applied (e.g., the voxel that had the largest change in temporal average before and after has a difference that is only ~1e-4). The command.txt for this node looks like

3dTshift -prefix <input>_bold_valid_tshift.nii.gz /work/workflow_enumerator/funcMRIQC/fMRI_HMC_afni/_in_file_<input>_bold.nii.gz/TimeShifts/<input>_bold_valid.nii.gz

Reading up on the help page for 3dTshift, and I gather that when -tpattern is not used (like it's absent in that call), then the program will try to apply correction based on information in the nifti's header. However, I'm working with a multiband sequence, and it's my impression that there isn't a way to describe that in the header.

The help page for 3dTshift clarifies that

If the input dataset does not have any slice timing information, and
  '-tpattern' is not given, then this program just copies the input to
  the output.

So, I'm wondering if that's the the situation -- that the image is mostly just being copied. Could that be? Thanks!

[oesteban]

This assessment is very reasonable. However, MRIQC should not really run slice-timing correction. Unless, we can figure out some summary index that talks about quality.

For instance, plotting some sort of difference map or slice profile of differences when subtracting the original EPI and the slicetime-corrected could be interesting. WDYT? (cc/ @celprov).

For now, I think slice-timing correction should be removed from MRIQC, and reinserted when it indeed helps compute something related to quality.

[psadil]

FWIW, I wouldn't mind if slice-timing correction were dropped for now. Speaking just about my habits, I find that the most helpful metrics and plots are the subset for which there is a norm or reference to compare against. That plot sounds interesting, but I guess that I haven't (yet) seen many examples of it or have clear expectations for how it would/could look across different kinds of acquisitions (e.g., different slice patterns).

[oesteban]

Yep, its usefulness would need to be assessed before inclusion. I was just thinking out loud :)

[psadil]

Removing the flag and deleting the slice-timing correction parts from the workflow seems relatively straightforward. Would a pull request help?

[oesteban]

Definitely!