[Eeglablist] how to select channels for back-projection of ERP

Scott Makeig smakeig at ucsd.edu
Mon Aug 17 16:23:31 PDT 2015


Elizabeth -

ICs whose epoch-averaged activity time courses are ~orthogonal to some
scalp channel ERP may likely have projections with opposite polarities to
channel subsets (e.g., have scalp maps with both red and blue projection
weights).

Remember that the sum of the IC projections to a channel is the channel
value -- either in the continuous data or in data averages.  There was an
EEGLAB function (chantopo() ?) I wrote to show the largest IC projections
to a given channel epoch. It did not get into the EEGLAB GUI, but is likely
still in the EEGLAB misc_funcs folder...

Scott Makeig

On Tue, Aug 11, 2015 at 7:22 AM, Elizabeth Milne <e.milne at sheffield.ac.uk>
wrote:

> Dear Scott,
> Thanks - this is helpful. Dividing the IC activation by the RMS value of
> the its scalp map gives me very similar, but not identical, data to the IC
> activation [using the function *rms* in matlab].
>
> In the majority of data sets and ICs I have looked at, the time-course of
> the RMS-projected activation is similar (albeit different magnitude) to the
> time-course of the forward-projected activation of the same IC. In these
> cases the RMS-projected activations are easy to interpret in the context of
> looking for characteristic VEP deflections such as P1 / N1. However, in a
> small number of cases, the time-course of the RMS-projected IC activation
> is orthogonal to the time-course of the forward-projected IC activation
>  i.e. the component appears inverted. In these cases, identifying P1 as a
> positive peak and N1 as a negative peak is no longer possible, although it
> is clear that these deflections are in the data.
>
> In these cases is it legitimate to subtract the RMS-projected activation
> from 0 in order to invert it? Previously I was taking Makoto's advice and
> forward-projecting the IC activation to the channel that it projected to
> most strongly in order to ascertain the 'true' polarity of the activation.
> However, given your comments above it sounds like working with the
> RMS-projected IC activations is the preferable route - if I can be
> confident of the polarity of this activation.
>
> Thanks for your input,
> Elizabeth
>
>
>
>
>
> On 10 August 2015 at 16:48, Scott Makeig <smakeig at ucsd.edu> wrote:
>
>> Elizabeth and all -
>>
>> Makoto is correct that the term 'back projection' of an IC to the scalp
>> can be viewed also (and more fundamentally)  as a *forward* projection
>> from cortical source to the scalp sensors.
>>
>> I blieve the only EEG phenomena of interest are the source data
>> activities (e.g., IC activations) -- the source projections to the scalp
>> channels (whose sum we record with scalp electrodes) are essentially
>> epiphenomena (more or less arbitrary source sums and differences, in
>> themselves of no fundamental interest).
>>
>> Now, the most correct unit of measurement for cortical sources is source*
>> current density per cortical area *(for example, per mm^2).  However, to
>> convert scalp measurements into that unit one needs a high-resolution
>> electrical forward head model (sources to scalp electrodes) and an ideal
>> inverse model (source scalp projection map to cortical source patch).  The
>> former must include accurate values for tissue conductivities within the
>> individual subject, not something we currently have access to (though see
>> below).
>>
>> Therefore, the most reliable unit of measurement we have for the activity
>> of an identified source in scalp-recorded data is  'RMS uV' -- the root
>> mean-square average projection from the source to the scalp. Even this has
>> ambiguity -- To the *whole* scalp, even places where we did not place
>> electrodes??   A simple alternative is to measure IC activity (unaveraged
>> or averaged) as the RMS (mean) projection of the source to the actual scalp
>> electrodes:
>>
>> e.g., If IC is the index of an IC in an EEG data structure.
>>
>>  * >> RMS_uv(IC) = EEG.icaact(IC ) / RMS(EEG.icawinv(IC));*  % divide
>> the IC activation by
>>
>>                          % the RMS value of its scalp map
>>
>> Unfortunately, the function *RMS()* I used in the meta-code above is not
>> a Matlab function (by that name)... I am away from a Matlab installation at
>> present and forget the actual function call.
>>
>> It may be that this normalization (making *RMS(EEG.icawinv) = ones()* )
>> is already performed in the default output of runica / binica / AMICA - To
>> be safe, however, run the meta-code above explicitly or test the equality
>> above ...
>>
>> All units of measurement for IC activations (activities) should be
>> labelled 'RMS uV/chan' -- I will work with Arno and Ramon to see that this
>> is corrected in the current functions.
>>
>> Note: This removes the problem, 'Which channel projection is the best one
>> to use to measure the contribution of a source to the scalp (ERP or raw)
>> data?'
>>
>> Scott Makeig
>>
>> p.s. To see which ICs contribute most strongly, learn to use and
>> interpret *envtopo()* -- called in the EEGLAB GUI by '*Plot > Component
>> ERPs > With Scalp Maps*'.  Makoto has recently supervised building of a
>> plug-in to perform this function at the STUDY level (here the question is,
>> 'Which IC clusters contribute most strongly to the grand mean ERP or ERP
>> difference?')
>>
>> p.p.s  Zeynep Akalin Acar and I have developed a new method for
>> estimating skull conductivity from the EEG data (given a subject MR head
>> image allowing development of an individual electrical forward head model).
>> Our report on this should be accepted soon - more details then or at the
>> upcoming EEGLAB workshop in UK...
>>
>> On Mon, Aug 3, 2015 at 6:09 PM, Makoto Miyakoshi <mmiyakoshi at ucsd.edu>
>> wrote:
>>
>>> Dear Elizabeth,
>>>
>>> A projection from ICs to channels is a 'forward projection'. We've been
>>> using the word 'backprojection' in the wrong way, so I corrected it (at
>>> least in my functions).
>>>
>>> In ICA, the polarity of map and time-series signal can be flipped by
>>> applying -1 to the both. This is a fundamental uncertainty.
>>>
>>> > If I want to use this, or any other, IC to measure the amplitude /
>>> latency of particular ERP deflections it is necessary to know which is the
>>> correct channel to choose for back-projection. However, I am unsure as to
>>> how to make this decision objectively.
>>>
>>> I wrote pvaftopo() plugin for this purpose
>>> http://sccn.ucsd.edu/wiki/Plugin_list_process
>>> pvaf is a new concept Scott proposed nearly 20 years ago which is
>>>
>>> percent variance accounted for (pvaf) = 100-100*var(all_data -
>>> selected_ICs)/var(all_data)
>>>
>>> We'll publish IEEE EMBC conference proceedings soon for this year about
>>> the study-level envtopo and pvaf, so you may want to refer to the paper
>>> once it's published (Lee et al., IEEE EMBC conf proc 2015)
>>>
>>> Pick up the channel that is closest to the peak in the scalp maps and
>>> you can choose the 'most accounted' channel objectively.
>>>
>>> I'm happy that there is finally a user asking for this plugin!
>>>
>>> Makoto
>>>
>>> On Fri, Jul 31, 2015 at 2:13 PM, Elizabeth Milne <
>>> e.milne at sheffield.ac.uk> wrote:
>>>
>>>> Dear EEGLAB team,
>>>> I have a question about resolving the "true" polarity of IC ERPs by
>>>> back-projecting to channel data. Using erpimage, I have obtained the ERP of
>>>> an IC, but the polarity is different (orthogonal) when back-projecting to
>>>> different channels. In another example from a different IC, the polarity of
>>>> the ERP does not change, but the amplitude of the signal is different
>>>> depending on which channel is selected for back-projection.
>>>>
>>>> If I want to use this, or any other, IC to measure the amplitude /
>>>> latency of particular ERP deflections it is necessary to know which is the
>>>> correct channel to choose for back-projection. However, I am unsure as to
>>>> how to make this decision objectively. Are there particular features that I
>>>> should look at to make this decision more systematic, i.e. dipole
>>>> projection? % power accounted for?
>>>>
>>>> If anyone can offer advice, or point out errors in my understanding I'd
>>>> be very grateful.
>>>>
>>>> Many thanks,
>>>> Elizabeth
>>>>
>>>> --
>>>> Elizabeth Milne
>>>> Reader in Cognitive Neuroscience
>>>> University of Sheffield
>>>> Western Bank
>>>> Sheffield
>>>> S10 2TN
>>>>
>>>> +44 (0) 114 222 6558
>>>>
>>>> http://www.autismresearchlab.group.shef.ac.uk/
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> Scott Makeig, Research Scientist and Director, Swartz Center for
>> Computational Neuroscience, Institute for Neural Computation, University of
>> California San Diego, La Jolla CA 92093-0961, http://sccn.ucsd.edu/~scott
>>
>
>
>
> --
> Elizabeth Milne
> Reader in Cognitive Neuroscience
> University of Sheffield
> Western Bank
> Sheffield
> S10 2TN
>
> +44 (0) 114 222 6558
>
> http://www.autismresearchlab.group.shef.ac.uk/
>



-- 
Scott Makeig, Research Scientist and Director, Swartz Center for
Computational Neuroscience, Institute for Neural Computation, University of
California San Diego, La Jolla CA 92093-0961, http://sccn.ucsd.edu/~scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20150817/38d8c23f/attachment.html>


More information about the eeglablist mailing list