Match the background vertices and results vertices

[icupsy]

Thanks for the package!

I'm trying to visualize the results of the whole-brain vertex-wised analysis after the correction of multiple comparisons (.mgh file). Here's my code

vis.data.on.fsaverage(subjects_dir = subject_dir,
                      morph_data_lh = "freesurfer/mc-z.abs.th20.sig.cluster.mgh",
                      surface = "inflated", bg = "curv_light")

However, the # of vertices seems to be mismatched, which the .mgh file has 163842 vertices and the background has 655368.

Is there any way to match them? Thanks!

[dfsp-spirit]

Hi icupsy,

thanks for the report. I am currently trying to reproduce the problem on my machine, but the code runs fine (i.e., without error) here. In place of your morph_data_lh file, I used random data like this:

vis.data.on.fsaverage(subjects_dir = subject_dir, morph_data_lh = rnorm(163842, 0.5, 0.1), surface = "inflated", bg = "curv_light")

The number of background vertices is determined by the background type, and should automatically fit your template subject. E.g., for your background choice 'curv_light' with the subject 'fsaverage', the following file is used to determine the background vertices: subject_dir/fsaverage/surf/lh.curv. That file contain the mean curvature for the left fsaverage hemi, and the values in there are thresholded and mapped to the two colors to produce the background. If the vertex count does not match, this sounds like a bug in fsbrain.

Also 655368 seems like a lot of vertices, that does not look like a good value for any FreeSurfer surface. I have 4 questions:

1) How did you install fsbrain, and what is the output of the following command in R: packageVersion('fsbrain')? 2) What happens if you run without the bg = 'curv_light' part? 3) What is the output of length(freesurferformats::read.fs.morph('freesurfer/mc-z.abs.th20.sig.cluster.mgh'))? 4) What is the output of length(freesurferformats::read.fs.morph(file.path(subject_dir, 'fsaverage', 'surf', 'lh.curv')))?

One side note, only relevant after we get the command to execute without errors: even if the command from your post above runs, you are not going to see the background like this. The fsbrain package renders values in the data which are set to NA as transparent, and for them you will see the background. But for your file, mc-z.abs.th20.sig.cluster.mgh, I would assume that it contains no NA values, but only numeric values. You can do something like this to turn certain values to NA:

morph_data_lh = freesurferformats::read.fs.morph("~/path/to/mc-z.abs.th20.sig.cluster.mgh");
morph_data_lh[morph_data_lh > 0.05] = NA;
vis.data.on.fsaverage(subjects_dir = subject_dir, morph_data_lh = morph_data_lh, surface = "inflated", bg = "curv_light");

or with less typing, use rglactions, like this:

vis.data.on.fsaverage(subjects_dir = subject_dir, morph_data_lh = rnorm(163842, 0.5, 0.1), surface = "inflated", bg = "curv_light", rglactions = list('trans_fun'=limit_fun_na(0.0, 0.45)))

[icupsy]

Hi Tim, Thanks for your reply!

1. I installed the package using install.packages("fsbrain") and the version is 0.4.0.

2. If I removed the parameter bg = "curv_light", I'll get the figure with the following warning:

Warning messages:
1: In coloredmesh.from.color(subjects_dir, subject_id, color_data,  :
  Data mismatch: surface has 163842 vertices, but 655368 color values passed in argument 'color_data'.

2: In fs.coloredmesh(mesh, color_data, hemi, metadata = metadata) :
  The mesh3d instance from parameter 'mesh' has 163842 vertices, but 655368 colors passed in parameter 'col'.

3. The output of length(freesurferformats::read.fs.morph('freesurfer/mc-z.abs.th20.sig.cluster.mgh')) is 655368. It seems that the my result file (mc-z.abs.th20.sig.cluster.mgh) has more vertices than I thought.

4. The output of length(freesurferformats::read.fs.morph(file.path(subject_dir, 'fsaverage', 'surf', 'lh.curv'))) is 163842.

I thought the subjects were normalized to the fsaverage and the subsequent statistical analyses were based on the same fsaverage surface. However, it may not be the case here. Maybe I should check which surface were used in the previous statistical analyses.

One side note, only relevant after we get the command to execute without errors: even if the command from your post above runs, you are not going to see the background like this. The fsbrain package renders values in the data which are set to NA as transparent, and for them you will see the background. But for your file, mc-z.abs.th20.sig.cluster.mgh, I would assume that it contains no NA values, but only numeric values. You can do something like this to turn certain values to NA:

Both codes work fine.

Another unrelated question, any chance you know how to save high dpi figures on mac? I've googled it and tried all the methods but I can only got a 72 dpi png/jpeg. I know it is totally unrelated, but worth to try :) Thanks!

Xin

[dfsp-spirit]

Thanks for the detailed reply. What I find suspicious is that your vertex count is exactly 4 times the number of fsaverage verts.

Are these 4 time points or something? Could you try visualizing only the first quarter of your data? What command did you use to generate the file mc-z.abs.th20.sig.cluster.mgh (I guess mri_glmfit)?

[icupsy]

Yeah, I noticed that and I'm trying to figure out what happened.

The result file mc-z.abs.th20.sig.cluster.mgh was generated by the qdec in Freesurfer. However, it is a 32-bit application and I cannot open it on the MacOS Catalina. It's hard to trace back.

I checked the first/second/third/fourth quarter of the data and I found that they are actually different values related to the results. Here are my best guesses:

• 1st: The -log(p) value for each cluster
• 2nd: The -log(p) value for each vertex
• 3rd: The -log(p) value for each vertex within each cluster
• 4th: The # of each cluster

Thanks for the help!

Xin

[dfsp-spirit]

Okay, I am closing this as this turned out not to be an issue with fsbrain. Good luck with your analysis! Feel free to post in here or open a new issue if it turns out that this is related to fsbrain.

I could not find any documentation on the qdec output format online, but if you can point to something, I would be interested. Maybe I could add a small entry to the fsbrain FAQ vignette that explains how to visualize qdec results. I guess you are not the only one who wants to do that.

[dfsp-spirit]

Regarding your question on getting high-DPI images under macos: in my understanding the DPI depends on the size in which the images is printed. But if you are referring to the fsbrain output images, and want a higher resolution, this is explained at the top of this notebook: basically use fsbrain.set.default.figsize(1000, 1000); before plotting.

For the final plots, with a tight layout and potentially a colorbar, have a look here. The example there to get uses

cm = vis.subject.morph.standard(sjd, sj, 'sulc', rglactions=list('no_vis'=T));

but you can get the cm (coloredmeshes) from any visualization function, including vis.data.on.fsaverage().

Keep in mind though that the rgl renderer performs onscreen rendering, so the figure resolution is in general limited by your screen resolution. You can circumvent this by using a virtual display I think, but I have not tried that.