MRG: Take mean of nirs channels that are too close for topoplot

[rob-luke]

Reference issue

Alternative approach to #7410 as suggested by @larsoner

What does this implement/fix?

If nirs channels are too close for the topoplot to represent then those channels are combined by taking the mean.

Additional information

Initial attempt. No tests yet, just looking for feedback to see if I am on the right path. But this works on my data.

[larsoner]

Yep this looks like about what I would expect to be required. Left some comments inline

[larsoner]

Also I would recommend git grep _merge_grad_data'ing to see where else you might need to change things.

[codecov]

Codecov Report

Merging #7414 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           master    #7414    +/-   ##
========================================
  Coverage   90.03%   90.04%            
========================================
  Files         454      454            
  Lines       81400    82297   +897     
  Branches    13001    13020    +19     
========================================
+ Hits        73288    74103   +815     
- Misses       5267     5369   +102     
+ Partials     2845     2825    -20     

[rob-luke]

Also I would recommend git grep _merge_grad_data'ing to see where else you might need to change things.

So it appears _merge_grad_data is also used in get_peak, plot_projs_topomap, _plot_ica_topomap, plot_ica_components, plot_tfr_topomap, plot_epochs_psd_topomap and like a dozen helper functions.

So I think I will tackle each topic in turn to keep things bite sized. I will look at psd_topomap, ica, tfr, then projs in subsequent PRs. But first I will take and upload a short test measurement with overlapping channels so that I can make useful tests. @larsoner is this plan ok?

[larsoner]

So I think I will tackle each topic in turn to keep things bite sized.

Sounds reasonable to me. Another approach might be to make _merge_grad_data a more general _merge_channel_data that handles both channel types, but based on its arguments I think this approach will not be straightforward (even if it ends up the way we go after you change a few of these code paths over). +1 for working in bite sized increments and we can see if patterns are repeated and can refactored.

[rob-luke]

#7057

[rob-luke]

@agramfort and @larsoner could you please review. This is working nicely for me.

[larsoner]

LGTM, thanks @rob-luke !

[larsoner]

For linked lists the builtin list actually works quite well and probably faster than np.append, but it won't make any appreciable difference here