Relates to #39 here, bids-standard/bids-specification#622 in BIDS 1.0, maybe others also. Had hoped to discuss at OHBM22 but didn't get the chance.
I really dislike having information regarding how an inhomogeneity field should be estimated ("B0FieldSource") and the images to which that estimate should be applied ("IntendedFor") encoded alongside image data sidecar information. The contents of those sidecars provide information about the image data themselves, how they were acquired, acquisition parameters, etc., whereas these fields relate specifically to how those data should be processed. We are currently bastardising the sidecar information that is specific to one image data file with content that relates to other image data files and the desired utilisation of such.
I would vastly prefer a solution where information relating to how a dataset should be processed is independent of the raw data themselves. The image sidecar JSONs that come out of eg. dcm2niix should remain untouched. Instead there should be a separate JSON file that is specifically intended to provide information about the intended utilisation of specific images.
In the specific context of B0 inhomogeneity field map estimates, one may theoretically have any number of field map estimates, which may come from different sources. Eg. If acquiring reversed phase encoding spin-echoes, and a subject moves a lot during the session, you may want to derive multiple field maps throughout the session, and for each fMRI run use only the most temporally proximal estimate. So that might look like (focusing more on concept than field names):
$ cat processing.json
{
"B0FieldMaps": [
"early": {
"Sources": [
"fmap/sub-###_dir-ap_run-1_epi.nii.gz",
"fmap/sub-###_dir-pa_run-1_epi.nii.gz"
],
"Sinks": [
"func/sub-###_task-nback_bold.nii.gz"
"func/sub-###_task-olr_bold.nii.gz"
]
},
"late": {
"Sources": [
"fmap/sub-###_dir-ap_run-2_epi.nii.gz",
"fmap/sub-###_dir-ap_run-3_epi.nii.gz",
"fmap/sub-###_dir-pa_run-2_epi.nii.gz"
"fmap/sub-###_dir-pa_run-3_epi.nii.gz"
],
"Sinks": [
"func/sub-###_task-rest_bold.nii.gz"
]
}
]
}
Theoretically, this concept of defining a text file that prescribes the intended image processing and inter-dependencies between data may not necessarily be constrained to just B0 inhomogeneity field mapping; hence the "B0FieldMaps" list at the root level. Curious to know if anyone with a wider breadth of experience can come up with more examples of such.
TL;DR: Separate processing instructions from raw data.
Relates to #39 here, bids-standard/bids-specification#622 in BIDS 1.0, maybe others also. Had hoped to discuss at OHBM22 but didn't get the chance.
I really dislike having information regarding how an inhomogeneity field should be estimated ("
B0FieldSource") and the images to which that estimate should be applied ("IntendedFor") encoded alongside image data sidecar information. The contents of those sidecars provide information about the image data themselves, how they were acquired, acquisition parameters, etc., whereas these fields relate specifically to how those data should be processed. We are currently bastardising the sidecar information that is specific to one image data file with content that relates to other image data files and the desired utilisation of such.I would vastly prefer a solution where information relating to how a dataset should be processed is independent of the raw data themselves. The image sidecar JSONs that come out of eg.
dcm2niixshould remain untouched. Instead there should be a separate JSON file that is specifically intended to provide information about the intended utilisation of specific images.In the specific context of B0 inhomogeneity field map estimates, one may theoretically have any number of field map estimates, which may come from different sources. Eg. If acquiring reversed phase encoding spin-echoes, and a subject moves a lot during the session, you may want to derive multiple field maps throughout the session, and for each fMRI run use only the most temporally proximal estimate. So that might look like (focusing more on concept than field names):
Theoretically, this concept of defining a text file that prescribes the intended image processing and inter-dependencies between data may not necessarily be constrained to just B0 inhomogeneity field mapping; hence the
"B0FieldMaps"list at the root level. Curious to know if anyone with a wider breadth of experience can come up with more examples of such.TL;DR: Separate processing instructions from raw data.