[Eeglablist] (Updated) Huge challenge: Dipoles uncorrelated with components

[Makoto Miyakoshi]

Dear Curtis,

This seems a common failure that coregistration between the forward head
model and your electrode locations is erroneously set to be 90 degrees
rotated.
I updated my Wiki page to describe the meaning of head model coregistration.

https://sccn.ucsd.edu/wiki/Makoto%27s_preprocessing_pipeline#Head_model_coregistration


Makoto

On Tue, Jun 30, 2020 at 11:26 PM Curtis Bingham <cnbingham at gmail.com> wrote:

> (UPDATE with links to images, and additional information in UPDATES
> section below, as requested by kind souls who responded privately)
>
>
>
> Why are my dipoles completely uncorrelated with independent components?
>
> In this image (
> https://urldefense.com/v3/__https://imgur.com/wlHSs0X__;!!Mih3wA!W92KXdh7blda6IzoYtjvGjRu6xaTeySMzUMtOXyW_F1oJlZEaDjOLADtJxU5Hp4eJLIK6g$
> ), you can see that the dipoles representing the components are almost
> entirely uncorrelated with the independent components.
> The dipole for IC 7 is the only dipole properly correlated with the
> underlying component
> Dipoles for IC 2 and IC 9 are in opposite hemispheres from the components
> The remaining dipoles are a LONG way away from their components.
>
>
> What would cause this extreme separation of dipole from independent
> component?
>
>
>
> The EDF file is generated by Neurofield Q20 and processed as follows:
> import, channel locations (10-20 or 10-05 locs file makes no difference)
> average reference, remove baseline, high and low-pass filter, runica,
> ICLabel, and delete rejected components.
>
>
>
> DIPFIT is run with Template BEM (MNI), no co-reg, autofit (RV%=100)
>
> There is a warning in each pass saying “use cfg.headmodel instead of
> cfg.hdmfile” but that is hardcoded in the dipfit code.
>
>
>
> In this image (
> https://urldefense.com/v3/__https://imgur.com/P8CvQA3__;!!Mih3wA!W92KXdh7blda6IzoYtjvGjRu6xaTeySMzUMtOXyW_F1oJlZEaDjOLADtJxU5Hp5QVil1qw$
> ) you can see the DIPFIT plot with the RV% and TAL numbers:
>
>
>
>
>
> I’ve used the same EDF dataset and tested eeglab 2019_0 against 2019_1,
> and within each of those trials, have tested DIPFIT 3.0 and 3.3, but
> haven’t been able to find any combination wherein the dipoles actually
> matched the components, most likely ruling out a version mismatch.
>
>
>
> What are we doing wrong? Can anyone shed some light on what might be
> happening and how we can attempt to further diagnose?
>
>
>
> Updates:
>
> Someone suggested plotting the channels to ensure that channels aren’t
> being transposed somehow. It appears that the channels are being properly
> referenced and sequenced.
>
> This image (
> https://urldefense.com/v3/__https://imgur.com/ByfaSYi__;!!Mih3wA!W92KXdh7blda6IzoYtjvGjRu6xaTeySMzUMtOXyW_F1oJlZEaDjOLADtJxU5Hp69f1htbg$
> ) shows the layout of the channels. Ignoring the pre- and post-fix labels,
> these appear to be in the correct order and placement in the 10-20 system.
> These are obtained in the channel locations dialog from the
> eeglab2019_1/sample_locs/Standard-10-20-Cap19.ced file that I’ve merely
> changed the labels so I don’t have to manually edit every channel name.
>
>
>
> Without going too far down a rabbit hole, when I plot the channel layout
> obtained from the plugins/dipfit/standard_BEM/elec/standard_1005.elc, I get
> a plot where the ears (T3/T4) are too low, and the Fp1/Fp2 are too far
> forward and off the head (
> https://urldefense.com/v3/__https://imgur.com/dlp8KEw__;!!Mih3wA!W92KXdh7blda6IzoYtjvGjRu6xaTeySMzUMtOXyW_F1oJlZEaDjOLADtJxU5Hp52heQLlw$
> ). Is that expected behavior?
>
>
>
>
>
>  Suggestions welcome!
>
>
>
> Best regards,
>
> Curtis
>
>
>
> _______________________________________________
> 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