[Eeglablist] ICA time points for good decomposition defined in time

[Russell Toll]

Hi all,

tl;dr: Number of time points needed for good decomposition doesn't take into account sampling rate. How much time (seconds) given some reasonable assumptions is sufficient?

My focus is in dense EEG during resting state. In the past I mainly used 64 channels and about a 3 minute recording. Now I am using a 256 channel EGI saline system and have about 2.5 minutes of recording per paradigm (eyes open or closed).

I'd like to thank Arno and Makoto for their awesome tutorials and explanations that have helped me so much over the years but I could really use some clarification on the issue of time points used in the ICA decomp.

In chapter 09 of the tutorial we see: (https://sccn.ucsd.edu/wiki/Chapter_09:_Decomposing_Data_Using_ICA )

Very important note: We usually run ICA using many more trials that the sample decomposition presented here. As a general rule, finding Nstable components (from N-channel data) typically requires more than kN^2 data sample points (at each channel), where N^2 is the number of weights in the unmixing matrix that ICA is trying to learn and k is a multiplier. In our experience, the value of k increases as the number of channels increases. In our example using 32 channels, we have 30800 data points, giving 30800/32^2 = 30 pts/weight points. However, to find 256 components, it appears that even 30 points per weight is not enough data. In general, it is important to give ICA as much data as possible for successful training. Can you use too much data? This would only occur when data from radically different EEG states, from different electrode placements, or containing non-stereotypic noise were concatenated, increasing the number of scalp maps associated with independent time courses and forcing ICA to mixture together dissimilar activations into the N output components. The bottom line is: ICA works best when given a large amount of basically similar and mostly clean data. When the number of channels (N) is large (>>32) then a very large amount of data may be required to find N components. When insufficient data are available, then using the 'pca' option to jader.m<http://sccn.ucsd.edu/eeglab/locatefile.php?file=jader.m> to find fewer than N components may be the only good option.

Relying on Makoto's pointers, I typically downsample to 100 Hz before ICA (artifact channel rejection, interpolation, rereferencing (let's avoid that controversy for now) has been done). I have 3 minutes of recording so I have 18,000 data points. If my sampling rate were maintained at 1000 Hz, I would have 10 times the data points obviously but the decomposition would also of course not be 10 times "sharper". Task based (ERP or TEP) paradigms need higher sampling rate, but constraining our problem for now to resting, I think we can all agree somewhere between 100-256 Hz is just fine.

When I only had 64 channels, I could come closer to the recommended value for k of 25 with a pca.
No pca: At 100 Hz: 18000/64^2 = 4.4
With pca: At 100 Hz: 18000/25components^2 = 28.8

Now using 256 channels, you can see my concern with the dropping k value. I've experimented with varying the sampling rate between 100 and 250 Hz but as expected, the decompositions are effectively similar. I'd just like to see what the experts think about defining the parameters of a resting acquisition at 100 Hz and defining timepoints with an explicit sampling rate to get a decent k.

Thanks very much for all you do and best of luck to everyone who studies these squiggly lines.

Very respectfully,

Russell T. Toll, Ph.D.
Assistant Professor
Department of Psychiatry
Center for Depression Research and Clinical Care
UT Southwestern Medical Center
5323 Harry Hines Boulevard
Dallas, TX 75390-9119

[utsw]


________________________________

UT Southwestern


Medical Center



The future of medicine, today.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20190222/a4b83f85/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6665 bytes
Desc: image001.png
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20190222/a4b83f85/attachment.png>