Back to the main page.
Bug 2625 - ft_freqanalysis seems to ignore cfg.channel
| Status | ASSIGNED |
| Reported | 2014-06-27 13:57:00 +0200 |
| Modified | 2014-08-12 13:40:26 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | Macintosh |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | Diego Lozano Soldevilla |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=2053http://bugzilla.fcdonders.nl/show_bug.cgi?id=2051http://bugzilla.fcdonders.nl/show_bug.cgi?id=2596http://bugzilla.fcdonders.nl/show_bug.cgi?id=2054http://bugzilla/show_bug.cgi?id=2646http://bugzilla.fcdonders.nl/show_bug.cgi?id=2668http://bugzilla.fcdonders.nl/show_bug.cgi?id=2673 |
Ian Andolina - 2014-06-27 13:57:00 +0200
cfg = []; cfg.keeptrials = 'yes'; cfg.output = 'pow'; cfg.channel = 'LFP10'; ... out = ft_freqanalysis(cfg, datain); I have 4 channels data in datain, and when I select 1 channel using cfg.channel and pass that to ft_freqanalysis, what gets returned is 4 channels of data (out.label is a 4 cell string, out.powspctrm has 'rpt_chan_freq_time' with chan = 4). This has changed recently, before out was the selected channel's data only.... This is using the latest (as of today) master branch via github...
Ian Andolina - 2014-06-27 14:22:51 +0200
A little bit of digging shows ft_freqanalysis@228 rollback_provenance is where cfg.channel gets reset from a single channel back to my 4 channels...
Robert Oostenveld - 2014-06-27 14:49:50 +0200
(In reply to Ian Andolina from comment #1) thanks for the report and pointing to the possible location where it goes wrong. I do currently not understand why there is not also tmpcfg.channel = cfg.channel; prior to ft_selectdata, i.e. have ft_selectdata also handle channel selection. We will make a small test script to figure it out.
Diego Lozano Soldevilla - 2014-07-01 14:28:29 +0200
(In reply to Robert Oostenveld from comment #2) The problem is that rollback_provenance fills the input cfg with the data.cfg configuration options. If data.cfg.channel = 'all' and cfg.channel=1, then line 76 will update the cfg.channel='all AFAIK rollback_provenance should track rather than change cfg options right?
Diego Lozano Soldevilla - 2014-07-02 13:39:53 +0200
(In reply to Diego Lozano Soldevilla from comment #3) all data selections should be done at once using ft_selectdata and calling rollback_provenance. Multiple ft_selecdata calls wih rollback_provenance updates cfgs
Diego Lozano Soldevilla - 2014-07-02 15:50:59 +0200
(In reply to Diego Lozano Soldevilla from comment #4) It's important to document other potential cases on where the call of rollback_provenance could be more complicated to resolve (at least elegantly). Robert pointed us an example in ft_sourceinterpolate: tmpcfg = keepfields(cfg, {'downsample'}); orgcfg.parameter = cfg.parameter; tmpcfg.parameter = 'anatomy'; anatomical = ft_volumedownsample(tmpcfg, anatomical); [cfg, anatomical] = rollback_provenance(cfg, anatomical); cfg.parameter = orgcfg.parameter; % restore the original parameter, it should not be anatomy Here the original cfg parameter should be stored and put it back afterwards. I'll check all rollback_provenance cases to look for exceptions: grep rollback_provenance *.m | grep -v ':%' ft_freqanalysis.m:[cfg, data] = rollback_provenance(cfg, data); ft_math.m:[cfg, varargin{:}] = rollback_provenance(cfg, varargin{:}); ft_prepare_mesh.m: [cfg, mri] = rollback_provenance(cfg, mri); ft_sourcegrandaverage.m:[cfg, varargin{:}] = rollback_provenance(cfg, varargin{:}); ft_sourceinterpolate.m: [cfg, anatomical] = rollback_provenance(cfg, anatomical); ft_sourceplot.m: [cfg, data] = rollback_provenance(cfg, data); ft_timelockanalysis.m: [cfg, data] = rollback_provenance(cfg, data); ft_volumenormalise.m: [cfg, mri] = rollback_provenance(cfg, mri); ft_volumereslice.m: [cfg, mri] = rollback_provenance(cfg, mri); ft_volumesegment.m: [cfg, mri] = rollback_provenance(cfg, mri); ft_volumewrite.m: [cfg, volume] = rollback_provenance(cfg, volume);
Diego Lozano Soldevilla - 2014-07-02 15:55:55 +0200
(In reply to Diego Lozano Soldevilla from comment #5) More explicit with: bash-4.1$ grep -B 1 rollback_provenance *.m | grep -v ':%' ft_freqanalysis.m-% restore the provenance information ft_freqanalysis.m:[cfg, data] = rollback_provenance(cfg, data); -- ft_math.m-% restore the provenance information ft_math.m:[cfg, varargin{:}] = rollback_provenance(cfg, varargin{:}); -- ft_prepare_mesh.m- mri = ft_volumedownsample(tmpcfg, mri); ft_prepare_mesh.m: [cfg, mri] = rollback_provenance(cfg, mri); -- ft_sourcegrandaverage.m-[varargin{:}] = ft_selectdata(tmpcfg, varargin{:}); ft_sourcegrandaverage.m:[cfg, varargin{:}] = rollback_provenance(cfg, varargin{:}); -- ft_sourceinterpolate.m- anatomical = ft_volumedownsample(tmpcfg, anatomical); ft_sourceinterpolate.m: [cfg, anatomical] = rollback_provenance(cfg, anatomical); -- ft_sourceplot.m- data = ft_volumedownsample(tmpcfg, data); ft_sourceplot.m: [cfg, data] = rollback_provenance(cfg, data); -- ft_timelockanalysis.m- data = ft_selectdata(tmpcfg, data); ft_timelockanalysis.m: [cfg, data] = rollback_provenance(cfg, data); -- ft_volumenormalise.m- mri = ft_volumedownsample(tmpcfg, mri); ft_volumenormalise.m: [cfg, mri] = rollback_provenance(cfg, mri); -- ft_volumereslice.m- mri = ft_volumedownsample(tmpcfg, mri); ft_volumereslice.m: [cfg, mri] = rollback_provenance(cfg, mri); -- ft_volumesegment.m- mri = ft_volumedownsample(tmpcfg, mri); ft_volumesegment.m: [cfg, mri] = rollback_provenance(cfg, mri); -- ft_volumewrite.m- volume = ft_volumedownsample(tmpcfg, volume); ft_volumewrite.m: [cfg, volume] = rollback_provenance(cfg, volume);
Robert Oostenveld - 2014-07-03 17:36:34 +0200
when discussing this with Diego, I searched and found the potentially affected files using this linux code: mac011> grep -l ft_channelselection `grep -l ft_selectdata.*cfg *.m` ft_channelrepair.m ft_componentanalysis.m ft_connectivityanalysis.m ft_connectivityplot.m ft_denoise_pca.m ft_denoise_synthetic.m ft_freqanalysis.m ft_freqdescriptives.m ft_freqstatistics.m ft_megplanar.m ft_megrealign.m ft_multiplotER.m ft_preprocessing.m ft_rejectvisual.m ft_removetemplateartifact.m ft_singleplotER.m ft_timelockanalysis.m Note that not all are using rollback_provenance yet. E.g. ft_channelrepair.m uses selectdata the old way. These are the ones that also call rollback_provenance: mac011> grep -l ft_channelselection `grep -l ft_selectdata.*cfg *.m` > out mac011> grep -l rollback_provenance `cat out` ft_freqanalysis.m ft_freqstatistics.m -> this is locally modified on my computer ft_timelockanalysis.m
Robert Oostenveld - 2014-07-03 17:37:02 +0200
(In reply to Robert Oostenveld from comment #7) note that the introduction of rollback_provenance in ft_timelockanalysis was done here https://code.google.com/p/fieldtrip/source/detail?r=9617
Robert Oostenveld - 2014-07-03 18:11:33 +0200
mac011> svn commit ft_timelockanalysis.m Sending ft_timelockanalysis.m Transmitting file data . Committed revision 9691.
Robert Oostenveld - 2014-07-09 17:45:19 +0200
I just solved the still open issue for ft_freqanalysis. I noticed that it was still failing because of test_bug1409 giving an error due to the mismatch between channels in the lead field (after ft_prepare_leadfield->151) and channels in the freq data (after ft_freqanalysis->183, including refs). mac011> svn commit ft_freqanalysis.m utilities/ Sending ft_freqanalysis.m Adding utilities/copyfields.m Sending utilities/keepfields.m Sending utilities/removefields.m Transmitting file data .... Committed revision 9717.
Diego Lozano Soldevilla - 2014-07-16 12:20:44 +0200
(In reply to Robert Oostenveld from comment #10) rollback_provenance updated as in ft_freqanalysis Sending ft_timelockanalysis.m Transmitting file data . Committed revision 9735.