Question for command "wb_command -cifti-gradient"

[yu li]

Hello, I'm using "wb_command -cifti-gradient" to caulate the gradient of left surface. I don't quite understand the parameter <direction>. Could anyone give suggestions?
In my opinion, if I use COLUMN, that means workbench will caulate gradient for each single column, and this process is independent between columns. Any questions? So I think using the parameter "ROW" or "COLUMN" is depend on what we want to do. For example, if I think the rows of matrix represent vertices and the columns of matrix represent features(e.g, functional connectivity), I should use COLUMN in "wb_command -cifti-gradient". But in the introduction of "wb_command -cifti-gradient", why recommend "ROW" for dconn files and "COLUMN" for dtseries files? Is the consideration between speed and PC memory?
Now, if I have a symmetrical functional connectivity of left surface (32k*32k) , and want to calculate its gradient (then smoothing), how to do? There is my code as fllows:

wb_command -cifti-gradient FC.dconn.nii COLUMN FC_gradient.dconn.nii -left-surface Conte69.L.midthickness.32k_fs_LR.surf.gii
wb_command -cifti-smoothing FC_gradient.dconn.nii 2.55 0 COLUMN FC_gradient_smooth.dconn.nii -left-surface Conte69.L.midthickness.32k_fs_LR.surf.gii

If I use "ciftiopen“ to open the result "FC_gradient_smooth.dconn.nii" in matlab, I could obtain a 32k*32K matrix. So for each sigle column of this matrix, does it represent a gradient with smooth for left surface?

Thanks a lot!  

[Coalson, Timothy Scott (S&T-Student)]

Yes, the direction is referring to the "axis" in the cifti file to treat as spatial maps.  The reason ROW is recommended for dconn is that when displaying a dconn in wb_view, each row is used as a spatial map (while in dscalar, dtseries, etc, each column is used as a spatial map).  The reason for this is that cifti is organized such that it is fast to read a single row from the file, but reading a single column is rather slow, and because we generally don't read the entire dconn file into memory.

Why are you smoothing after calculating the gradient?  Since gradient is a derivative, it is more sensitive to noise in the input to​ the gradient command, which is why it has presmoothing options.  Taking the magnitude of the gradient prevents you from being able to deal with this noise after the fact (if you used the gradient vectors instead, smoothing those afterwards should be roughly equivalent to presmoothing, but with extra work and disk space).  Sharp, thin features in the gradient output are actually what you want to see when your data is properly aligned (look at https://balsa.wustl.edu/ZKv3), so smoothing the gradient magnitude doesn't seem like it should be useful.

Tim

---

From: yu li <lyw...@gmail.com>
Sent: Wednesday, May 19, 2021 12:15 PM
To: HCP-Users <hcp-...@humanconnectome.org>
Cc: ly...@mail.ustc.edu.cn <ly...@mail.ustc.edu.cn>
Subject: [hcp-users] Question for command "wb_command -cifti-gradient"

 

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.
To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/41231f6c-0a3a-4148-bc15-ce17a0e797d8n%40humanconnectome.org.

[yu li]

Thanks for your  prompt reply. After understanding your reply, here are some conclusions and questions.

1) For dconn files (or pconn?), wb_view regards row as a spatial map, but others regard column as a spatial map. By the way, how to display the dconn results in wb_view? I loaded it, and see some information such as histogram. But is there any visual figure such as dscalar, dtseries？

2) I think the rule mentioned in 1）is just for wb_view, which "axis" in the cifti file to treat as spatial maps is depended on the argument <direction> in ”wb_command -cifti-gradient“ and "wb_command -cifti-smoothing". In other word, I could use "COLUMN" for dconn and dscalar files, and their results are same if their data (martices) are same.

