Spec does not cover multi-echo reverse phase encode case

[jbteves]

The current specification does not cover the case of using reverse phase encode EPIs to undistort multi-echo data per the Entity Table. This should be amended in the specification and validator.

[tsalo]

Could you expand on this a bit? Some example filenames could help me understand.

Are we talking about PEPOLAR field maps for multi-echo data or full AP/PA runs (like HCP has)?

[jbteves]

Sure; AP/PA runs specifically. So it would look like (extrapolating from the current spec):
sub-ID_ses-1_dir-rev_echo-1_epi
sub-ID_ses-1_dir-rev_sbref_echo-1_epi (in a multi-band case; for the single-band reference)
More complex: you could make several acquisitions so that there's also a run- label.

It's possible that I'm misreading the spec, but the above names are at a minimum not passing the validator.

[tsalo]

It looks like _dir-<label> is supported for functional data in the specification and the entity table. See this description under task fMRI data in the specification:

Similarly the OPTIONAL dir- and rec- key/values can be used to distinguish different phase-encoding directions and reconstruction algorithms (for example ones using motion correction). See fmap Case 4 for more information on dir field specification.

It sounds like you're describing full functional runs, in which case your files should look like the following. Also, you don't have SBRefs specified correctly:

• sub-ID/ses-1/func/sub-ID_ses-1_dir-rev_echo-1_bold.nii.gz
• sub-ID/ses-1/func/sub-ID_ses-1_dir-rev_echo-1_sbref.nii.gz

[jbteves]

Whoops, sorry about the sbref.
They're not full runs, they're exclusively to undistort. Therefore, they're philosophically more similar to a fieldmap than a functional run. It's only like 4 TRs of data, whereas a full functional run is >200.

[tsalo]

Oh, okay. I think that's a fairly rare case, so it's probably not explicitly covered in the specification.

It seems to me that this kind of scan is ambiguous- the data are not spin echo field maps like PEPOLAR, and so best fit under func/ with the _bold suffix instead of under fmap/ with the _epi suffix. However, the data are also not full functional runs. While the changes I proposed above should pass the validator (after adding _task-), I'm not sure that they're very compatible with existing workflows. Perhaps the solution is to use a special task label (e.g., _task-Distortion) and to include an IntendedFor field in the metadata.

The idea of adding an IntendedFor field to functional run metadata is discussed in #239. This issue may also be related to nipreps/fmriprep#1246 as well.

It might be worth it to rename the issue, since this isn't unique to multi-echo data.

[jbteves]

To clarify, you think the bigger issue is that blip-up/blip-down isn't covered as a fieldmap?

[tsalo]

I believe that blip-up/blip-down is covered under the specification here. I think that the issue is that your data are (1) GRE instead of SE and (2) combine a full functional scan and a field map scan when the specification supports two field map scans with opposite encoding directions, and neither of those are explicitly covered in the specification.

However, based on this NeuroStars post, acquiring a single EPI volume with the inverse encoding direction to the main functional scan is supported and the volume should be placed under fmap with the IntendedFor field pointing toward the full functional run.

If that all is right, then I think the specification just needs to be updated to say that GRE field maps and asymmetric field maps (i.e., one scan with inverse encoding against the main functional scan) are supported under "Case 4".

[jbteves]

That works for me, thank so much @tsalo !