[Eeglablist] ICA "adds" noise?
Joseph Dien
jdien07 at mac.com
Thu Dec 20 14:30:45 PST 2012
Just to expand on what Matt said, I've run into the same thing with my automated artifact correction routine in the EP Toolkit (http://sourceforge.net/projects/erppcatoolkit/).
Basically, the deal is that when you designate an electrode as the reference, you are arbitrarily defining it as being zero voltage. When you designate both mastoids as being the reference, you run into the problem that their voltage readings are not identical and can't both be exactly zero so what we do is take the mean of them and treat that as being zero voltage. The extent to which they differ from each other is allocated to each mastoid and they end up being mirror images of each other. See Dien (1998) for a treatment of reference site issues and how this all works.
From the ICA point of view, having two electrodes be exact mirror images is problematic because they are essentially redundant from an informational point of view (technically, the rank is no no longer full). ICA doesn't work properly when the rank is not full. The way to deal with it is to just drop one of the redundant electrodes, run the ICA, and then put it back in (still a mirror image). That way the data will still be mean mastoid referenced and the ICA will work properly. This is a legitimate operation because the dropped mastoid has been in effect defined as being simply the mirror image of the remaining mastoid.
I wouldn't use PCA first when using ICA to fix artifacts. You need all the dimensionality you can get when doing so. The way to think about this is that the number of ICA dimensions is limited to the number of variables (i.e., number of electrodes). If you have "only" 128 electrodes, then everything that is going on in the data (noise, artifacts, EEG, etc) has to fit into those 128 ICA components. The ICA components will necessarily end up representing multiple things. If you use PCA to reduce the subspace, then you reduce the number of possible ICA components even further. The dropped PCA factors will carry away some of the undesirable noise etc but is not the best way to do so as they will not even be rotated to simple structure. The more ICA components you can have, the less likely that "artifact" components that you delete will carry away with them real EEG variance.
Cheers!
Joe
On Dec 20, 2012, at 7:46 AM, Matt Craddock <matt.craddock at uni-leipzig.de> wrote:
> Hi Kristina,
>
> I've recently hit on similar behaviour (and in some cases even *worse*)
> with some of my datasets. For me, this seemed to be because of
> decomposing the data as if it were full rank (i.e. all the channels are
> approx linearly independent from each other) when it wasn't (there are
> also previous posts along these lines by Maximilien Chaumon - see
> http://sccn.ucsd.edu/pipermail/eeglablist/2011/004326.html). Looking in
> your specific case, I'd be quite cautious about removing those "noisy"
> components because they look to me like they also contain some genuine
> brain activity (though note that the two are basically identical, just
> opposite sign, which makes it look like the same problem as above).
>
> There are much more expert people than me on this list who can tell you
> much better why these noisy components happen, but what I can tell you
> is interpolation and rereferencing reduce the rank of the data, and this
> can, occasionally, make ICA do things like you're seeing. I'd suggest
> running PCA first to reduce the dimensions in the data accordingly. I've
> seen Arnaud Delorme suggest on another list you should avoid using PCA
> first, but I'm not sure that advice applies when the data is not full-rank.
>
> Now, if you run ICA through the menus in EEGLAB, it should detect that
> your data is not full rank, suggest an appropriate number of components
> to return, and then run PCA before ICA. However, if you run the ICA as
> part of a script, it'll probably be set up in such a way that it skips
> this step of suggesting an appropriate number of components and asking
> if it should reduce the data first. You may see a message along the
> lines of "fixing rank computation inconsistency probably because you're
> on linux 64 bit matlab"; this appears even if you're on Windows, and
> always selects the higher number of components returned by two different
> methods of calculating rank, which, in my experience, means it always
> decomposes the data as if it were full rank. So I'd suggest, if you're
> running ICA as part of your script, calculating the rank of your data
> and then passing that to the pop_runica function yourself.
>
> Cheers,
> Matt
>
> On 19/12/2012 10:26, Kristina Borgström wrote:
>>
>>> Hi,
>>> I have an issue regarding ICA for artifact correction that I really
>>> would appreciate some help with.
>>> Here is some background information: I have recorded child data (2
>>> years old) with EGI, 128 channels. Before export to EEGLab, the data
>>> has been band-pass filtered 1-30 Hz, epoched, clearly bad epochs (with
>>> more artifacts than just eye artifacts) were removed, and bad channels
>>> in the remaining epochs were interpolated. The data was rereferenced
>>> to average mastoid reference. I then imported into EEGlab, which
>>> treats the data as continuous, but has all the event information. I
>>> have then performed ICA in order to correct for eye artifacts.
>>>
>>
>> *The problem (please see the image files located at following links):*
>>> **https://dl.dropbox.com/u/7016081/DataPlots.jpg
>>
>> https://dl.dropbox.com/u/7016081/ICAComponents.jpg
>>>
>>> In (at least) two data files, besides some clear eye artifact
>>> components (components 1 & 11: blink; component 7: horizontal eye
>>> movement), the ICA also found two components that look like pure high
>>> frequency noise (components 2 & 3).
>>> When I remove the eye artifact components (1,7 & 11), the eye
>>> artifacts are in fact removed, BUT the data looks generally “noisier”,
>>> i.e. the channels overall are fuzzier (see the image “DataPlots” for
>>> comparisons). When I calculated individual averages with this data, it
>>> indeed contained massive amounts of high frequency noise that was not
>>> present in the averages where I did not use ICA at all but instead
>>> removed all epochs containing eye artifacts.
>>> I then continued and tested removing the “noise components” (2 & 3),
>>> and the data then looked like it did originally, minus the eye
>>> artifacts. It didn’t seem to have a major effect on the ERP components
>>> either, but of course removed the high frequency noise.
>>>
>>> *My main questions are:*How can noise be “added” to the data, after
>>> removal of certain components? How can I determine what type of noise
>>> components 2 & 3 consist of? I’ve looked at the frequency plots, but I
>>> don’t think it’s very clear. Can it be line noise, or EMG? The scalp
>>> topographies are very widespread, and EMG is usually more laterally
>>> located. Should it be ok to just remove these two components when they
>>> appear, or is there a risk that they contain cognitive components?
>>> Many thanks for any input you can give me!
>>> Regards,
>>> Kristina Borgström
>>> PhD Student
>>> Department of Psychology
>>> Lund University
>>> Sweden
>>> +46-46-2223638
>
> --
> Dr. Matt Craddock
>
> Post-doctoral researcher,
> Institute of Psychology,
> University of Leipzig,
> Seeburgstr. 14-20,
> 04103 Leipzig, Germany
> Phone: +49 341 973 95 44
> _______________________________________________
> 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
--------------------------------------------------------------------------------
Joseph Dien,
Senior Research Scientist
University of Maryland
E-mail: jdien07 at mac.com
Phone: 301-226-8848
Fax: 301-226-8811
http://joedien.com//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20121220/9612f92e/attachment.html>
More information about the eeglablist
mailing list