fMRIPrep intensity normalization

Hi all,

I’ve got a dataset with some consistency problems. Intensity normalized T1s are available for everyone (just the scanner’s intensity normalization) and un-normalized scans are available for ~ 3/4 of sessions. Should I use everyone’s intensity normalized T1s for consistency? Is there a way to signal that a scan has already been normalized? Does freesurfer get passed the intensity normalized output from the segmentation pipeline or do you use the freesurfer intensity normalization? Do you know if the quality of the segmentation or surfaces will be impacted with pre-normalized T1s (as in, is it bad to normalize a scan that’s already been normalized)?

For what it’s worth, this is longitudinal data with somewhere between 1 and 4 sessions per subject.

Thanks,

Dylan

1 Like

This seems more of a BIDS problem (I guess you could encode the names with an acq- flag). Then this recent addition to fMRIPrep (fmriprep#1770) can help you set up a filter for acq-prenorm (or whatever name you pick). This should be available as of fMRIPrep 20.0.4.

Since you have it for all of them, yes, I’d use the intensity normalized ones. That said, fMRIPrep should not be particularly sensitive to this.

There is no way to signal this. FreeSurfer gets a normalized image.

I have no data to support this. In my experience, it seems that FreeSurfer is super-reliable with pre-normalized scans. N4 (what fMRIPrep runs by default) is also pretty solid (although I have seen failures for this reason).

I would run a first pass on the normalized T1ws with the --anat-only flag (keeping the work directory) to make sure the approach gives good results and then run the full fMRIPrep.

You might be interested in these two developments (although they are not yet ready within any release):

  • fmriprep#2039: will allow you to pre-skull-strip your images on your own, if nothing really works.
  • fmriprep#2036: will make the proposed --anat-only approach more flexible as you will not need to keep the work directory anymore.

Hi @oesteban,

I finally got the data reorganized with the prenorm and orig scans so that I can compare the results of the anat pipeline in both cases. I thought I might just look at the ICC of some of the freesurfer stats and volumes of ROIs transformed back to subject space. Is there anyway to persuade fmriprep to produce these outputs for each session if I use the longitudinal flag, or should I just run each session separately?

Thanks,

Dylan

Hi Dylan,

Thanks very much for the update - that seems like a great plan to me.

Regarding the --logitudinal flag - it only determines how FreeSurfer is going to calculate the T1w average. So you need to split it by sessions. If all sessions have one T1w, then you’d be fine. If you want/may group sessions (e.g. you have a test-restest protocol run on September for 5 years – 10 sessions that go in pairs), then more tricky settings will be necessary.

More on that here: fMRIPrep: how to reuse longitudinal AND pre-run FreeSurfer

Finally, I’d like to bring one discussion @satra usually takes care of clarifying. FreeSurfer via fMRIPrep is not exactly FreeSurfer and should be considered as a variant. In other words: you either run FreeSurfer on its own or via fMRIPrep. But don’t mix both.

Just to be clear, running Freesurfer via fMRIPrep with the longitudinal flag will not produce a stats directory for each session the way FreeSurfer run with the longitudinal flag would. Correct?

Sorry, I was unclear before.

If you set the --longitudinal flag for fMRIPrep, it will propagate it down to FreeSurfer (i.e., FreeSurfer will behave as though you ran it separately with the flag).

When I said you should not mix between anatomicals processed with FreeSurfer via fMRIPrep and directly with FreeSurfer it is because fMRIPrep alters slightly the inputs to FreeSurfer (e.g., the brain mask is re-touched before feeding it into FreeSurfer - instead of just using the one calculated by FreeSurfer).

So the tool (FreeSurfer) is the same (and behaves exactly as you would expect in isolation), but the results of running it within/without fMRIPrep will vary and may not be compatible.

As far as I can tell, Freesurfer from fmriprep with the -longitudinal flag does not produce the session level outputs that you would get from Freesurfer run with the -long flag. (To be clear, I ran this subject with a longitudinal flag through the freesurfer bids app, but as far as I can tell, that’s just doing recon-all -long.) I’ve got a subject (20900) with two sessions (session 01 and session 04). When I run that subject through recon-all -long I get the following outputs:

fsaverage      rh.EC_average  sub-20900_ses-01                 sub-20900_ses-04
lh.EC_average  sub-20900      sub-20900_ses-01.long.sub-20900  sub-20900_ses-04.long.sub-20900

When I run the same subject through fMRIPrep with the --longitudinal flag, the freesurfer output directory contains:

fsaverage  sub-20900

And the sub-20900 directory looks like it’s just a single Freesurfer output:

(abcd_mine) [nielsond@cn1500 freesurfer]$ ls sub-20900
label  mri  scripts  stats  surf  tmp  touch  trash
(abcd_mine) [nielsond@cn1500 freesurfer]$ ls sub-20900/stats/
aseg.stats               lh.aparc.stats             lh.w-g.pct.stats         rh.aparc.stats             rh.w-g.pct.stats
lh.aparc.a2009s.stats    lh.BA_exvivo.stats         rh.aparc.a2009s.stats    rh.BA_exvivo.stats         wmparc.stats
lh.aparc.DKTatlas.stats  lh.BA_exvivo.thresh.stats  rh.aparc.DKTatlas.stats  rh.BA_exvivo.thresh.stats
lh.aparc.pial.stats      lh.curv.stats              rh.aparc.pial.stats      rh.curv.stats

Is that difference not intended?

Hi @oesteban, just bumping my reply up in case you hadn’t seen it. The longitudinal pipeline in freesurfer creates the subject template across all sessions, and then produces one output per session registered to that subject template, so you get one set of registered stats per session. It looks like in fmriprep, it’s just doing that first bit. Is that not what’s intended? I understand that fmriprep is primarily a functional pipeline, so I think it’s fine that it’s not doing everything needed for an anatomical analysis, I just wanted to make sure that difference is known and intentional.

Sorry for the slow turn around. I’m not very familiar with the details of the longitudinal pipeline of FreeSurfer so I cannot confirm whether that is the expected behavior. Since fMRIPrep is not focused on the anatomical side of things, I guess we never missed out on those stats before.

Surely @effigies will be of more help here.

Right, in fMRIPrep, we pass in the merged template to FreeSurfer as a single T1.mgz, and so FreeSurfer doesn’t have the information to do its standard longitudinal analysis. If someone with more familiarity with the longitudinal analysis would like to help us enable it, I’d be happy to assist, but I don’t know enough to do it myself.

I think there are also some issues with using a pre-calculated longitudinal FreeSurfer reconstruction (again, because I don’t know how to do longitudinal analysis in FreeSurfer), but if we could resolve these, it would probably be the simplest approach to compatibility.

I’m by no means an expert, but my understanding is that the Freesufer longitudinal pipeline consists of running Freesurfer on each session, then creating an unbiased template for that subject, and finally rerunning most of the processing for each session initializing many of the steps based on the within subject template: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3389460/

This deserves a more thorough report, but in case I don’t have time to get to that for a bit, it looks like the prenormed scans produce slightly higher ICCs on average for both freesurfer stats and the volumes of ROIs transformed from MNI152NLin2009cAsym back to session space. This is with a group of depressed adolescents scanned 3-4 times over the course of a year, so your mileage may vary.

1 Like