Image quality metrics of multi-echo datasets -- where to go?

[oesteban]

MRIQC had long marginalized multi-echo datasets. Originally, it would treat them as different BOLD runs, and that's it.

This presented us with challenges and inconsistencies. One very obvious is that between-volume head motion should be the same through every echo at each timestep. However, our original approach would calculate head motion per echo and it obviously would not match across echos. More worryingly, performing image registration with long echos with low SNR and great dropout from distortions is very unreliable.

That made us change the view and now MRIQC treats all echos in a multiecho dataset as part of a single run. There are many wrinkles to iron out here and there (e.g., #1334), but the most challenging issue is to generate a single set of IQMs that make the most sense for ME.

@garciaml participated in the NiPreps Hack and worked on this topic. She has developed a notebook (https://github.com/garciaml/mriqc_fMRI_multi-echos_iqms) showing what metrics can be more predictive of specific artifacts and how they relate.

With her hands-on experience and the me-experts (looking at @emdupre, @eilidhmacnicol, @CesarCaballeroGaudes, and laterally, @tsalo), I'd like to address the question: what quality metrics should we define within MRIQC?

So far, we have reached the conclusion that FD (framewise displacement) should be a single value per timepoint across echos, and we are running image registration on the shortest echo (which has the largest SNR and t1 contrast), on top of which the FD is calculated.

An appealing solution could be to calculate the combined echoes and then run standard se-bold metrics. However, I'm weary that this is too much processing for MRIQC, which should be as attached as possible to the original unprocessed data.

We could start moving by averaging across echos all the different metrics (except FD), but I'm not sure this is going to be consistent across me options (e.g., 3 echos vs. 6 echos).

Thoughts?

/cc @celprov

[oesteban]

BTW, there's an issue open for this #1184, generalizing from #1183.