Back to the main page.
Bug 1288 - ft_senstype does not recognize combined planar data correctly
| Status | CLOSED FIXED |
| Reported | 2012-01-25 11:59:00 +0100 |
| Modified | 2012-12-31 11:46:27 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Jörn M. Horschig - 2012-01-25 11:59:11 +0100
Problem is, combinedplanar data w/o defining a layout cannot be plotted, e.g. by ft_topoplot Reason is, ft_senstype checks data.grad, which was changed by megplanar to having twice the amount of channels (for dH and dV), and combineplanar does not combine the data.grad information again. ft_senstype just checks data.grad and sees "w00t many channels, must be planar", but then returns the grad-information. What follows is a classical "labels do not match" error in the plotting routine (sens labels have '_dH' and '_dV", which the data does not have anymore due to combineplanar)
Robert Oostenveld - 2012-01-25 12:31:09 +0100
should we consider this a fieldtrip error or a user error? In my impression, the best we can do is to provide the user with a more informative error message.
Jörn M. Horschig - 2012-01-25 12:34:37 +0100
Hmm... I would consider that when calling megplanar, freqanalysis, combineplanar, my data will be in a format that can be used by all FT functions. Also, the example I tried is from the plotting tutorial, which used to work some day.
Robert Oostenveld - 2012-01-25 15:25:37 +0100
your data is, but your layout might not. Computing layouts on the fly is a service to the user, but ideally 1) the user carefully handcrafts his own layout 2) selects one of the carefully handcrafted layouts in the template dir 3) constructs one with ft_prepare_layout and carefully checks 4 (worst case) uses one that was created on the fly The topography is used in interpretation, and an incorrect topography (e.g. electrodes below the ears, but all channels in a lay file automatically getting scaled into a unit-diameter sphere with the ears on the rim of that sphere) might cause misinterpretation. The consequences of the 2D interpolation in the topoplot function are not to be taken lightly. ---------- My feeling is that this issue is a recurring one. In the past combineplanar would remove the grad structure, as it is invalid. People did not like that, because that makes it more difficult to define neighbours. So it was decided to keep the grad. Then as methods improved, it also became possible to compute planar leadfields. So the grad had to be adjusted on in megplanar. Now you are saying that you don't like the adjusted gradiometer, but atht you want the original one again. Let's discuss this at a FT meeting when JM is around.
Jan-Mathijs Schoffelen - 2012-01-25 15:48:42 +0100
I guess that a creation of the layout 'on-the-fly' should look at the chanpos and label fields in the gradiometer description. Although the planar combination invalidates the tra-matrix, a meaningful chanpos and label can replace the planar-channel description. Should we consider throwing away the coilpos/coilori/tra from the gradiometer description upon planar-combination, and replacing the chanpos and label with consistent values?
Robert Oostenveld - 2012-01-25 16:06:02 +0100
(In reply to comment #4) that is a good though!
Jan-Mathijs Schoffelen - 2012-02-10 11:22:46 +0100
fixed on revision 5272
Diego Lozano Soldevilla - 2012-05-04 08:35:32 +0200
Created attachment 262 tooplot90degrees_fliped
Diego Lozano Soldevilla - 2012-05-04 08:43:04 +0200
(In reply to comment #7) I run the "Event related averaging and planar gradient" tutorial for next week toolkit with today's Fieldtrip and 20120501 versions and I found something weird. When you run ft_combineplanar the result is shifted 90 degrees (see previous attachment). After revision 5272 is still going. Is it a different problem or is it still the same as this bug? Diego
Robert Oostenveld - 2012-05-04 12:35:25 +0200
(In reply to comment #8) This is the code that does not run correctly, whereas adding cfg.layout=CTF151 ensures that the figure is correct. The code below should be included in the inspect/test script. cfg = []; subplot(121) cfg.xlim = [0.3 0.5]; cfg.zlim = 'maxmin'; cfg.colorbar = 'yes'; ft_topoplotER(cfg,avgFIC) colorbar subplot(122) cfg.zlim = 'maxabs'; ft_topoplotER(cfg,avgFICplanarComb)
Robert Oostenveld - 2012-05-09 10:11:27 +0200
I had a look at it. The 90 degree rotation is because ft_senstype returns unknown and consequently x remains x and y remains y, whereas normally the x-axis points to the nose in the sensors but to the left in the figure. The unknown senstype is because the combined planar does not have coilpos and tra, i.e. it is not a grad. I have solved the problem. The solution is mainly in ft_senstype, which in this case should simply look at the channel labels. I have extended the test script with some explicit assertions that error in case the problem happens. The test script now works fine, also in the figure that it creates it looks fine. manzana> svn commit forward/ft_senstype.m test/test_bug1288.m Sending forward/ft_senstype.m Sending test/test_bug1288.m Transmitting file data .. Committed revision 5753.
Jörn M. Horschig - 2012-06-05 15:33:35 +0200
sorry for re-opening while fixing bug 1477 I thought it'd be wise to re-check the test-script from bug 1315. However, I cannot call the test-script now, because of an error. The code that produces this error can be found in test_bug1315.mat, but basically it is: >> load test_bug1315.mat >> // define neighbours >> erf_planar = ft_megplanar(cfg, data); ??? Error using ==> ft_checkdata at 371 This function requires ctf151_planar, ctf275_planar, neuromag122, neuromag306, bti248_planar, bti148_planar, itab153_planar, yokogawa160_planar, yokogawa64_planar or yokogawa440_planar data as input, but you are giving ctf275 data. The data that is read in has only 38 channels, the grad still has all (and obviously, erf_planar.grad.label is not updated to be in planar representation)
Robert Oostenveld - 2012-06-08 14:07:55 +0200
see also bug #1458, it might be related.
Eelke Spaak - 2012-11-29 08:51:28 +0100
*** Bug 1858 has been marked as a duplicate of this bug. ***
Eelke Spaak - 2012-11-29 08:52:41 +0100
see bug 1858 (related but very similar issue), has been fixed.