help

help >

**RE: Extra scans in condition specification?**Dec 17, 2015 09:12 AM | Alfonso Nieto-Castanon -

*Boston University*RE: Extra scans in condition specification?

Dear Pravesh,

Yes, there is typically some overlap between the different conditions, where a given scan may be associated with several conditions through different weights, simply reflecting that the BOLD signal at a given scan may be influenced by several conditions (e.g. at the beginning of a block you typically still have some trailing effect of the previous block). Regarding the computation of ROI-to-ROI FC measures, yes, if you compute:

w = max(0,conditionweights{1});

idx = find( w>0 );

data_reduced = cellfun(@(x)x(idx,:), data, 'uni',0);

w_reduced = w(idx);

then the "data_reduced" and "w_reduced" variables represent, respectively, the timeseries and weights that will be used for computing weighted-GLM measures (e.g. weighted correlation). Note that, given that these will be

Hope this helps

Alfonso

Yes, there is typically some overlap between the different conditions, where a given scan may be associated with several conditions through different weights, simply reflecting that the BOLD signal at a given scan may be influenced by several conditions (e.g. at the beginning of a block you typically still have some trailing effect of the previous block). Regarding the computation of ROI-to-ROI FC measures, yes, if you compute:

w = max(0,conditionweights{1});

idx = find( w>0 );

data_reduced = cellfun(@(x)x(idx,:), data, 'uni',0);

w_reduced = w(idx);

then the "data_reduced" and "w_reduced" variables represent, respectively, the timeseries and weights that will be used for computing weighted-GLM measures (e.g. weighted correlation). Note that, given that these will be

*weighted*correlation measures, you will get exactly the same results whether you limit the computation to only the nonzero-weighted scans (e.g. using the "data_reduced" and "w_reduced" variables) or the entire timeseries (e.g. using the original "data" and "w" variables), since excluding the zero-weighted scans just makes the computation faster, but it does not change the result. Also note that, for gPPI analyses, you still need to enter the entire timeseries (i.e. "data" instead of "data_reduced") in the analyses, since gPPI analyses use the zero-weighted scans as an implicit baseline when computing condition-specific effects.Hope this helps

Alfonso

*Originally posted by Pravesh Parekh:*Dear Dr.
Alfonso,

