Fitlins and BIDS Stats-Models: contrast effects from different tasks

Summary of what happened.

This question is about how to customize the BIDS Stats-Models to compute contrast maps using Fitlins.

I have an fMRI dataset where each subject did two different tasks (A and B) in multiple runs. Each run consists of only one task. So the event file for task A has conditions A1 and A2; the event file for task B has conditions B1-B4. Sometimes, a couple of subjects finished the two tasks in separate sessions.

Key question: If I want to look at brain activations (specifically t-maps) to see areas that activate during task A and not task B, especially, areas that activate during A1, not A2, and during B1 not B2, how could I customize the BIDS-Stats Model file which usually just consists of one task parameter?

BIDS-Stats Model structure

It doesn’t work by just adding “TaskB” in the task field and create the interesting contrasts. Shall I create a design matrix that include conditions of task A and task B simultaneously?

{
   "Name":"ds003_model001",
   "BIDSModelVersion":"1.0.0",
   "Description":"",
   "Input":{
      "task":"TaskA", "TaskB"
   },
   "Nodes":[
      {
         "Level":"run",
         "Name":"subject",
         "GroupBy":[
            "subject"
         ],

Version:

Fitlins version: the latest, 0.11.0

I could do things like that with the BIDS stats model and bidspm : olfactory_fmri_blind/src/analysis_func/models/model-default_smdl.json at master · Remi-Gau/olfactory_fmri_blind · GitHub

Not sure that Fitlins support across run contrasts in general though.

It’s a question of whether pybids can produce a design matrix. I haven’t ever tried it. I would expect some bumps, but if bidspm can do that and it’s considered a reasonable model, we would accept PRs to make it work.

Not sure if FitLins supports this, but as far as the BIDS-Stats Model spec, wouldn’t it make sense to GroupBy “task” in order to them compute the estimate for the two tasks separately, and then compare them at a later stage?

yes that would make sense too

I think that I used a slightly different approach because of the SPM tradition of dumping all the all the runs into one single giant design matrix