3) Actually, the reason why I focus on this question is that I need to use some toolboxes to read and write cifti files for further analysis, so I have to understand if the "axis"(i.e., COLUMN and ROW) of wb_command is same as  "axis"  of matrices obtained from other toolboxes. Specifically，I used cifti-matlab-master toolbox in Matlab2017, and nibabel for Python3.7. In practice， the matrices obtained from "ciftiopen" and " nibabel.load " are transposed. So which is same as wb_command？I guess "ciftiopen" is same as wb_command because " nibabel.load " would got 1*29696 (not 29696*1) matrix for left surface files.

Could you give some suggestions for these points?  For "smoothing" option, I will mull it over again.

Thanks a lot.

[Coalson, Timothy Scott (S&T-Student)]

Mostly, yes, but be careful: the output of smoothing or gradient on a dconn does not have symmetric values, and the commands do not add a transpose if you use COLUMN (they take a column, smooth it or whatever, and put it into a column of the output file, and when using ROW, they take a row, operate on it, and put it into a row of the output file).  You can use COLUMN with dconn, but to get the same resulting file as using ROW, you will need to additionally use -cifti-transpose afterwards.

To display surface-based data, you need to load surface files, cifti does not contain the information of triangles and vertex coordinates (midthickness is good for computation, but not for viewing, where we use inflated, so putting either of those surfaces "inside" the cifti format would have drawbacks).  For dconn, you then need to enable the layer, and then click on a vertex or voxel that the dconn contains data for.

The "matrix orientation" issue is slightly more complicated than that: matlab forces the "rightward" dimension to be the second index, but internally to the cifti format, "rightward" is the first dimension (because this is the only way to implement "rows are fast" in nifti-2).  wb_command mostly gets around that by usually asking for names (ROW or COLUMN) rather than something like "first dimension".

Tim

---

From: yu li <lyw...@gmail.com>
Sent: Thursday, May 20, 2021 4:59 AM
To: HCP-Users <hcp-...@humanconnectome.org>
Cc: Coalson, Timothy Scott (S&T-Student) <tsc...@mst.edu>; ly...@mail.ustc.edu.cn <ly...@mail.ustc.edu.cn>
Subject: Re: [hcp-users] Question for command "wb_command -cifti-gradient"

 

[tony han]

Hi Tim,

I'm curious why the gradient matrix from a correlation matrix is not symmetric? The correlation matrix is symmetric, so extracting a correlation map for a given vertex should be the same no matter which axis (either row or column) is used. Could you elaborate a little more on how the gradient is calculated? Thanks.

liang

[Coalson, Timothy Scott (S&T-Student)]

Consider the element (100, 2345) of the output - if you run it one way, the output value is based on the neighbors of element 100, and the other way, the value is based on the neighbors of 2345.

Tim

---

From: tony han <tonyl...@gmail.com>
Sent: Thursday, May 20, 2021 7:14 PM
To: HCP-Users <hcp-...@humanconnectome.org>
Cc: Coalson, Timothy Scott (S&T-Student) <tsc...@mst.edu>; ly...@mail.ustc.edu.cn <ly...@mail.ustc.edu.cn>; yu li <lyw...@gmail.com>

[Coalson, Timothy Scott (S&T-Student)]

And an even simpler difference: one direction looks at the map produced using 100 as the seed, while the other looks at the map produced with 2345 as the seed - yes, they trivially share one value exactly (correlation between 100 and 2345), but the rest of the values in those two maps are not equivalent.

Tim

---

From: Coalson, Timothy Scott (S&T-Student) <tsc...@mst.edu>
Sent: Thursday, May 20, 2021 7:33 PM
To: tony han <tonyl...@gmail.com>; HCP-Users <hcp-...@humanconnectome.org>
Cc: ly...@mail.ustc.edu.cn <ly...@mail.ustc.edu.cn>; yu li <lyw...@gmail.com>

To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/SN6PR01MB4991164C821B137F0D7B0A7381299%40SN6PR01MB4991.prod.exchangelabs.com.

[Coalson, Timothy Scott (S&T-Student)]

As for interpretation, one of them asks "where are the boundaries of what this seed correlates with?", while the other asks something like "what areas have a difference in correlation between the seed and its neighbors?"

