Hi, I have couple of related issues I was hoping to get some community insight on, so any comments/suggestions are welcome!
We have a few participants who needed to get out of the scanner during the middle of scan and we didn’t get a second fmap for them when they got back in the scanner. I’m assuming we shouldn’t really use the first fmap we collected since the B0 field would be different. In these cases, we could try to use the synthetic fmap, but that doesn’t seem to be producing reasonable output with the latest version of FMRIprep (More distorted images are produced through SyN distortion correction). In addition, I am not totally sure how to only apply the synthetic fmaps for specific runs and tasks in a given subject.
Alternatively, it seems like an ideal solution for our problem – and likely a nice advance for the field – would be to use framewise fmaps derived from multi-echo phase images, an approach described in Andrew Van’s preprint (Framewise multi-echo distortion correction for superior functional MRI - PMC). Although we can get very reasonably-looking fmaps from this approach since we have part-mag and part-phase bold for each echo, it’s unclear how to integrate this approach into FMRIprep. We tried a simplified case where we just use the first fmap, but that throws an error with the BIDS validator (echotime1_2_difference_unreasonable) since the echo time difference is about 17 ms (and I think the limit in BIDS is currently set to 10 ms).
Any ideas of how to move forward? I realize that Andrew’s work may not be integrated into FMRIprep anytime soon, but it would at least be nice to see FMRIprep use the first derived fmap from our bold data. That would solve a lot of problems for us, even in the cases where the participants don’t get our of the scanner since they invariably move their head from the time of acquiring the fmap and collecting the last bold scan.
Thanks!
David
Tagging @effigies and @oesteban just to ensure they see it. I’m not sure if Andrew is on NeuroStars…
Thanks, Taylor! Happy to try and help and test if possible. The framewise SDC would be a great integration with FMRIprep, but it seems like the BIDS definitions for a reasonable Echo 1 and Echo 2 difference will have to be amended either way since most multi-echo sequences have more than 10 ms between echoes?
For the purposes of getting something up and running in FMRIprep sooner rather than later, is there a way to suppress this error/warning? Within the context of medic, is it even fair to call it Echo 1 vs. Echo 2 if it’s using all four echoes? We got so far as to creating an fmap for each task and run corresponding to the first volume of the acquisition, but then we get the error in the BIDS validator (echotime1_2_difference_unreasonable).
I’m going to repost messages from the GitHub issue because this is the better location for them:
FWIW I don’t think SDCFlows will work if you just take the first two echoes from one of your volumes and rename them as field map files (which is when the BIDS validator would notice your echo time difference, I believe). The phase data are probably highly wrapped, which I believe is what ROMEO is particularly good at handling, but ROMEO isn’t what SDCFlows uses for unwrapping. I could definitely be wrong though.
Then you said:
Yes, there’s definitely a ton of wrapping with the phase images. I’m not yet 100% sure what MEDIC is doing under the hood, but the output we got was quite reasonable at least in terms of how the images looked.
We had four echoes going into MEDIC, but it doesn’t output a corresponding .json file with the metadata (and I was assuming FMRIprep was using the .json file to infer parameters about the scan, like the echo time difference). In the case of a multi-echo sequence with four echoes where MEDIC produces a great fmap image for each time point, I’m just not sure how FMRIprep should handle the fmap. If we had a proper .json file for any of these fmaps (ideally the first one, though), it seems like FMRIprep could quickly and easily have task- and run-specific fmaps that could be applied to each bold image. Of course, I realize that the major advance with Andrew’s paper is doing this in a framewise fashion, but I know that will take more time.
I still worry that treating the first two echoes as EPIs from a phase-difference field map acquisition won’t work given the large echo spacing, but I suppose that’s a question for Andrew. I don’t know if he tested MEDIC with subsets of echoes (e.g., just the first two) or if it requires >= 5, as in the paper.
What about running MEDIC to get volume-wise field maps and then grabbing the first volume’s field map and labeling that as your BIDS field map? Basically, following Case 3 in the spec, in which case you don’t need EchoTime values. The benefits there are that the validator wouldn’t raise an error for your data and the field map would be derived from all of the echoes.
Ah, thanks Taylor! I totally overlooked Case 3 in the BIDS specification and incorrectly assumed that these would be like the phasediff maps we normally have.
MEDIC seems to work fine with four echoes, but I realize this is still beta software. I was able to generate the fieldmap.nii.gz images from the first volume of the the MEDIC output, and I’m just using the first volume of the bold sequence as the magnitude image (not sure if the sbref image would be better here since it has better contrast). In any case, I’m not 100% sure about the .json files. If I’m understanding the BIDS spec correctly, it seems like mainly need the three fields below in our fieldmap.json file. We’ll see if this works with the BIDS validator and FMRIprep.
@tsalo and @effigies and @oesteban – Thanks again for the help, and just following up now that I got a chance to test this in fMRIprep. Although it passes the validator now, FMRIprep still crashes with the error below (it doesn’t produce a crash- file and the html file reports no errors):
240329-08:21:40,860 nipype.workflow CRITICAL:
fMRIPrep failed: The 'mag_files' trait of a _CheckRegisterInputSpec instance must be a list of from 1 to 2 items which are a pathlike object or string representing an existing file, but a value of ['/base/bids/sub-10369/fmap/sub-10369_acq-doors_run-1_magnitude.nii.gz', '/base/bids/sub-10369/fmap/sub-10369_acq-sharedreward_run-1_magnitude.nii.gz', '/base/bids/sub-10369/fmap/sub-10369_acq-sharedreward_run-2_magnitude.nii.gz', '/base/bids/sub-10369/fmap/sub-10369_acq-socialdoors_run-1_magnitude.nii.gz', '/base/bids/sub-10369/fmap/sub-10369_acq-trust_run-1_magnitude.nii.gz', '/base/bids/sub-10369/fmap/sub-10369_acq-ugr_run-1_magnitude.nii.gz', '/base/bids/sub-10369/fmap/sub-10369_acq-ugr_run-2_magnitude.nii.gz'] <class 'list'> was specified.
I wonder if our .json files are screwed up? After we extracted the first volume of the warpkit/medic output, we copied the .json file from the bold images and added fields for IntendedFor, Units, and B0FieldIdentifier for both the _fieldmap.json and the _magnitude.json. Do these .json files only need the IntendedFor, Units, and B0FieldIdentifier?
# extract first volume as fieldmap and copy to fmap dir. still need json files for these.
fslroi $outdir/sub-${sub}_task-${task}_run-${run}_fieldmaps.nii $maindir/bids/sub-${sub}/fmap/sub-${sub}_acq-${task}_run-${run}_fieldmap 0 1
fslroi $indir/sub-${sub}_task-${task}_run-${run}_echo-1_part-mag_bold.nii.gz $maindir/bids/sub-${sub}/fmap/sub-${sub}_acq-${task}_run-${run}_magnitude 0 1
# placeholders for json files. will need editing.
cp $indir/sub-${sub}_task-${task}_run-${run}_echo-1_part-mag_bold.json $maindir/bids/sub-${sub}/fmap/sub-${sub}_acq-${task}_run-${run}_magnitude.json
cp $indir/sub-${sub}_task-${task}_run-${run}_echo-1_part-phase_bold.json $maindir/bids/sub-${sub}/fmap/sub-${sub}_acq-${task}_run-${run}_fieldmap.json
When the B0FieldIdentifier/Source is used, it will take precedent over IntendedFor. We would need to see the BOLD JSON files (in particular, the B0FieldSource) to see how your SDC mappings are being made.
I’m guessing that you used a single B0FieldIdentifier for all of the different field maps, which would explain why SDCFlows would collect each run’s magnitude files for a given field map. The B0FieldIdentifier needs to be unique for each field map.
Awesome, thanks! Yes, the B0FieldIdentifier field was the problem, so I removed that and it looks like it’s working fine now. Output seems to be better than the traditional fmap, but these aren’t super distorted images and it’s a low-motion participant. There does seem to be a bit of a bias field, though I’m not sure how problematic that is here. See example output.
Either way, thanks for all the input and help. Will be very exciting to see this implemented into fmriprep in a framewise manner like in Andrew’s paper, but that’s a conversation for another day. I think the original subject line here is was solved with Taylor’s original response, so I’m going to mark it solved and stop spamming the list serv. Thanks again!
Glad you got it working, @dvsmith! A better image from the HTML to analyze might be the BOLD-to-T1w correspondence, which should be soon after the before-after SDC plot. If SDC was applied well you should see good anatomical matching between the BOLD and T1. Especially pay attention to the frontal area, as that appears to be where the most warping was.
Thanks, Steven! I could be mistaken, but the red lines in these images reflect the gray/white tissue boundary from the T1 scan, so I think those also give a great sense of alignment to anatomy and a direct comparison of distorted and corrected images. But yes, the corrected image overlaid on the T1 is also gives a much clearer sense of how well the corrected image matches the anatomy (and not just the gray/white tissue boundaries).
I’ll have to do more direct comparisons between phasediff GRE fmaps we collect vs. these derived fmaps that Andrew’s warpkit program outputs, but these are encouraging results. They will certainly work well in cases where we had participants get out of the scanner in the middle of the scan and we neglected to get a second fieldmap. In principle, it seems like we could save a few minutes and stop collecting the traditional fmaps…
