using stim_type vs stim_file for face localizer

[yibeichan]

Hi,

I'm using HCP working memory task to localize faces. in the stim_type column, we have face, body, place, and tool. in the stim_file column, we have each different stimulus files.

In a regular GLM localizer, I would use stim_type for modeling, so I used stim_type for GLMsingle as well. But then I thought maybe I should use stim_file since it's single-trial modeling.

If I use stim_file, I'll later aggregate betas from the same stim_type to make my contrast. But I want to understand how statistically different is "aggregating the predictors first (using stim_type)" versus "aggregating betas later (use stim_file for modeling then average beta based on stim_type)".

They for sure would be different, but would this kind of difference significant enough to impact our goal (localizer)? i guess no. but it would still be interesting to know about it.

Thank you!

[kendrickkay]

Can you provide some more details on what exactly is in stim_type and stim_file?

My guess is that you are talking about different choices for the design matrix.

You are right that different results will be produced. But it is likely that the differences will be small/negligible.

Relevant to the decision is the following section from the GLMsingle FAQ (see screenshot below).

The basic issue is what you decide to call the same condition. For example, do you ignore the fact that faces were viewed under both 2-back (I think?) and 0-back task states, or do you separately code those two task states? As long as you have sufficient repetitions of each condition, I think you could adopt the approach of coding the design matrix at a fine granularity (i.e. code the 2 different task states as two separate conditions, e.g. faces0 and faces2).

Note that if you are using GLMsingle, it is ultimately going to provide you with single-trial beta estimates. So, after applying GLMsingle, you are going to be doing post-hoc aggregation in any case.

Let me know if this makes sense.

[yibeichan]

hi, thank you!
here is a screenshot of the event file

stim_file has things like wm/BP_002_BP10_BA.png
stim_type has Body, Face, Tool, Place.

i didn't use trial_type (2-Back, 0-Back, etc.) since my goal was to get a face localizer. I think using stim_file makes sense. I put all 15 runs into one GLMsingle with the session splitter. After I got single trial betas, I did a contrast (Face > Place) with t-test, then FDR corrected.

Also, I did two versions, one with all "Cue" trials (4 in total), one without them. I got different results. The one removed four Cue trials has ~ 100 more significant vertices. Wow, only four trials, that large difference?

[yibeichan]

sorry, i meant to say 4 "cue" trials per run.

[kendrickkay]

Thanks for the information, but I remain a bit confused:

• When you say that you used stim_file, do you mean that you coded conditions at the image level? That is, do different images get associated with different conditions?
• When you say 15 runs, is that correct? (How long are the 15 runs?)
• And, I am not sure what cue trials are, so I can't comment on whether or not modeling them should make a big difference. In general, one should code all possible events that might evoke BOLD responses.

Perhaps you can show a picture of the 2D design matrix that you are using for GLMsingle

[yibeichan]

Hi hi,

each run is about 5 minutes (TR=1.49). I removed the cues because I found that in some subjects' some runs, the cue onset overlapped with the subsequent stimulus onset.

Yes, each stimuli file (192 unique files in total) is associated with one stim_type (body, face, tool, place), and four stim_type can repeat in trial_type (either 0-back or 2-back). The cues are those stimuli files as well (sorry, I'm analyzing an existing dataset so I don't know why cues were present there, but it looks like every time switch between 0-back and 2-back, there is a cue)

below are two versions of the design matrix (x-axis: stim_file, y-axis: TR); each cluster is either 2-back or 0-back.

here is the design matrix without "Cue"

this is the one with "Cue" ( the red dots)

When you say, "In general, one should code all possible events that might evoke BOLD responses", it should be the case for typical GLM design. But now I'm thinking of my ultimate goal here #156 . It's naturalistic design (video watching), literally the BOLD responses are on all the time during watching. It could be fundamentally wrong if we only model/annotate faces? But I guess that's why I need to do the face localizer first?

[kendrickkay]

