Back to the main page.
Bug 1486 - improve artifact detection and rejection for unstable acquisition systems
| Status | NEW |
| Reported | 2012-05-23 09:34:00 +0200 |
| Modified | 2014-10-07 11:12:17 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P4 enhancement |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2012-05-23 09:34:07 +0200
The following is from an email that was still in my todo box.... Better make it a joint todo item. It pertains to bad-channel handling, which is important for less stable MEG systems but also for EEG measurements in infants. TODO: discuss in FT meeting and come up with a good plan. ----- On 17 Feb 2012, at 11:41, Weisz, Nathan wrote: the mix of different sensor types is causing some headache already at the preprocessing level (don't want to think about the sources for now). the problem with our neuromag system at least is that it is very unstable (even with the Konstanz BTI, one bad channel usually was the bad guy for weeks / months). this creates enormous problems for sensor level stats, since this means that if not somehow taken care of efficiently plenty of sensors would be lost. as i understand it, your suggestion basically involves rerunning the rejectvisual and preprocessing multiple times. while of course this would work (and I did think of it) i would find a field in a data structure with a flag whether the channel was marked as bad or not as more efficient. but perhaps i am totally mistaken. so my home made solution at the moment is to add following lines of code to the part where ft_rejectvisual checks the input to cfg.keepchannel (empty at the moment in the official release, at least the one of a week ago): case 'yes' % keep all channels, also when they are not selected %HACK NATHAN: aim ... when running rejectvisual on grads and mags %separately with "keepchannel" to keep track of "good" channels if ~isfield(data,'numrejections') data.numrejections = 1; else data.numrejections = data.numrejections + 1; end %if isfield if ~isfield(data,'chansel') data.chansel=chansel; else data.chansel=data.chansel+chansel; end i agree that the code may be pretty ugly. however by this means (a vector of 1 and 0 for good and bad channel respectively) i can a) remove bad channels for visualization purposes of artefacts, b) keep the channels however to interpolate them in order not to loose too many for stats, c) know which ones to dump for source analysis (cfg.channel=data.channel(find(data.chansel == 1)); or 2 depending on the rounds of rejections). this would save me a couple of steps in the preprocessing flow. for the channels marked as bad we are currently looking at ways to interpolate. i know that Elekta has some magic software solutions but i would prefer not to use them as long as i can (we have good shielding and are quite distant from major noise sources). i hope i was not totally confusing. i would really like to stick to a solution in the standard fieldtrip release as much as possible instead of using hacked versions, since these hacked versions may not work after some fieldtrip upgrades. is there something wrong about including such a 'flag' solution in the official version? btw, talking about ft_rejectvisual, we have encountered the problem that the window displaying the trials does not rescale after removing an extreme outlying trial. i am not aware of posts on the fieldtrip list, so i was wondering whether this is a known issue or whether it may be specific to our data.
Jörn M. Horschig - 2012-06-20 15:38:23 +0200
to hook up on this, I just implemented spherical spline interpolation for ft_channelrepair (bug 634), which might give better interpolated data. The method is based on Perrin et al. 1989, the implementation is done by Jason Farquhar (i.e. should be fast and correct) Also, for ft_channelrepair it is possible to give a list of trials to be interpolated, i.e. for each channel only a number of trials could interpolated. In addition it might be wise to add a cfg.channel field to ft_channelrepair such that magnetometers will not be interpolated by gradiometers or any other creepy stuff.
Robert Oostenveld - 2012-06-21 10:31:19 +0200
(In reply to comment #1) It should be explained on the http://fieldtrip.fcdonders.nl/tutorial/artifacts page as a 3rd method (i.e. 1=reject, 2=remove, 3=interpolate). I would expect (consistent with other methods) cfg.trial=[1 3 5] to result in an output with only 3 trials. How to deal with trial selection and explaining to users how data should be fused back again after doing channelrepair? Or should we just interpret cfg.trial differently here?
Robert Oostenveld - 2014-10-07 10:19:07 +0200
Hi Stephen, This is something we addressed last week in the NatMEG workshop. How should we go about documenting this in general? There is ft_rejectvisual, in combination with ismember etc. Should we make an example script that demonstrates it?