Thank you for your quick response. I think I have some more clarity on the problem (any recommended reading on the same?). So in the present model, when the design matrix is convolved with the HRF, the computed time series would have "overlaps" between conditions, right? And therefore, as in the original question, the 55 time points instead of the expected 40? Not wanting to err on the side of assumption, is this the time series that is being used for further connectivity analysis (let's say bivariate correlation)?

Therefore, in order to "extract" the timeseries used for ROI-to-ROI FC analysis, I should use the same matlab codes (find the non-zero entries and then concatenate the timepoints)?

idx = find( conditionweights{1}>0 );

data_reduced = cellfun(@(x)x(idx,:), data, 'uni',0);

Thank you once again for your help!

Thank you for your quick response. I think I have some more clarity on the problem (any recommended reading on the same?). So in the present model, when the design matrix is convolved with the HRF, the computed time series would have "overlaps" between conditions, right? And therefore, as in the original question, the 55 time points instead of the expected 40? Not wanting to err on the side of assumption, is this the time series that is being used for further connectivity analysis (let's say bivariate correlation)?

Therefore, in order to "extract" the timeseries used for ROI-to-ROI FC analysis, I should use the same matlab codes (find the non-zero entries and then concatenate the timepoints)?

idx = find( conditionweights{1}>0 );

data_reduced = cellfun(@(x)x(idx,:), data, 'uni',0);

Thank you once again for your help!

*Originally posted by Alfonso Nieto-Castanon:*Dear
Pravesh,

The extra-scans that you are finding are related to the hrf (hemodynamic response function) convolution of task effects. To clarify a bit, because of the slowly-varying nature of the BOLD signal (compared to for example neural firing events) the expected BOLD signal effects associated with a block that starts at time 0s and ends at time 9s are expected to span a little bit longer than that 0s to 9s window. This is typically modeled by convolving your block design effects with a canonical hrf function. The convolved effects (which is what it is being displayed in the Setup.Conditions graph) is a continuous signal (instead of just 0/1 values like your original block timeseries) that typically peaks at a later time than the beginning of your blocks and falls-off gradually after the end of your blocks. These convolved timeseries (also the "conditionweights" variable that you refer to) quantify the expected influence of each condition blocks on each individual scan, and they represent, for example, the weights that will be used when computing weighted-GLM measures of connectivity associated with each condition, as well as the "psychological effects" that will be used when computing gPPI measures associated with your conditions. If you wish to skip this hrf-convolution step (not really a good idea for continuous acquisitions, but some times useful for sparse sampling acquisitions or extremely long TRs) you may do that in CONN

Hope this helps, and let me know if you would like me to further clarify anything here

Alfonso

The extra-scans that you are finding are related to the hrf (hemodynamic response function) convolution of task effects. To clarify a bit, because of the slowly-varying nature of the BOLD signal (compared to for example neural firing events) the expected BOLD signal effects associated with a block that starts at time 0s and ends at time 9s are expected to span a little bit longer than that 0s to 9s window. This is typically modeled by convolving your block design effects with a canonical hrf function. The convolved effects (which is what it is being displayed in the Setup.Conditions graph) is a continuous signal (instead of just 0/1 values like your original block timeseries) that typically peaks at a later time than the beginning of your blocks and falls-off gradually after the end of your blocks. These convolved timeseries (also the "conditionweights" variable that you refer to) quantify the expected influence of each condition blocks on each individual scan, and they represent, for example, the weights that will be used when computing weighted-GLM measures of connectivity associated with each condition, as well as the "psychological effects" that will be used when computing gPPI measures associated with your conditions. If you wish to skip this hrf-convolution step (not really a good idea for continuous acquisitions, but some times useful for sparse sampling acquisitions or extremely long TRs) you may do that in CONN

*Setup.Basic*tab by switching the acquisition type field from "continuous" to "sparse". If you do that, then you will find that the samples associated with each condition should now span only the within-block scans (without the extra scans) and that the associated weights are just 0/1 values identical to your original block timeseries (but again, for a continuous acquisition this is not really a good representation of the scans associated with each condition because it is failing to account for the delay and weighting effects introduced by the BOLD signal hrf response)Hope this helps, and let me know if you would like me to further clarify anything here

Alfonso

*Originally posted by Pravesh Parekh:*Greetings Dr. Alfonso (and forum members),

My apologies if the following is something quite intuitive and obvious but I am confused regarding the condition specification in Conn.

I have a block design experiment having five conditions. I have provided the onset time for each of them and also the duration (both in seconds) but the GUI shows me "extra" scans being associated with each of the condition. Elaborating: Condition 1 starts at 0th second and has a duration of 9s (TR = 3, so 3 scans). However, in the GUI, I see that the condition actually spans from scan 1 to scan 6 [screenshot attached]. This holds true for all the conditions.

Further to this, I opened the conn*/results/preprocessing/ROI_Subject*_Condition*.mat file to obtain the denoised time series from each of the ROI and note the following:

- The variable data has the entire time series (210 volumes)

- The variable conditionweights has five 210x1 values which roughly correspond to the condition variable selected. However, I notice that there are "extra" three scans or timeseries values which are non-zero. For example, Condition 3 starts at 4th scan and ends at 11th scan (8*3 = 24s). However, entries 4-14th are non-zero in the conditionweights variable (all five cell objects have the same trend). The same holds for other conditions.

- I use the following (suggested on a different thread) to reconstruct condition specific time series:

idx = find( conditionweights{1}>0 );

data_reduced = cellfun(@(x)x(idx,:), data, 'uni',0);

However, the number of time points are 55 for each ROI (the condition, spanning 8 scans occurs five times, so there should be 8*5 = 40 time points for the timeseries; (8+3extra)*5 = 55 time points)

At this point, I am not sure of what's happening to the condition specification. Why should there be an extra three scans being associated with each condition?

Many thanks in anticipation of your reply, for the wonderful toolbox, and your continued help!

Warm Regards

Pravesh

My apologies if the following is something quite intuitive and obvious but I am confused regarding the condition specification in Conn.

I have a block design experiment having five conditions. I have provided the onset time for each of them and also the duration (both in seconds) but the GUI shows me "extra" scans being associated with each of the condition. Elaborating: Condition 1 starts at 0th second and has a duration of 9s (TR = 3, so 3 scans). However, in the GUI, I see that the condition actually spans from scan 1 to scan 6 [screenshot attached]. This holds true for all the conditions.

Further to this, I opened the conn*/results/preprocessing/ROI_Subject*_Condition*.mat file to obtain the denoised time series from each of the ROI and note the following:

- The variable data has the entire time series (210 volumes)

- The variable conditionweights has five 210x1 values which roughly correspond to the condition variable selected. However, I notice that there are "extra" three scans or timeseries values which are non-zero. For example, Condition 3 starts at 4th scan and ends at 11th scan (8*3 = 24s). However, entries 4-14th are non-zero in the conditionweights variable (all five cell objects have the same trend). The same holds for other conditions.

- I use the following (suggested on a different thread) to reconstruct condition specific time series:

idx = find( conditionweights{1}>0 );

data_reduced = cellfun(@(x)x(idx,:), data, 'uni',0);

However, the number of time points are 55 for each ROI (the condition, spanning 8 scans occurs five times, so there should be 8*5 = 40 time points for the timeseries; (8+3extra)*5 = 55 time points)

At this point, I am not sure of what's happening to the condition specification. Why should there be an extra three scans being associated with each condition?

Many thanks in anticipation of your reply, for the wonderful toolbox, and your continued help!

Warm Regards

Pravesh

## Threaded View

Title | Author | Date |
---|---|---|

Pravesh Parekh |
Dec 17, 2015 | |

Alfonso Nieto-Castanon |
Dec 17, 2015 | |

Yuan-Fang Zhao |
Sep 29, 2016 | |

Pravesh Parekh |
Dec 17, 2015 | |

Alfonso Nieto-Castanon |
Dec 17, 2015 | |

Pravesh Parekh |
Jan 25, 2016 | |

Alfonso Nieto-Castanon |
Jan 25, 2016 | |