Back to the main page.
Bug 1959 - ft_senstype doesn't detect the appropriate grad type in comp data
| Status | ASSIGNED |
| Reported | 2013-01-25 17:37:00 +0100 |
| Modified | 2013-02-19 10:26:17 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 1806 |
| See also: |
Diego Lozano Soldevilla - 2013-01-25 17:37:35 +0100
ft_senstype detects grad types using ft_senslable. In component data for ctf275, the labels are name by "component001" resulting in a grad.type='ctf'. Then, after IC rejection the grad type make a crash when ft_megplanar is called: the input is raw data with 273 channels and 364 trials Error using ft_checkdata (line 409) This function requires ctf151, ctf275, bti148, bti248, itab153, yokogawa160 or yokogawa64 data as input, but you are giving ctf data. Error in ft_megplanar (line 107) data = ft_checkdata(data, 'datatype', {'raw' 'freq'}, 'feedback', 'yes', 'hassampleinfo', 'yes', 'ismeg', 'yes', 'senstype', {'ctf151', 'ctf275', 'bti148', 'bti248', 'itab153', 'yokogawa160', 'yokoga Similar to Comment 1 here http://bugzilla.fcdonders.nl/show_bug.cgi?id=1414 Potential solution: When I call ft_prepare_neighbours(cfg3{2,1,1}, meg2); the grad is recognized Trying to load sensor neighbours from a template Estimating sensor type of data to determine the layout filename Data is of sensor type 'ctf275' Successfully loaded neighbour structure from ctf275_neighb.mat there are on average 7.3 neighbours per channel the call to "ft_prepare_neighbours" took 1 seconds and required the additional allocation of an estimated 0 MB I'll find a way to update the grad.type
Diego Lozano Soldevilla - 2013-01-31 11:55:10 +0100
(In reply to comment #0) I know where the problem is but I'm not sure about the expected behavior of ft_rejectcomponent. If I reject certain component using comp and meg as inputs, the grad.type is correctly detected cfg = []; cfg.component = component; meg2 = ft_rejectcomponent(cfg,comp,meg); meg2.grad ans = balance: [1x1 struct] chanori: [301x3 double] chanpos: [301x3 double] chantype: {301x1 cell} chanunit: {301x1 cell} coilori: [594x3 double] coilpos: [594x3 double] label: {301x1 cell} tra: [301x594 double] type: 'ctf275' unit: 'cm' If I use the comp alone (as in the tutorial http://fieldtrip.fcdonders.nl/example/use_independent_component_analysis_ica_to_remove_eog_artifacts?s[]=ft&s[]=rejectcomponent), the grad.type is only cft and you've troubles with megplanar later on: cfg = []; cfg.component = component; meg2 = ft_rejectcomponent(cfg,comp); meg2.grad ans = balance: [1x1 struct] chanori: [301x3 double] chanpos: [301x3 double] coilori: [594x3 double] coilpos: [594x3 double] label: {301x1 cell} tra: [301x594 double] type: 'ctf' unit: 'cm' I think that the expected behavior regarding grad.type should be ctf275 given that the meg2.lables are the MEG sensors, not component numbers. QUESTION: Should the data output be the same using ft_rejectcomponent is the two ways: ft_rejectcomponent(cfg,comp) VS ft_rejectcomponent(cfg,comp,meg);? If yes, I know where to dig
Johanna - 2013-02-06 14:38:34 +0100
The .tra fields might not be the same. If so, then I think only the .tra from the 3-input way is correct, not the 2-input way. Please also see bug 1443.
Diego Lozano Soldevilla - 2013-02-06 14:39:48 +0100
(In reply to comment #2) I'll check it and I'll keep you updated
Diego Lozano Soldevilla - 2013-02-06 17:05:55 +0100
Created attachment 420 toy data It seems to me that the tra matrix is almost equal (error of e-14). You can load the toy data I attached load bugdata.mat cfg = []; cfg.component = component; meg2 = ft_rejectcomponent(cfg,ica); cfg = []; cfg.component = component; meg3 = ft_rejectcomponent(cfg,ica,meg); figure;imagesc(meg2.grad.tra-meg3.grad.tra);
Johanna - 2013-02-06 17:41:56 +0100
I'm not sure that's always the case. I just created test_bug1443 and compare the output .tra fields. They both have a norm of 1.4e5, but a norm of the diff is 1.4. Thus, the error is on the order of 1e-5. Is that acceptable or significant? The figure plotted in my test function shows that the errors occur on the diagonals. Perhaps the initial problem I refered to in bug 1443 was solved, when bug 1249 was solved? (this was the bug refering to the topograd).
Diego Lozano Soldevilla - 2013-02-15 17:07:07 +0100
(In reply to comment #5) Using grad.balance structure to detect sens.type in comp data type Sending ft_senstype.m Transmitting file data . Committed revision 7480. test script is coming to test meg and other datatypes (eeg,lfp...)
Robert Oostenveld - 2013-02-19 10:15:04 +0100
it has been decided in one of the recent FT meetings that ft_senstype of comp data should return the original type of sensor array. This is best implemented by using private/undobalancing. Noite that this affects the test script test_bug1806 for bug # 1806.
Robert Oostenveld - 2013-02-19 10:20:38 +0100
roboos@mentat001> svn commit test/test_bug1806.m Sending test/test_bug1806.m Transmitting file data . Committed revision 7494. updated the test script to the latest insights and decisions, comp ctf151 data should be detected as ctf151, not as comp