help
help > RE: Extra scans in condition specification?
Dec 17, 2015 05:12 PM | Pravesh Parekh - National Institute of Mental Health and Neurosciences
RE: Extra scans in condition specification?
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!
Originally posted by Alfonso Nieto-Castanon:
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 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:
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 30, 2016 | |
| Pravesh Parekh | Dec 17, 2015 | |
| Alfonso Nieto-Castanon | Dec 17, 2015 | |
| Pravesh Parekh | Jan 25, 2016 | |
| Alfonso Nieto-Castanon | Jan 25, 2016 | |