Back to the main page.
Bug 1887 - extend ft_connectivityanalysis with measures for time-domain and component data
| Status | ASSIGNED |
| Reported | 2012-12-12 17:26:00 +0100 |
| Modified | 2014-05-21 22:00:23 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 enhancement |
| Assigned to: | Diego Lozano Soldevilla |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=2518http://bugzilla.fcdonders.nl/show_bug.cgi?id=2559http://bugzilla.fcdonders.nl/show_bug.cgi?id=2539 |
Robert Oostenveld - 2012-12-12 17:26:27 +0100
The following test scripts should be considered in all updates to the function mac001> grep -l ft_connectivity *.m test_bug1425.m test_bug1677.m test_bug46.m test_bug538.m test_ft_connectivity_powcorr_ortho.m test_ft_connectivityanalysis.m test_ft_topoplotER.m test_tutorial_coherence.m test_tutorial_connectivity.m test_tutorial_connectivity2.m test_tutorial_connectivity3.m
Robert Oostenveld - 2012-12-12 17:28:08 +0100
I have cleaned up the whitespace in the function, this should not have any effect on the functionality. mac001> svn commit ft_connectivityanalysis.m Sending ft_connectivityanalysis.m Transmitting file data . Committed revision 7158.
Diego Lozano Soldevilla - 2013-01-10 18:24:08 +0100
Created attachment 398 comp data type
Diego Lozano Soldevilla - 2013-01-10 18:24:56 +0100
(In reply to comment #2) (In reply to comment #1) Hi Robert, I think there's a bug in ft_checkdata but I'm not sure. For component data as this one: data = cfg: [1x1 struct] fsample: 300 label: {274x1 cell} time: {[1x1193 double] [1x1244 double] [1x1148 double]} trial: {[274x1193 double] [274x1244 double] [274x1148 double]} trialinfo: [3x11 double] unmixing: [273x273 double] sampleinfo: [3x2 double] topo: [273x273 double] topolabel: {273x1 cell} if you use ft_checkdata to evaluate specific data type: data = ft_checkdata(data, 'datatype', {'raw' 'timelock'}); the expected output should be data with raw structure as specified in ft_datatype_raw. However I got comp-like structures. Line 265 in ft_checkdata should be: if okflag (instead of if ~okflag) to allow data conversion. Even correcting it, the output is a data structure that combines raw and timelock subfields: data = cfg: [1x1 struct] fsample: 300 label: {274x1 cell} time: [1x1244 double] trial: [3x274x1244 double] trialinfo: [3x11 double] unmixing: [273x273 double] sampleinfo: [3x2 double] dimord: 'rpt_chan_time' - Cheap solution: Make specific data type calls in ft_checkdata; never combine datatypes as above {'raw' 'timelock'} because if you enter component data it will be flaged as iscomp=1; israw=1 and as a consequence there're 2 eleseif statements that make the raw and timelock subfields combination: line 304 elseif isequal(dtype(iCell), {'raw'}) && iscomp line 310 elseif isequal(dtype(iCell), {'timelock'}) && iscomp I attach you a comp data with 3 trials to play
Robert Oostenveld - 2013-01-11 10:47:03 +0100
I noticed that the data is all nan and that it is not a comp structure, since it contains no topo+unmixing+topolabel. But I can do the following >> for i=1:10 data.trial{i} = randn(size(data.trial{i})); end >> cfg = []; >> cfg.method = 'pca'; >> comp = ft_componentanalysis(cfg, data) the input is raw data with 32 channels and 10 trials selecting 32 channels baseline correcting data scaling data with 1 over 1.154641 concatenating data.......... concatenated data matrix size 32x10000 starting decomposition using pca the call to "ft_componentanalysis" took 1 seconds and required the additional allocation of an estimated 6 MB comp = fsample: 1000 time: {[1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double]} trial: {1x10 cell} topo: [32x32 double] unmixing: [32x32 double] label: {32x1 cell} topolabel: {32x1 cell} sampleinfo: [10x2 double] cfg: [1x1 struct] and then I have >> ft_datatype(data) ans = raw >> ft_datatype(comp) ans = comp
Robert Oostenveld - 2013-01-11 10:48:08 +0100
(In reply to comment #4) Ah, I notice that you mention a 3-trial comp structure, whereas the attached one is a 10-trial data structure. So I guess you just mixed them up. No worries.
Diego Lozano Soldevilla - 2013-01-11 10:50:07 +0100
(In reply to comment #5) Sorry I saved the wrong variable...
Robert Oostenveld - 2013-01-11 10:54:23 +0100
From ft_datatype_comp: % The only difference to the raw data structure is that the comp structure % contains the additional fields unmixing, topo and topolabel. See % FT_DATATYPE_RAW for further details. So a comp structure complies with the rules of FT_DATATYPE_RAW and FT_DATATYPE_COMP, it is both. But the example you point to >> ft_checkdata(comp, 'datatype', {'timelock'}) ans = fsample: 1000 time: [1x1000 double] trial: [10x32x1000 double] unmixing: [32x32 double] label: {32x1 cell} sampleinfo: [10x2 double] cfg: [1x1 struct] topo: [32x32 double] topolabel: {32x1 cell} dimord: 'rpt_chan_time' returns a mixed representation of timelock (not raw!) and comp. This is a problem with the following >> ft_datatype(ft_checkdata(comp, 'datatype', {'timelock'})) ans = comp as it should have been timelock. We don't want comp and timelock (or freq) to get mixed. So in this case the topo+topolabel+unmixing should be stripped off.
Robert Oostenveld - 2013-01-11 11:16:15 +0100
(In reply to comment #7) ... the question is whether it should also be stripped off if you want to have raw data. Raw and comp data are processed the same way (i.e. data.trial and data.label are used in the computations) and if the output is again raw, it is desirable to keep the topo details. e.g. ft_resampledata(cfg, comp) should return a comp formatted structure, as the algorithmic operation on the timeseries does not change the topo/unmixing. So the comp details should not be stripped of when converting comp->raw, but should be stripped of when converting comp->timelock. I changed it such that >> ft_checkdata(comp, 'datatype', 'raw') ans = fsample: 1000 time: {[1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double] [1x1000 double]} trial: {1x10 cell} unmixing: [32x32 double] label: {32x1 cell} sampleinfo: [10x2 double] cfg: [1x1 struct] topo: [32x32 double] topolabel: {32x1 cell} >> ft_checkdata(comp, 'datatype', 'timelock') ans = fsample: 1000 time: [1x1000 double] trial: [10x32x1000 double] label: {32x1 cell} sampleinfo: [10x2 double] cfg: [1x1 struct] dimord: 'rpt_chan_time' mac001> svn commit Sending utilities/ft_checkdata.m Transmitting file data . Committed revision 7295.
Diego Lozano Soldevilla - 2013-01-11 12:06:31 +0100
(In reply to comment #8) Following the logic, then we should delete the ft_checkdata subfunction comp2raw that is executed when the input data is comp and you want raw (line 312) given that it deletes topo and topolabel (don't know why it doesn't delete the unmixing subfield). I think that with your implementation the following cases are irrelevant: elseif isequal(dtype(iCell), {'raw'}) && iscomp (line 312) elseif isequal(dtype(iCell), {'timelock'}) && iscomp (line 318)
Robert Oostenveld - 2013-01-11 15:38:13 +0100
I have just added a test script. mac001> svn commit Adding test/test_bug1887.m Transmitting file data . Committed revision 7298. And in reply to comment #9: I now see that there is some double code that I overlooked. I fixed that, and added a comment to the code clarifying the similarity between comp and raw. mac001> svn commit utilities/ Sending utilities/ft_checkdata.m Transmitting file data . Committed revision 7299.
Robert Oostenveld - 2014-05-21 11:27:03 +0200
this bug has migrated away from the initial purpose into "comp" handling. The comp aspects are somehow related to bug #2539 and were discussed in the FT meeting of 14 May 2014. I have reorganised the implementation for structures that have a combination of comp with raw/timeloc/freq. There is now explicit handling of raw+comp, timelock+comp and freq+comp. In case datatype=comp, the timeseries fields are being removed by ft_checkdata. Idem, in case of datatype=raw/timelock/freq, the comp fields are being removed. roboos@mentat001> svn commit Sending ft_databrowser.m Sending ft_examplefunction.m Sending ft_freqanalysis.m Sending ft_interpolatenan.m Sending ft_rejectcomponent.m Sending ft_timelockanalysis.m Sending ft_topoplotIC.m Sending private/topoplot_common.m Sending test/test_bug1887.m Sending utilities/ft_checkdata.m Sending utilities/ft_datatype.m Sending utilities/ft_datatype_comp.m Sending utilities/ft_selectdata_old.m Transmitting file data ............. Committed revision 9564. I suspect that there are now some functions that will not pass the comp details from the (raw) input to the processed output. I will follow this up.