I am having a little trouble understanding what's going on, but a few thoughts: Based on your screenshots, it looks like the cue is not that important. It might just be a brief "instruction" to the subject. So probably safe to just ignore it completely.

It looks like you are attempting to model each stimulus image separately. This might work, but one challenge is having enough sensitivity to do this. One issue is do individual stimulus images repeat across different runs? A prerequisite for GLMsingle is to have at least some repeats.

There are some blank white columns in your design matrices, which presumably mean that the shown run doesn't have all of the stimulus images present. This isn't a problem, but just an observation.

As I mentioned earlier, you might need to code the design matrix not at the image level but at the level of stim_type (e.g. Body, Face, Tool, Place) and furthermore to treat each block (~ 16 s?) as a single trial. This will make estimation much easier, and may help with the fact that we need conditions to repeat across runs.

Regarding the movie dataset, that is a whole another "can of worms". There are many approaches... but perhaps not quite suitable for a github thread.

[yibeichan]

Hi, regarding your question:

do individual stimulus images repeat across different runs?

Yes, the same set of images was used across all runs, and there are even repetitions within each run.

I did use stim_type (e.g., Body, Face, Tool, Place) for modeling at the beginning, but then I decided to use each image file. I guess it was because I saw you model each image in the tutorial. But your case was probably different from my current case.
But now, since I modeled each image, I later grouped betas from all images into stim_type and did the contrast.
I could have compared my modeling results on stim_type vs those on each image, but I ran 3 or even more versions (fixed some errors), and I can't remember which "GLMsingle_old" is which model....

Regarding the movie dataset, yes, probably some approaches are more suitable/useful than others to a given research questions. I will email you about it later. Thank you!

[kendrickkay]

OK. Regarding your chosen approach --> presumably, you are able to get "sensible" localizer results based on your GLMsingle outputs. If not, there is something wrong, and could be diagnosed. If you have sample GLMsingle figure outputs, I could take a look to try to diagnose what's going on.

[yibeichan]

Hi, sorry for the late reply. I was checking the results to ensure there were no coding errors.

Main issue: I have too many significant vertices for the face-place contrast.

Results (short version):

• Type-b: Found 775 significant vertices after FDR correction
• Type-c: Found 885 significant vertices after FDR correction
• Type-d: Found 6,310 significant vertices after FDR correction

Steps I took:

• I ran trial-level GLMsingle (1,200 trials across 10 sessions) with type a, b, c, and d, using CIFTI data. This resulted in beta estimates of shape (91,802, 1, 1, 1,200).
• I grouped these 1,200 trials into four conditions (body, face, place, tool) and squeezed the betas to get (91,802, 300) for each condition. Each condition has the same number of trials.
• Type-c and type-d used the same noisepool.
• For types b, c, and d, I computed the contrast statistics using the t-test (face vs. place > 0), FDR correction, and a signal map (~noisepool), yielding the results above.
• I also computed a version using only signal vertices (~51k), which is more liberal, and observed significantly more results for type-d.

The number of significant vertices in type-d is almost 8 to 9 times higher than in types b and c. I did see the expected results in OFA, FFA, and PPC (negative), which is great. However, I also found quite a lot of significant vertices (~100 per hemisphere, with some individual variation) in V1 for type-d.

GLMsingle only generated carpet plots for the surface data, so probably only a little information from there. I made some brain plots for each model, both with and without contrast; they look reasonable. (I'm currently on a plane and can't open the Jupyter notebook on the server to copy and paste the brain plot, sad)

Anyway, I'm looking at "type-d: Found 6,310 significant vertices after FDR correction" and the significant V1 vertices (~ 90 vertices per hemisphere; the individual difference is quite large, though) for the face-place contrast, being surprised, trying to determine whether I've discovered something new or if there's an undetected error in my code.

Let me know if you'd like to see the data.

[kendrickkay]

The information you provide is informative. That being said, I'm not sure if there is a problem. (I mean, it is possible that signal estimation quality is better, and stuff generally gets more "statistically significant".) So, I would have to see in more detail stuff (e.g. brain maps, etc.) to get a better sense.