[Eeglablist] Channel interpolation before ICA vs. channel interpolation following ICA
marius.s.klug at gmail.com
Sat Aug 5 05:46:30 PDT 2017
Hi Dan and Tarik,
I'm far from an expert but I've read a lot about exactly this (complex
topic, though nothing published to my knowledge) and came to the conclusion
that we delete and interpolate channels, then re-reference to average
reference, then reject bad timeframes and then run AMICA with reduced rank
afterwards. My reasoning is as follows:
For a start: One should always at least delete bad channels before running
AMICA, since it drastically improves the decomposition. Also visually scan
for artifacts in the time-domain and reject them helps improving the
decomposition to a great degree.
Now, ideally interpolating after AMICA would be preferred, because
spherical interpolation introduces small nonlinearities into the data set
which AMICA can't account for since it's a linear model. Making up new data
to my understanding wouldn't be an issue per se, IF one enters a reduced
rank into the AMICA decomposition, and the interpolation is linear (I might
be wrong here).
However this comes with several complications:
a) This essentially means that one has to re-interpolate each time one
backprojects the component level into the source level. Also I've heard
that EEGLAB throws errors every now and then if you work with those kind of
data sets, even though one could create wrapper functions oneself.
b) We want to perform visual cleaning of strong artifacts before running
AMICA, but for this we want to average reference the data first. For
average referencing, one should interpolate bad channels first, because the
center of the ideal sphere covered by the electrodes would otherwise be
skewed away from the deleted channels.
-> After careful examination of decompositions with and without
interpolation before ICA, I did not see any relevant differences and
because of this and the pragmatic reasons above, I chose this processing
flow to be most efficient for our purposes. Also, since there would be no
projection from the full data set to the component level, source
localization might prove difficult later on. I am not sure about this,
though, because I've never gone that far with interpolating after AMICA.
I would highly appreciate a comment of the experts on my approach, though,
because by now I just tried to piece everything together myself and am not
entirely sure if this is the best way to go. If not, I should know! :-)
2017-07-26 1:25 GMT+02:00 Tarik S Bel-Bahar <tarikbelbahar at gmail.com>:
> Hi Dan, some quick thoughts below, we should hear something from the
> experts soon!
> I think the current majorly held belief and recommendation from eeglab
> experts is that one should drop bad channels before ICA so as to let
> it do it's job better, giving it a better chance of focusing on neural
> ICs. Other implementations, perhaps via amica or gift-eeg, might
> handle or treat the data in special ways that obviate the need to do
> Don't think I've not seen this compared empirically in published
> papers. And it would be touch to collect and clearly compare results
> across multiple extant papers using interpolation before or after ICA.
> One could run simulations on some larger datasets. The field (and
> eeglab) seems to be needing more data-based empirical consolidation on
> a range of truisms (e.g., recent notes of the need for new
> publications related to high/low density arrays, clinical vs. research
> questions, the nature, if any, of ICA effects on phase metrics,
> Dropping channels before ICA and not interpolating before ICA might
> not allow for full/accurate representation of the spatial data.
> My understanding is that the interpolation before ICA, however, is not
> a good idea for ICA because it essentially "makes up" new channel
> information. Perhaps biasing effects could depend on the method of
> Interpolating channels before ICA does seem to work ok too often in my
> experience, though I prefer the interpolate-after method.
> I would say the biasing effects on reconstructed eeg data from which
> only artifact ICs have been removed depend on how many channels have
> been removed (many or few?). I also tend to use post-ICA interpolation
> for such analyses.
> Note that messages in eeglab are sometimes cryptic or late to be updated.
> On Mon, Jul 24, 2017 at 10:55 AM, Daniel Roberts <drobertc at gmu.edu> wrote:
> > A question that has frequently come up on this list is whether to perform
> > bad channel interpolation before or after ICA. Of course if you
> > prior to ICA it is necessary to indicate the reduced rank of the data to
> > ICA algorithm. In various threads it is recommended to interpolate before
> > ICA, or alternatively, interpolate after ICA. I’m curious if anyone is
> > of any empirical data on which method is preferable, or the potential
> > detriments of one method or the other.
> > I noticed that EEGLAB generates a warning / error when interpolating then
> > average referencing following ICA: ““Error: some channels not used for
> > decomposition are used for rereferencing the ICA decomposition has been
> > removed” which would seem to suggest interpolating prior to ICA if an
> > average reference is required. However, this warning seems to only remove
> > ICA decomposition but maintains the channel space data. So perhaps it is
> > an issue if ICA was used only for artifact removal and the rest of the
> > analysis will be in channel space.
> > Thanks for any thoughts on the issue,
> > Dan
> > _______________________________________________
> > Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
> > To unsubscribe, send an empty email to eeglablist-unsubscribe at sccn.
> > For digest mode, send an email with the subject "set digest mime" to
> > eeglablist-request at sccn.ucsd.edu
> Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
> To unsubscribe, send an empty email to eeglablist-unsubscribe at sccn.
> For digest mode, send an email with the subject "set digest mime" to
> eeglablist-request at sccn.ucsd.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the eeglablist