ENH: plot_topo layout creation

[larsoner]

It seems like we keep hitting issues with topo scaling confusing people. I think we probably shouldn't change where (0., 0., 0.) is in any given channel layout, and instead ensure that our internal layouts are actually in head coordinates. I wonder if we could also just assume a head is e.g. 90 cm. That would make subselections of electrodes appear correct. A normalize=True (default) | False argument in functions that do such topologies could do it.

@jaeilepp WDYT?

[jaeilepp]

Yeah, that sounds like a good idea. I was already experimenting with this, but it seems that _check_outlines may require some tweaking to make it work well with topomaps.

[larsoner]

This would fix #3814

[jaeilepp]

I'm thinking that maybe the head coordinates should only apply when the layout is custom made. After all, the locations are only used in layout plots and they're not actual sensor locations. I noticed that vectorview locations for instance are not centered to 0. So some kind of adjustment would be needed anyway.

[agramfort]

no opinion

[larsoner]

You mean the horizontal offset? I think this could actually be correct. If you set dev_head_t to identity does it go away? If so it indicates that the head was shifted to the side relative to the sensors, making this a feature not a bug.

…

On Feb 22, 2017 5:07 AM, "Alexandre Gramfort" ***@***.***> wrote: no opinion — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3987 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACQZXixYfX3GGL6AxBJrS2ABzmBav087ks5rfAjOgaJpZM4MAho3> .

[jaeilepp]

Why would it go away? These are just the sensor locations from the layout file.

[larsoner]

Then we should probably apply dev_head_t to get sensor locations in head coordinates. Then the spatial relationship between the head and the sensors, at least is terms of the center, will be correct.

[jaeilepp]

But these are static locations from the layout file. Why would it help to transform them?

[larsoner]

If we are plotting sensors on top of a head, it would be best to plot the sensors with the same (or at
least similar) geometrical relationship they actually had with the head during the recording. For MEG sensors this means using dev_head_t to get them to head coordinates.

[larsoner]

... so maybe not for plot_topo (and even then I'm not sure), but for plot_topomap it seems like we should always do things in head coordinates. Concretely the proposal would be:

1. Convert MEG sensors to head coords
2. Assume (0, 0, 0) is meaningful: don't re-center
3. Assume the head is about 90cm in diameter: don't rescale sensor positions
4. Any built-in EEG layouts that don't give "sensor locations in head coordinates" should be put through a function that effectively makes them be in head coordinates

This will give us much more realistic geometry than our current procedure, which is just to center based on extrema and scale everything to hit the boundaries.

[jaeilepp]

Any built-in EEG layouts that don't give "sensor locations in head coordinates" should be put through a function that effectively makes them be in head coordinates

Even some of our built-in MEG layouts don't give head coordinates (like KIT-AD). I'm not sure it's worth the effort to change this. After all, in most cases our layouts work fine and the change would require overhaul of all the plotting functions that use layouts. Also, topomaps use layouts so it might be dangerous to change this.

[larsoner]

I agree it would be a big change. Such a process should make all of the plots more accurately represent the head to sensor relationship, though. Actually we'd really want to skip the layout entirely and use the channel positions from info. In the case of MEG sensors, we'd just need to apply dev_head_t. Maybe we could add it as a separate mode?

[jaeilepp]

The layouts should still be used at least for topo-plots since the sensor triplets have identical positions.

[larsoner]

Ahh right. Forgot about that :)

And I guess there is some logic to the "unwrapping" transformation we normally do, since it's just one way (of many possibilities) to do a projection of spherical data.

Maybe just disabling norm and/or centering is enough