-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] Allow images in dwi and func to have an IntendedFor field in their json sidecar #239
Comments
Ah, I hadn't understood that you were proposing an
I think this is correct. If it will take modification to get them into a state where they can be used as fieldmaps, then it's misleading; if they're ready-to-use, then they're just fieldmaps. I think we need to consider the modified version derivatives (e.g., In fMRIPrep, this is already something we need to do with regard to lesion masks and custom brain masks. |
How would the |
@mattcieslak @effigies are we expecting this to affect also how we save data related to the DWI modality? |
@mattcieslak To make it concrete, suppose we start with:
Neither of them should be directly used as a fieldmap, so we need to do some preprocessing on each to make it suitable for the other.
Following the BIDS derivatives dictum if any filename in a derivative dataset has a name permissible for a raw BIDS data, then that file must be an identical copy of that raw file I've added a
{
"IntendedFor": ["sub-01/dwi/sub-01_acq-PA_dwi.nii.gz"]
}
{
"IntendedFor": ["sub-01/dwi/sub-01_acq-AP_dwi.nii.gz"]
} I do see one difference with the current language: The example Does that make sense, or even address your question? @francopestilli I'm trying to work within the existing specs as much as possible. If there ends up being a specific proposal to modify the spec, it should still be backwards compatible, so it shouldn't affect existing, valid datasets. |
I'm thinking about the common case where the sampling scheme is split up across multiple runs with different phase encoding directions. I've seen protocols with something like
where it's not immediately clear which series should be paired together for correction. If there's not a best-practices heuristic it would be nice to let the person curating the data specify their intended pairing in the sidecars. |
@satra this conversation is highly related to some of the points you raised in nipreps/fmriprep#1246 |
@mattcieslak Is it the case that these can be used directly, or they need to be preprocessed before they can be used? If the former, then I think there's a strong case for allowing
{
"IntendedFor": ["sub-01/dwi/sub-01_acq-PA_run-02_dwi.nii.gz"]
}
{
"IntendedFor": ["sub-01/dwi/sub-01_acq-AP_run-01_dwi.nii.gz"]
} And so on. I think you may also be able to do something like the following:
This would make it clearer that these pairs are associated, although that would simply be the curator's convention. The spec does not indicate that these should be interpreted as each others' fieldmaps. |
@effigies - almost no system generates ready to use fieldmaps. most of them requires some processing to generate a fieldmap that is then used for distortion correction. (and there are typically upto 4 types of distortion that need to be corrected for: gradient nonlinearity, B0, B1, eddy). as noted earlier, in some cases some acquisitions of dwi are only collected for distortion correction (we have done this ourselves with 4B0 images), for some scans it's implicit like non-similar phase encoding for diffusion scans, and sometimes you may be able to use other scans to correct a given scan. therefore there is a difference between intent (of the protocol) and possibilities for an automated routine like fmri/dmri/qsiprep (e.g., i could undistort epi bold images using information from diffusion images, if some acquisition settings were aligned - in this case it may not have been intended, but an analysis of the bids data may allow such a thing). i think bids could encode intent and automation. whether it should is a community decision. there is perhaps a broader conversation around |
Although potentially confusing, I actually like the idea of allowing an optional |
Hi @edickie, as per our dmriprep meeting, I've assigned you to this issue with the hopes we resurrect this and take it to the finish line. |
This PR addresses the problem @mattcieslak spotted at in bids-standard#239. This enhancement (WIP) basically allows for researchers to encode the protocol's intent regarding fieldmaps. As @satra introduced in bids-standard#239 (comment), BIDS "*could encode intent and automation. Whether it should is a community decision." This PR proposes a solution to encoding the intent. It doesn't modify anything to allow also encoding automation. The PR attempts to be backwards compatible. I'm submitting this draft PR to open discussions and looking forward to feedback. Resolves: bids-standard#239. References: #263, nipreps/dmriprep#43, bids-standard/bids-2-devel#39
This PR addresses the problem @mattcieslak spotted at in bids-standard#239. This enhancement (WIP) basically allows for researchers to encode the protocol's intent regarding fieldmaps. As @satra introduced in bids-standard#239 (comment), BIDS "*could encode intent and automation. Whether it should is a community decision." This PR proposes a solution to encoding the intent. It doesn't modify anything to allow also encoding automation. The PR attempts to be backwards compatible. I'm submitting this draft PR to open discussions and looking forward to feedback. Resolves: bids-standard#239. References: #263, nipreps/dmriprep#43, bids-standard/bids-2-devel#39
This PR addresses the problem @mattcieslak spotted at in bids-standard#239. This enhancement (WIP) basically allows for researchers to encode the protocol's intent regarding fieldmaps. As @satra introduced in bids-standard#239 (comment), BIDS "*could encode intent and automation. Whether it should is a community decision." This PR proposes a solution to encoding the intent. It doesn't modify anything to allow also encoding automation. The PR attempts to be backwards compatible, and is based off of bids-standard#651, where the text about fieldmaps is being revised. I'm submitting this draft PR to open discussions and looking forward to feedback. Resolves: bids-standard#239. Depends: bids-standard#651. References: #263, nipreps/dmriprep#43, bids-standard/bids-2-devel#39
This PR addresses the problem @mattcieslak spotted at in bids-standard#239. This enhancement (WIP) basically allows for researchers to encode the protocol's intent regarding fieldmaps. As @satra introduced in bids-standard#239 (comment), BIDS "*could encode intent and automation. Whether it should is a community decision." This PR proposes a solution to encoding the intent. It doesn't modify anything to allow also encoding automation. The PR attempts to be backwards compatible, and is based off of bids-standard#651, where the text about fieldmaps is being revised. I'm submitting this draft PR to open discussions and looking forward to feedback. Resolves: bids-standard#239. Depends: bids-standard#651. References: #263, nipreps/dmriprep#43, bids-standard/bids-2-devel#39
This PR addresses the problem @mattcieslak spotted at in bids-standard#239. This enhancement (WIP) basically allows for researchers to encode the protocol's intent regarding fieldmaps. As @satra introduced in bids-standard#239 (comment), BIDS "*could encode intent and automation. Whether it should is a community decision." This PR proposes a solution to encoding the intent. It doesn't modify anything to allow also encoding automation. The PR attempts to be backwards compatible, and is based off of bids-standard#651, where the text about fieldmaps is being revised. I'm submitting this draft PR to open discussions and looking forward to feedback. Resolves: bids-standard#239. Depends: bids-standard#651. References: #263, nipreps/dmriprep#43, bids-standard/bids-2-devel#39
This PR addresses the problem @mattcieslak spotted at in bids-standard#239. This enhancement (WIP) basically allows for researchers to encode the protocol's intent regarding fieldmaps. As @satra introduced in bids-standard#239 (comment), BIDS "*could encode intent and automation. Whether it should is a community decision." This PR proposes a solution to encoding the intent. It doesn't modify anything to allow also encoding automation. The PR attempts to be backwards compatible, and is based off of bids-standard#651, where the text about fieldmaps is being revised. I'm submitting this draft PR to open discussions and looking forward to feedback. Resolves: bids-standard#239. Depends: bids-standard#651. References: #263, nipreps/dmriprep#43, bids-standard/bids-2-devel#39
This PR addresses the problem @mattcieslak spotted at in bids-standard#239. This enhancement (WIP) basically allows for researchers to encode the protocol's intent regarding fieldmaps. As @satra introduced in bids-standard#239 (comment), BIDS "*could encode intent and automation. Whether it should is a community decision." This PR proposes a solution to encoding the intent. It doesn't modify anything to allow also encoding automation. The PR attempts to be backwards compatible, and is based off of bids-standard#651, where the text about fieldmaps is being revised. I'm submitting this draft PR to open discussions and looking forward to feedback. Resolves: bids-standard#239. Depends: bids-standard#651. References: #263, nipreps/dmriprep#43, bids-standard/bids-2-devel#39
This PR addresses the problem @mattcieslak spotted at in bids-standard#239. This enhancement (WIP) basically allows for researchers to encode the protocol's intent regarding fieldmaps. As @satra introduced in bids-standard#239 (comment), BIDS "*could encode intent and automation. Whether it should is a community decision." This PR proposes a solution to encoding the intent. It doesn't modify anything to allow also encoding automation. The PR attempts to be backwards compatible, and is based off of bids-standard#651, where the text about fieldmaps is being revised. I'm submitting this draft PR to open discussions and looking forward to feedback. Resolves: bids-standard#239. Depends: bids-standard#651. References: #263, nipreps/dmriprep#43, bids-standard/bids-2-devel#39
This PR addresses the problem @mattcieslak spotted at in bids-standard#239. This enhancement (WIP) basically allows for researchers to encode the protocol's intent regarding fieldmaps. As @satra introduced in bids-standard#239 (comment), BIDS "*could encode intent and automation. Whether it should is a community decision." This PR proposes a solution to encoding the intent. It doesn't modify anything to allow also encoding automation. The PR attempts to be backwards compatible, and is based off of bids-standard#651, where the text about fieldmaps is being revised. I'm submitting this draft PR to open discussions and looking forward to feedback. Resolves: bids-standard#239. Depends: bids-standard#651. References: #263, nipreps/dmriprep#43, bids-standard/bids-2-devel#39
Currently EPI fieldmaps are stored in the
fmap
directory. The user specifies which scans infunc
ordwi
the fieldmaps are supposed to correct via theIntendedFor
field in the corresponding json sidecars.Sometimes a whole DWI series is acquired with the reverse phase encoding direction of another DWI series and the low b images in each series are meant to correct the opposite PE direction series.
For this use case, would it be best to
IntendedFor
specified in its sidecar orIntendedFor
field to the sidecars of the images indwi
andfunc
?Option 1 would go against keeping the images as raw as possible and would make automatic BIDS conversion very tricky. Option 2 might be confusing because images in
dwi
andfunc
are not really "intended for" distortion correction.I'd be very interested to hear opinions on this and happy to do a PR
The text was updated successfully, but these errors were encountered: