SDC-pepolar not executed only for some runs

[oesteban]

DS000223 / sub-01 / run-03, run-04 don't have SDC-pepolar, while run-01 and run-02 do.

[effigies]

Most likely not in the "IntendedFor" field.

…

-------- Original message -------- From: Oscar Esteban <notifications@github.com> Date: 10/17/17 18:03 (GMT-05:00) To: poldracklab/fmriprep <fmriprep@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [poldracklab/fmriprep] SDC-pepolar not executed only for some runs (#774) DS000223 / sub-01 / run-03, run-04 don't have SDC-pepolar, while run-01 and run-02 do. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#774>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAFF8q3t4CcgwFtC1yhPBiuV5OTCQesQks5stSQfgaJpZM4P84u6>.

[effigies]

Actually, it just looks like there's only fieldmaps for runs 1 and 2 for subjects 1-6. There are no fieldmaps at all for subjects 7-19.

[oesteban]

@chrisfilo what do you think we should do here? My feeling is that not running SDC unless the file has been pointed by an IntendedFor key would implicitly make IntendedFor mandatory. What is the current stand of BIDS on this?

[effigies]

Just to be clear, here:

$ tree /data/bids/ds000223/sub-01 
/data/bids/ds000223/sub-01
├── anat
│   └── sub-01_T1w.nii.gz
├── fmap
│   ├── sub-01_dir-opposing_run-01_epi.json
│   ├── sub-01_dir-opposing_run-01_epi.nii.gz
│   ├── sub-01_dir-opposing_run-02_epi.json
│   └── sub-01_dir-opposing_run-02_epi.nii.gz
└── func
    ├── sub-01_task-mag_run-01_bold.json
    ├── sub-01_task-mag_run-01_bold.nii.gz
    ├── sub-01_task-mag_run-01_events.tsv
    ├── sub-01_task-mag_run-02_bold.json
    ├── sub-01_task-mag_run-02_bold.nii.gz
    ├── sub-01_task-mag_run-02_events.tsv
    ├── sub-01_task-mag_run-03_bold.json
    ├── sub-01_task-mag_run-03_bold.nii.gz
    ├── sub-01_task-mag_run-03_events.tsv
    ├── sub-01_task-mag_run-04_bold.json
    ├── sub-01_task-mag_run-04_bold.nii.gz
    └── sub-01_task-mag_run-04_events.tsv

My interpretation is that the opposing runs are specifically acquired for runs 01 and 02, and that they are not valid for 03 and 04. Is that wrong? (The IntendedFor fields are certainly written as if this is the case, but I don't have any outside context for this dataset.)

[oesteban]

I doubt that was the original intent when the protocol was designed. The "opposing" EPIs are certainly designed to be used with the IntendedFor BOLDs in estimation. But I'm pretty convinced that the idea was to apply the correction on all BOLD scans.

…

On Oct 20, 2017 12:14 PM, "Chris Markiewicz" ***@***.***> wrote: Just to be clear, here: $ tree /data/bids/ds000223/sub-01 /data/bids/ds000223/sub-01 ├── anat │ └── sub-01_T1w.nii.gz ├── fmap │ ├── sub-01_dir-opposing_run-01_epi.json │ ├── sub-01_dir-opposing_run-01_epi.nii.gz │ ├── sub-01_dir-opposing_run-02_epi.json │ └── sub-01_dir-opposing_run-02_epi.nii.gz └── func ├── sub-01_task-mag_run-01_bold.json ├── sub-01_task-mag_run-01_bold.nii.gz ├── sub-01_task-mag_run-01_events.tsv ├── sub-01_task-mag_run-02_bold.json ├── sub-01_task-mag_run-02_bold.nii.gz ├── sub-01_task-mag_run-02_events.tsv ├── sub-01_task-mag_run-03_bold.json ├── sub-01_task-mag_run-03_bold.nii.gz ├── sub-01_task-mag_run-03_events.tsv ├── sub-01_task-mag_run-04_bold.json ├── sub-01_task-mag_run-04_bold.nii.gz └── sub-01_task-mag_run-04_events.tsv My interpretation is that the opposing runs are specifically acquired for runs 01 and 02, and that they are not valid for 03 and 04. Is that wrong? (The IntendedFor fields are certainly written as if this is the case, but I don't have any outside context for this dataset.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#774 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkhxuIW3a_EnokjmfE11-IaRKQ2g1-wks5suPEWgaJpZM4P84u6> .

[effigies]

So this should be solved by #747, then?

[oesteban]

Yes - mostly. The idea being: fmriprep tries to make the best estimation of the field map possible given a certain set of means (pepolar, fieldmap, syn, etc) and then corrects all BOLD scans with that.

As for BIDS, I think we are reaching to a point where we can rethink the "IntendedFor". With all this experience we gathered, I think we can propose to make the field mandatory. And the meaning would be something like: this EPI is the opposing direction of this other EPI (can be a BOLD, another EPI, a low-b diffusion or an SBref), and those two (or more) are the inputs for TOPUP (or whatever pepolar method you want to use).

[chrisgorgo]

IntendedFor field is share across all types of fieldmap data and does not indicate how the fieldmaps should be estimated. It only tells which file a particular fieldmap should be applied to.

This sounds like a problem with the dataset itself - "IntendedFor" should be listed for all runs (unless they should not be applied to all runs). Please raise this issue via appropriate channels with OpenfMRI curation team.

As for what to do with fieldmap data that do not have "IntendedFor" fields - that is up to each package. One approach could be to (suggested by @poldrack a while ago) to create a robust average for all available fieldmaps (for each subject independently) and apply it to all BOLD runs (ignoring "IntendedFor" field even if it is present). The advantage of this approach is that due to averaging the fieldmap will be more robust.

[oesteban]

Thanks, I forgot that IntendedFor applies to all fieldmaps.

Anyways, this seems to be a BIDS-specification issue more than a FMRIPREP issue. Especially with #747 there. I'll bring the discussion to the appropriate venue.

Feel free to reopen if needed.