I wanted to include fieldmap-based distortion correction in my preprocessing with fmriprep (this case). Unfortunately, according to the scanner technician there is no way whether the PhaseEncodingDirection was j or j-, other than trying both out and see which one does better.
i did that, but in the fieldmap part of the report, there is no change between the fixed and moving phases of the images. So, that makes it hard to tell which PhaseEncodingDirection was the correct one and makes me also wonder whether the distortion correction actually worked. In case it matters, I also included the SyN correction, which seems to do its job.
Here the two reports. _fmap corresponds to j and _fmapNeg to j-
In order to make the reports digestible by the browser, we had to strip out the display objects to the sub-<sub_id>/figures/ folder. Please include those with the reports.
From the information you provide, I’m afraid you are not actually applying the fieldmaps. Even though this is something we have on our TO-DO list to change, right now FMRIPREP will dismiss your fieldmaps unless there is an IntendedFor field in the JSON corresponding to the fieldmap (see BIDS spec, sec 8.4).
An important parameter you will need to provide is the EffectiveEchoSpacing (or one of its alternatives).
Please, let us know if any of this helped resolve your issues.
Of course! Here is another download link including all the figures for both reports, and also an example fieldmap.json file and one EPI.json file.
right now FMRIPREP will dismiss your fieldmaps unless there is an IntendedFor field in the JSON corresponding to the fieldmap
As you can see in sub-01_fieldmap.json, I did specify the IntendedFor field. And from the report I can also see that some processing with the fieldmaps was done, I just don’t see what effect it had on the registration, so that I can’t judge which PhaseEncodingDirection to choose (j or j-).
An important parameter you will need to provide is the EffectiveEchoSpacing (or one of its alternatives).
Also this parameter I specified, but in the json file of the functional scan.
I had a look at the metadata and I noticed that _fieldmap.json is missing Units and the IntendedFor field should be relative path not absolute (see section 8.9.3 http://bids.neuroimaging.io/bids_spec1.0.2.pdf). _bold.json is missing TaskName field. It might be worth running bids-validator on this dataset to make sure there are no other issues.
One potential cause I can think of is if phasediff data was confused with precomputed fieldmap data.
@oesteban: Here some example data. I included the image of the anatomy, of one functional run, of the fieldmap and of the magnitude (and corresponding .json files).
@ChrisGorgolewski: Thanks for the advice. I added the fields and am currently rerunning fmriprep. I also started the bids-validator. Is it normal that it doesn’t seem to do anything? I tried the online version both with chrome and firefox, but whenever I select a directory, the label next to the button still shows “no directory selected”. Sometimes, the label did change to the selected folder, but nothing else happened on the screen for ~1-2h. Now, I installed it via node.js and started running it. The process does start and is still running, but it’s also taking quite a bit of time (>30 minutes currently). What is the expected duration of the procedure?
Edit: Maybe it is important to add, that the data is on a remote server, and I run the validator locally, after mounting the remote directory.
This is not normal - the validator should only take a few seconds to run. I expect that the delays you experience are due to the fact the data are on a remote server. Try installing the validator on the server and running it there.
Try installing the validator on the server and running it there.
Ok, I did that and the dataset passes the tests now. I rerun fmriprep twice, once with j as PhaseEncodingDirectionand once with j-. The part of the final report that shows the effect of the fieldmap correction (Results of performing susceptibility distortion correction (SDC) on the EPI), still shows no difference between before and after and between j and j-.
However, when looking at the effect of SyN-based correction, the after image seems to look a little better than the before one when using j, but better before than after when using j- (But maybe that’s just me). So, could the reason for not seeing a difference after the fieldmap correction be that this is merely an intermediate step in the distortion correction pipeline but the final output of it includes both fieldmap as well as SyN-based correction?
To check that I am currently running fmriprep without the --force-syn flag. In that case, the fieldmap images, should show a before-after difference, right? Once it finishes, I will post the results here.
Here the download link for the fmriprep reports with positive and negative PhaseEncodingDirection along j:
It seems all your settings check out. Let’s see if there might be some other issue.
Since your fieldmaps seem well aligned with the bold run, only one more thing could be affecting: the effective echo spacing is too small. Distortion is inversely proportional to the effective echo spacing. If, for some reason, it is not correctly calculated, then you might expect the wrong displacement field to be calculated.
A potential source of this problem is not taking into account the in-plane acceleration factor. For instance for a GRAPPA acquisition of 2x, your effective echo spacing is half the nominal time.
Other than that, everything looks good.
You can give it a try with a different factor (e.g. divide your current EffectiveEchoSpacing by 10 and I would be surprised you don’t see a correction being applied).
Thanks again for your help. I followed your suggestion and tried direct fieldmap correction with an EES lowered 10-fold (0.0000359 instead of 0.000359). However, there is still no difference between before and after in the report. And it still doesn’t seem to matter whether I specify the PhaseEncodingDirection to be negative or positive j.
A potential source of this problem is not taking into account the in-plane acceleration factor. For instance for a GRAPPA acquisition of 2x, your effective echo spacing is half the nominal time.
Orginally, I did take this into account, so this shouldn’t be the reason for that pattern here.
Here the reports for the runs with lowered EES, once with j and once with j- as PhaseEncodingDirection.
In my opinion, the correction looks fine in either case, but because it shouldn’t be the same for j and j- I am a little confused and concerned that there is a problem somewhere that will cause problems later on during the analysis.
I have a question when comparing the results from different SDC workflows. When using using Direct B0 mapping sequences, I found little change before and after SDC, while using Phase Encoding POLARity (PEPOLAR) the effect of SDC is very obvious, which made me wonder if we set up B0 SDC properly.
You can check the svg files before and after SDC as well as the json files here.