dHCP fMRI without SBREF or Fieldmap

I have run the structural pipeline on our neonatal with relatively high success and would like to also use the fMRI pipeline. Unfortunately, I do not believe we have SBREF or spin-echo EPI images. I noticed a solution to having no Fieldmap and am hacking the script to either

  1. Use the scripts motion correction methods to register the func to anat
  2. Slot into the script our own motion corrected func in anat space

Or maybe it just be easier to write our own script to use the trained FIX classifier and not use the fMRI pipeline (unless below question 2) applies)?

My two main questions

  1. Has anyone faced this issue of not having SBREF. Did you edit the script to go straight from func to anat. Or, did you skip the registration process and input your own motion corrected func to anat images.
  2. I can get my hands on ‘DTI field maps’, can I insert these directly into the pipeline (in place of the spin-echo EPI images) or do I need to pre-process them in any way?

Thanking in advance for any advice offered!

Hi Johann

My advice, in the absence of SBREF, would be to take the temporal mean of the fMRI and call it your SBREF. The SBREF is just used an intermediary registration target in the func-to-T2 alignment because it has better tissue contrast than the func. The temporal mean of the fMRI would have better SNR than the func and potentially also have better contrast. This way the registration would go from the 1st-volume of the func, to the mean of the func, then to the T2w. It is important that the 1st volume of the func is used because the motion correction step (with EDDY) expects the field map to be aligned with the first volume.

You can use the DTI field maps if there has not been a shim between the fMRI and the DTI, however keep in mind the field map will be less appropriate the further away in time it is from the fMRI acquisition. IHMO I think it would likely still be better than no field map.

In terms of pre-processing, the field map will need to be in rad/s as per FSL Fugue: FUGUE/Guide - FslWiki

Alternatively, if you have B0s with two different phase encode directions, you could use FSL topup to generate a field map for you. topup - FslWiki

I hope this helps.

Cheers, Sean

Hi Sean,

Many thanks for the detailed reply! That is a good pointer/workaround in the absence of SBREF.

I have a couple more question about the DTI which I was hoping you could iron out?
*We unfortunately do not have B0s with two different phase encode directions so will have to stick with the DTI ‘method’.

In terms of shim settings we seem to have a range

  • Small differences of: 0 -1 -1 -1 -1 1 6 1
  • Average differences of: 1 5 -19 -82 9 12 8 9 && 7 10 -7 -60 40 -48 24 -15
  • Large differences of: -85 174 -30 100 -423 -107 -315 396
    I assume the large differences are too large, but would the average distances be acceptable? Maybe it is something we just have to test out.

Furthermore, our DTI images are 3D. I assume it is adequate to create 4D images at TR intervals with the same number of time points as the fMRI images. But then our spinecho_pedir will not have alternating directions.
So maybe this method cannot work in our case?

On a final point, when running the pipeline I receive a

  • Traceback (most recent call last): File "/home/johann.drayne/.local/bin/dhcp_neofmri.py", line 609, in <module> p.import_data(**args) File "/home/johann.drayne/.local/lib/python3.8/site-packages/dhcp/func/pipeline.py", line 147, in import_data importdata.import_func( File "/home/johann.drayne/.local/lib/python3.8/site-packages/dhcp/util/util.py", line 51, in timed result = f(*args, **kw) TypeError: import_func() missing 2 required positional arguments: 'func_echospacing' and 'func_pedir'

  • Traceback (most recent call last): File "/home/johann.drayne/.local/bin/dhcp_neofmri.py", line 623, in <module> p.run_all(**args) File "/home/johann.drayne/.local/lib/python3.8/site-packages/dhcp/func/pipeline.py", line 930, in run_all self.prepare_fieldmap( File "/home/johann.drayne/.local/lib/python3.8/site-packages/dhcp/func/pipeline.py", line 204, in prepare_fieldmap self.defaults.on_disk(['spinecho'], error=True) File "/home/johann.drayne/.local/lib/python3.8/site-packages/fsl/utils/filetree/filetree.py", line 363, in on_disk raise IOError("Failed to find any files on disk for {}".format(missing)) OSError: Failed to find any files on disk for ('spinecho',)

But I will post about these in a different topic, seeing as they are probably unrelated.

Hi Johann

Unfortunately I do not have the expertise to comment in more detail on the shim. I will ask one of my colleagues to take a look at this thread and chime in.

By DTI image, I am assuming you are talking about a dual-echo-time fieldmap acquired along-side your diffusion weighted imaging? If so, this should be 3D. The pipeline will align it with the first volume of the fMRI and then it will be used as the initial estimate for the calculation of a 4D motion-by-susceptibility field.

Firstly, are you using the master branch? or the release v1.1 branch?

The master branch is for development, and it is entirely possible that low level changes might have broken high level code such as dhcp_neofmri.py. However, it should work in the release branch.

Irrespective, I don’t believe the high-level interface currently supports the dual-echo-time fieldmap. You would need to use the lower-level python interface. I could add an example to the examples folder early next week if that is helpful.

Cheers, Sean

Hi Johann

I have discussed the shim further with a colleague, and we think that, as you suggest, trial and error will be your best option.

I hope this helps.

Cheers, Sean

Hi Sean,

I appreciate the swift replies!

That’s sounds good, I will trial and error the subjects with varying difference in shim settings. If I notice any ‘trend’ I will note my findings in this thread for future readers.

Yes the image is 3D, however when I pass a 3D image into the pipeline (under --spinecho) I receive an error.
ValueError: incorrect shape for 4D nifti: (84, 84, 43)
The pipeline seems to prefer when it is 4D
But I could be doing something wrong.

I wrote my script based off this example
But maybe I will try this one in the meantime.

Switching to the v1.1 branch cleared up those previous errors. So thank-you for that advice! To note, I had to run with --no-deps flag (i.e. pip install --no-deps ...) and install the python dependencies after, as pprint was causing an issue.

The latest error is that when the pipeline runs eddy, I get a returned non-zero exit status 1. This could be another silly issue I am making, so if you could write an example and if time permits, mock images as well (however just an example would be excellent) I would highly appreciate that! That would probably clear a lot of issues where I could just be making a silly mistake.

All the best,


Hi Johann

I have created an example script for running the pipeline (at a low-level) using a dual-echo-time-derived fieldmap in the master branch:

Hopefully, this will help you to progress. I have added some comments highlighting the main differences to the default dHCP pipeline which uses a spin-echo-EPI-derived fieldmap.

So the problem here is that the --spinecho argument is intended for a spinecho EPI comprised of multiple volumes with opposing phase-encode directions. A fieldmap is then derived from this spinecho. However, as you already have a fieldmap, you can pass it directly which will hopefully be clearer in the example.

Unfortunately this functionality is only currently exposed at the lower python level, and not at the higher dhcp_neofmri.py command line level. I am in the process of updating dhcp_neofmri.py to support some of these alternative use cases, hence why it is currently broken on the master branch. I will attempt to raise the priority in getting it fixed.

Cheers, Sean