Fmriprep: Potentially unreliable and highly idiosyncratic generation of CompCor masks

[oesteban]

While completing #2128, I've come to realize this problematic bit of fMRIPrep:

https://github.com/poldracklab/fmriprep/blob/e5f067ddd67790f25e1ecb51c4ad1d6265a6a31d/fmriprep/workflows/bold/confounds.py#L189-L212

The code here has two major problems (after fixing the original bug and correctly picking the CSF and WM masks):

• [ ] Reliability: masks are generated (and hence binarized) in T1w space, then resampled with NearestNeighbors (with float instead of double-precision). This is prone to having voxels at the edges of the masks that may flip between runs. Considering that these masks are really tiny, just a voxel might introduce a big difference.
• [ ] Detached from the original methods:
  
  
  
  • [ ] Behzadi et al. do not erode the CSF mask, they set a very high threshold for the partial volume map (hence the interest in resampling probabilistic maps).
  
  
  • [ ] Behzadi et al. do not calculate the tCompCor mask the way we are doing (not even close). Here, we heavily erode the CSF+WM aCompCor mask (probably too heavily) and then NiPype's tCompCor interface picks the top 5% most variable voxels of the tSTD map. The original implementation picked the 2% most variable voxels OF EACH SLICE of the tSTD map. No masks at all (other than brain-masking the tSTD map).
  
  

Besides, the preprocessing of these masks is repeated for every run when just once would suffice (however this will not be true if the resampling on BOLD space were the first operation).

I think this has a lot of implications, and we probably want to address some of these issues before 20.1.x comes out.

What do you guys think (@bpinsard, @effigies, @mgxd) about:

• We call the reliability issue a bug, and address it for 20.1.
• We call trying to bring the masks to something closer to the original proposal of Behzadi a new feature and leave it for 20.2.

Related: nipy/nipype#3217
Related: #2052

[oesteban]

FYI @poldrack, @rciric.

[effigies]

At this point, I feel like we're really delaying 20.1, which was never the intent of the new release system. If the concern is that this must be addressed in the LTS, then would you be okay with cutting 20.1 and making 20.2 the LTS? Even if it only shows up two weeks later, there are a lot of features and fixes that people have been waiting on 20.1 to use.

[poldrack]

I am inclined to go with @effigies on this one. better to release the other stuff now and fix this in the next release and then call it LTS

[effigies]

As a quick point: if someone wants to run a bunch of data to present at OHBM, right now they're stuck using 20.0.x or a release candidate. Two more weeks and they'll be really pressed for time.

[poldrack]

and I'm guessing relatively few will be using tCompCor...

On Wed, May 20, 2020 at 12:28 PM Chris Markiewicz [e-mail]
wrote:

As a quick point: if someone wants to run a bunch of data to present at
OHBM, right now they're stuck using 20.0.x or a release candidate. Two more
weeks and they'll be really pressed for time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/2129#issuecomment-631678170,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGUVEBOALZSG4X5LKUFAHLRSQVNZANCNFSM4NGD66EA
.

--
Russell A. Poldrack
Albert Ray Lang Professor of Psychology
Bldg. 420, Jordan Hall
Stanford University
Stanford, CA 94305

[email protected]
http://www.poldracklab.org/

[oesteban]

Okay, let's cut 20.1 and call LTS on 20.2. That makes more sense than being held up with RCs. (cc/ @mgxd)