Back to the main page.
Bug 2028 - ft_channelselection needs to be reconsidered
| Status | NEW |
| Reported | 2013-03-05 12:30:00 +0100 |
| Modified | 2016-06-03 20:08:27 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 201520273135 |
| See also: |
Robert Oostenveld - 2013-03-05 12:30:14 +0100
There are expectations of users that cfg.channel=something works in general, but in some cases the magic fails to do its work and users end up with imperfect selections. ft_channelselection works by using lists of channel names. The developments in ft_chantype, ft_senstype have been implemented much later than ft_channelselection. If we were to reimplement cfg.channel, how would we do it?
Jörn M. Horschig - 2013-03-05 13:48:05 +0100
I would tear things apart a bit. At the moment I dislike that channel can be a list of channels but also some higher level,predefined set. cfg.channel for low-level string matching and cfg.chantype/cfg.senstype for selecting at a higher level of hierachy. This would require, however, senstype and chantype to be unambigious and revisited (not necessarily revised) And also, personally, I'd like use regular expressions, but that's for advanced users (note that currently, only one wildcard works)
Eelke Spaak - 2013-03-05 13:52:54 +0100
(In reply to comment #1) I actually quite like the mix of exact label matches and more advanced group-matching :) cfg.channel = {'MEG', '-MLO31'} is pretty neat. But I totally agree that wildcard handling should be more generic. As of now, it seems not only simple wildcards sometimes don't work. If I recall correctly, 'M*O*' does not match anything on CTF275.
Jörn M. Horschig - 2013-03-05 16:00:48 +0100
yep, only a single * works the discussion about what's neat and what's not should maybe continued in a group meeting :)
Jörn M. Horschig - 2015-02-05 16:31:48 +0100
while working on bug 2753, the wildcard issue got into my way again. There is a simple solution using the 'regexptranslate' function with the 'wildcard' option. E.g., if I want the string '*7??nm?' to be translated into a regular expression, I can type >> regexptranslate('wildcard','*7??nm?') ans = .*7..nm. Can this safely be implemented in ft_channelselection and replace the if-statements in the channel-loop by //concatenate '$' to indicate end-of-word rexp = sprintf('%s%s', regexptranslate('wildcard',channel{i}), '$'); datachannel(~cellfun(@isempty, regexp(datachannel, rexp))) ? This at least gives me the list of channels I would like and I am pretty confident that this will work like a charm. test_ft_channelselection would need to be extended to test this, but I do not have access from here to the test data
Robert Oostenveld - 2015-02-05 17:05:48 +0100
Hi Jorn, Sounds like a good plan to me! If you can give an explicit patch in bugzilla (i.e. description of what needs to be changed in what), then we can apply it next Wednesday in the bug binge. It would be a nice exercise for the two new people in the team. Robert
Jörn M. Horschig - 2015-02-06 09:46:05 +0100
Created attachment 699 patch for ft_channelselection okidoki ;) I attached the patch, which includes this change. During my tests I also encountered another bug, which is also fixed with this patch. Namely, if channels to be excluded were not at the end of the desired variable, the function crashed with Matrix index is out of range for deletion. Error in ft_channelselection (line 342) channel([ This was because of the deletion of entries in the channel variable when channels are excluded and the subsequent incoherence with labelreg, which was based on the initial channel variable.