[Eeglablist] Dealing with bad channels in merged datasets

Makoto Miyakoshi mmiyakoshi at ucsd.edu
Tue Apr 15 10:02:36 PDT 2014


Dear Brian,

> Do you know if there has been a systematic investigation of this issue of
combining data between sessions?

There is no systematic investigation as far as I know, partly because it's
more like theoretically evident issue. ICA produces a static spatial
filter, and if you change the relative positions between electrodes and
sources then you'll need another filter, which violates the stationarity
assumptions...

> We are very precise in our electrode placement.

But as I told you even re-gelling can screw it up... so we don't recommend
re-gelling.

> Our purpose in this study is to remove artifactual components and then
return to the scalp map space - not to continue on to dipole modeling, etc.
(though I intend to work on dipole modeling methods in the future).

I see.

> You mention the problem of probable creation of multiple artifact ICs in
the concatenation method I described. We do see e.g. multiple blink
components in some resting state files I have concatenated this way, but
not for others. And in fact, I often see such duplicate artifactual ICs in
longer datasets that are all from one session, so it seems there are other
generators of this multiple IC problem?

There are two issues. One is the subspace issue. For example, you may find
multiple alpha, mu, EOG, and EMG components. These subspace are
intradependent but inter-independent. This is a normal behavior of ICA, and
actually applying ICA means applying independent subspace analysis. I'm not
a specialist in this topic so if you need I can ask Jason Palmer, who wrote
AMICA, to take over this query. The other issue is the cap/electrode shift
by accident, lapse of time (since cap is elastic and tightened with rubber
band etc...) which is a problem for ICA.

> If the evidence really suggests that reapplication of the cap (multiple
> sessions) makes concatenation impossible,
>

Yes, as I said it is theoretically clear.

 > I see a few ways I could go forward. The first is to do PCA as you
mentioned. This reduces the dimensionality of the data and thus the number
of time points necessary for a good decomposition.

Yes, although Scott Makeig seems to have changed his preference on it over
this years, and now he is more reluctant to use PCA and I have never heard
he recommend PCA before ICA even in seemingly appropriate situations (more
optimism in minimum datapoint estimate for ICA).

> Another method for reducing dimensionality would be to simply
down-sample. I calculate that we would achieve the recommended 30
datapoints per channel^2 necessary for good ICA decomposition if we
down-sampled to 50 channels from our current 84. Could you comment on the
merits of this method vs. PCA?

If you downsample channels, you'll have problems in recovering the scalp
topos with full channels, although just discarding channels is the most
straightforward solution in a sense. I would say applying PCA is better.

> Particularly, what is the nature of any distortion caused by running PCA?
Since it drops variance.

After PCA, when you recover channel signals from ICA activations you'll see
different data (of course, since it's a lossy compression). Though you want
to compare before and after PCA application though, since the difference
should be fairly small.

I appreciate you consider this process seriously and your carefulness.

Makoto

2014-04-09 7:49 GMT-07:00 Erickson <ericksonb.eng at gmail.com>:

> Makoto,
>
> Thanks for your response. Do you know if there has been a systematic
> investigation of this issue of combining data between sessions? We are very
> precise in our electrode placement. Our purpose in this study is to remove
> artifactual components and then return to the scalp map space - not to
> continue on to dipole modeling, etc. (though I intend to work on dipole
> modeling methods in the future).
>
> You mention the problem of probable creation of multiple artifact ICs in
> the concatenation method I described. We do see e.g. multiple blink
> components in some resting state files I have concatenated this way, but
> not for others. And in fact, I often see such duplicate artifactual ICs in
> longer datasets that are all from one session, so it seems there are other
> generators of this multiple IC problem?
>
>
>
> Another option I see would be to split the file into two sets with 84/2 =
> 42 channels each (evenly distributed across the scalp). I would run ICA on
> both of these datasets independently, remove artifacts via ADJUST, and then
> recombine the corrected waveforms. Does this violate the assumptions of
> ICA? Again, I am only interested in removing artifacts, not dipole modeling
> etc. at this time. I appreciate your comments!
>
> - Brian
>
>
>
>
> On Fri, Apr 4, 2014 at 10:36 PM, Makoto Miyakoshi <mmiyakoshi at ucsd.edu>wrote:
>
>> Dear Erickson,
>>
>> > However, since the setup is identical between sessions, we are merging
>> the datasets from each subject's 4 sessions into a large dataset,
>>
>> Sorry to point this out, but you can't do this because electrode cap
>> applications were different for each of 4 recordings, right?
>>
>> Even a re-gelling can move a channel and create 'another' IC which shows
>> 'blocked' ERPimages...
>>
>> Run ICA separately for each of 4 recording sessions. If you don't have
>> enough datapoints, you can run pca to reduce dimensions. For infomax, after
>> 'extended', 1, continue 'pca', 20 for example.
>>
>> Makoto
>>
>> 2014-04-03 13:02 GMT-07:00 Erickson <ericksonb.eng at gmail.com>:
>>
>>> List,
>>> I am creating a data pipeline to process resting state eeg with ADJUST,
>>> and I've run into a conceptual problem with bad channels.
>>>
>>> Our study involved the collection of resting state data across several
>>> days. Individually these resting state files are not long enough to meet
>>> the data requirements of ICA (datapoints/channels^2 > 30 or 40). However,
>>> since the setup is identical between sessions, we are merging the datasets
>>> from each subject's 4 sessions into a large dataset, running ICA on this
>>> dataset, and then applying the ICA weights back to the 4 individual
>>> datasets. We have no reason to believe that the EEG signature of a blink
>>> would be any different between sessions, nor is the cognitive task
>>> different (resting state) so this merge seems to be a nice way to take care
>>> of the problem.
>>>
>>> However, my issue is that if there is a bad channel in one of these 4
>>> datasets, and I remove it, the dimensionality of the datasets is different
>>> and they can't be merged, much less used for ICA. Normally I would
>>> interpolate to get those channels back, but it's not correct to interpolate
>>> before ICA.
>>>
>>> Currently, my solution is just to accept the loss of data. If a channel
>>> is bad in any of the 4 original datasets, I have to remove it from all 4
>>> original datasets. Then I can merge them and run ICA on the merged file.
>>> Then I apply those ICA weights to the 4 original datasets individually and
>>> run ADJUST. However, I'm obviously throwing away a lot of data here so I
>>> would like to know if there is a better way.
>>>
>>> Can anyone suggest an option I am not thinking of to solve this issue?
>>>
>>> Thanks for your time! - Brian
>>>
>>> _______________________________________________
>>> Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
>>> To unsubscribe, send an empty email to
>>> eeglablist-unsubscribe at sccn.ucsd.edu
>>> For digest mode, send an email with the subject "set digest mime" to
>>> eeglablist-request at sccn.ucsd.edu
>>>
>>
>>
>>
>> --
>> Makoto Miyakoshi
>> Swartz Center for Computational Neuroscience
>> Institute for Neural Computation, University of California San Diego
>>
>
>


-- 
Makoto Miyakoshi
Swartz Center for Computational Neuroscience
Institute for Neural Computation, University of California San Diego
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20140415/736a4b1c/attachment-0001.html>


More information about the eeglablist mailing list