External Visualization in BrainNet Viewer

[Viv]

Hi Chris,

thanks for your great braingraph package...I enjoy working with it.

I have a question on visualization the results in braingraph:

Do you think it would also be possible to extract the (both corrected and uncorrected) results in a weighted adjacency matrix in .txt file format? The inputs would represent the test statistic output from lets say the NBS approach.

The reason is that BrainNet Viewer (https://www.nitrc.org/projects/bnv/) offers great flexibility in terms of visualizing the results based on an weighted adjacency matrix.

Thanks for your help on this

Cheers Viv

[Chris Watson]

Hi Viv,

Yes this is a very good idea, and one that I should have thought of already!

As you may know, I have a function, write.brainnet, that creates the relevant ".node" and ".edge" files for viewing with BrainNet Viewer. Today I made a simple addition to allow for edge weights: you will simply use the "edge.wt" function argument, and change it to whatever you would like to view.

I also noticed some issues with the NBS code. I have changed the function drastically, with many improvements:

* It is much faster for connectivity matrices that are not extremely dense (i.e., matrices that don't have positive values for most of the matrix elements). RAM usage is slightly higher, though this shouldn't be an issue. If your connectivity matrices are dense, this will be slower than the old implementation, but more accurate results.

* It returns the correct t-statistics as edge attributes (accessible by "E(g)$t.stat"). Previously, the t-statistics were not assigned to the correct edges under certain situations. It is now correct. (In the case above, you would use "edge.wt='t.stat'" for writing a BrainNet file.)

* It now also returns the p-values associated with the significant edges (the edge attribute is simply called "p", and can be used with "write.brainnet" as well). These p-values are *not* corrected in any way, and simply represent the value associated with the "Group" predictor variable, based on the linear model

* Added in v0.62.0 was the vertex attribute "p.nbs", which represents the p-value associated with the entire connected component. This was correct and will remain in the function.

Note that you can also quickly visualize edge attributes/weights using "plot_brainGraph_gui". My next package update will include GUI entries for limiting the maximum value of edge attributes. For example, if you only wanted to view edges with a negative t-statistic, you would select "Other", and in the box "Max. 1:", you would enter "0".

I will try to push all of these changes to Github by the end of the day. CRAN does not like package updates that are close together in time, so that will have to wait awhile for an official update.

Please let me know if you have any other suggestions, issues, etc.

Chris

--
You received this message because you are subscribed to the Google Groups "brainGraph-help" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brainGraph-he...@googlegroups.com.
To post to this group, send email to brainGr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brainGraph-help/8592b09e-7105-4303-a2bb-87c98b049aa9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Viv]

Hi Chris,

I do really appreciate your support on this, thank you very much. I'm looking forward to test all of this with a quite large data set N ~ 150.

In my case, I'd use connectivity matrices as inputs from deterministic or probabilistic tractography...this means DTI streamlines between brain regions from different atlases would serve as "connectivity measure".

1) So far I used NBS through its Matlab GUI...in terms of usability the GUI has some advantages that I think could be worth to consider to implement in brain graph NBS...it would be great that the same input measure from GUI_NBS could be defined before starting the R_NBS approach.

design <- [formula maybe using directly the a formular input (e.g lm(y = m*x + q] / or maybe lme for flexibilty

contrast <- [1 -1]

exchange blocks <--- [depending on the design...especially repeated measures worth considering]

iterations <- 5e3

pthreshold - 0.05

2) Another interesting thing would be extending NBS with a threshold-free cluster enhancement function...but thats already coming in GUI_NBS2.0, I guess ;)

3) Something that could be very interesting would be the possibility to combine inputs from multimodal MR data. For example including functional (rs-fMRI) and structural (anatomical, DTI) connectivity into one analysis using the same atlas and see potential overlaps between different modalities / networks / lobular structure.

In case me ideas seems a little chaotic or redundant, I'd be happy to explain them on skype or private chat 

Best wishes,

Viv

[Chris Watson]

Hi Viv, I am happy to help implement new features into the package.

1. I agree that GUI's are better from a usability standpoint, but they are more of a hassle to create and maintain. It is something I will consider in the future. RE your specific points:

• Design: I had avoided trying to write anything more about specific design matrices, due to simplicity. Currently, the function will only perform a GLM and focus on the "Group" predictor coefficient & t-statistic. If your concern is that you have a "covariates" file/data.table with all covariates, including ones that are not relevant to the current analysis, is that on the command line you would exclude these. E.g. if you had a column for "FSIQ", but did not want to adjust for that, you would specify: NBS(A, covars=covars[, !'FSIQ', with=F]).
• Contrast: Connected to the "design" issue. I have very recently written some code to handle contrasts. The reason I avoided doing more so far is that I was only concerned with group comparisons, and with the way R parameterizes factors, a simple +1 or -1 would indicate "Group1 > Group2" and vice versa. However, this does not allow for more complicated designs & contrasts. I would love to eventually include this functionality, but unfortunately I am deep into my dissertation and would not be able to dedicate enough time until August, probably. But if you wanted, I could probably quickly create a function and you could do some testing on your data.
• Exchange blocks: also connected to the above; repeated measures analysis is something that would require a lot of time for me to think about, and would not happen until further into the future.
• Iterations & p-threshold: these are already handled by the "N" and "p.init" function arguments

2. TFCE is a fantastic method and I would love to include functionality for it, but once again it will not be until I am finished with my dissertation (later this summer), I'm afraid.

3. Multi-modality: I have only done this so far for volumetric measures (i.e. thickness, LGI, volume, and surface area). This is why I introduced the "modality" argument to the functions: "brainGraph_init" (which creates the data.table "all.dat.tidy"; "set.brainGraph.attributes". These have downstream effects of including a "modality" column in the data.tables "dt.global" and "dt.net.meas". Then you can look at modality-based measures and how they differ, and use "plot_global" to show the differences (see Figure 21 of the User Guide; the different modalities would have a different line type, e.g. dashed vs. solid). I don't have an example on-hand but could include one soon.

I appreciate your feedback and suggestions!

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/brainGraph-help/d734a674-c6c2-4323-824b-ed070ceaba16%40googlegroups.com.