You can generate a transposed dconn gradient and click around to compare - clicking in the center of an area without much "topology" should give you mostly low values plus some noise (which may get visually amplified if you have the palette set to auto-scale) - this makes sense, as in the normal dconn gradient, there is no seed location that results in an "edge" in correlation near that point (excluding the near-seed spike from the pointspread function and voxel sharing, anyway).

Tim

---

From: Coalson, Timothy Scott (S&T-Student) <tsc...@mst.edu>

Sent: Thursday, May 20, 2021 7:39 PM

To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/SN6PR01MB4991FF4CC23289ACAC70087681299%40SN6PR01MB4991.prod.exchangelabs.com.

[tony han]

Hi Tim,

Thanks for you detailed explanation.

liang

[yu li]

Thanks!  For "matrix orientation"  question,  here is my  understanding.

I don't know if you ever used "ciftiopen" of Matlab. For example,  if I use "ciftiopen" read a cifti file into Matlab, and get a 29696*200 matrix. Obviously,  29696  represents vertex number, and 200 is the feature (e.g., timepoints, functional connectivity seed ...). Although this orientation is more in line with my habit (i.e., vertex * feature), it is transposed when compared to wb_command (200, 29696). In other words, if we regard the first dimension as row and the second dimension as column, they are transposed. When use ”wb_command -cifti-gradient“, we should use ”COLUMN“ because the column is a spatial map. If I am right, is this rule suitable for all cifti files (.dscalar , .dconn, ..pconn, dlabel, .dtseries,. etc.)? Especially for dconn.nii, because its matrix usually is N*N, we could not recognize it based on the shape of matrix.  By the way, it appears that the matrix obtained from "nibabel.load" of Python is consistent with wb_command (if you know this tool).

[Coalson, Timothy Scott (S&T-Student)]

Actually, no, by convention, in dconn a "map" is a row, not a column.  For dtseries, dscalar, and dlabel, a map is a column.  The other "conn" types (pconn, pdconn, etc) use a row as a map, like dconn.

Because matlab (and linear algebra in general) has a fixed convention of what index goes which direction, "transpose" has more than one possible interpretation when comparing to other software.  wb_command mostly does not expose which direction it considers the "first" index.

I am aware of those tools to load cifti.  I think nibabel returns the data as a numpy array, which I would guess uses the linear algebra convention of what the first index means, so it seems unfortunate if it loads cifti in a different orientation than ciftiopen/cifti_read.

Tim

---

From: yu li <lyw...@gmail.com>
Sent: Friday, May 21, 2021 8:32 AM
To: HCP-Users <hcp-...@humanconnectome.org>
Cc: Coalson, Timothy Scott (S&T-Student) <tsc...@mst.edu>; ly...@mail.ustc.edu.cn <ly...@mail.ustc.edu.cn>; yu li <lyw...@gmail.com>

[yu li]

Thanks, I got it. But a practical question is that how to know which dimension refers to spatial maps when we read dconn files by other tools such as "ciftiopen". As I mentioned before, I calculate the gradient using "wb_command -cifti-gradient"(parameter ROW),  and then read it in Matlab as a N*N matrix, I don't know which axis represents a spatial map. For me, I first save the N*100 matrix to dscalar.nii file, this matrix is the first 100 columns of that N*N matrix. I then use this dscalar.nii file to calculate the gradient maps. After compared to N*100 and  N*N gradient maps, I could find which axis is a spatial map for N*N matrix. But this way is a little inconvenient. Could you give me any suggestions? Maybe this problem should be proposed in a related toolbox forum.

[Glasser, Matthew]

Our Matlab tools treat CIFTIs the same as wb_command. I can’t speak for other tools we didn’t write.

 

Matt.

To view this discussion on the web visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/0bd6ceff-0e58-436d-8ec4-b5d38ce8767dn%40humanconnectome.org.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[yu li]

Thanks a lot!