Back to the main page.
Bug 2588 - ft_databrowser identifies wrong channel in butterfly mode
| Status | CLOSED FIXED |
| Reported | 2014-05-22 12:03:00 +0200 |
| Modified | 2014-07-15 17:25:07 +0200 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P5 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=2591 |
Carolina Sanchez - 2014-05-22 12:03:53 +0200
when browsing neuromag306 data with ft_databrowser in butterfly mode, identifying a channel using the "identify" button fails. instead of the correct channel, a different one is selected. the choice seems to be constant (not random) when the point that is clicked in the UI is kept constant.
Robert Oostenveld - 2014-05-22 14:45:57 +0200
Hi Caroline, Are you plotting all 306 channels, or only 204 (or 102) of a similar channel type? Could you try the code below? --------------------- data = []; for i=1:10 data.label{i} = num2str(i); end data.trial{1} = zeros(10,300); data.time{1} = (1:300)/300; for i=1:10 sel = ((10*(i-1)+1):(10*i)) + i*10; data.trial{1}(i,sel) = 1; end cfg = []; ft_databrowser(cfg, data); --------------------- for me it works fine, but I realise that if I click in between two "blocks", channel 10 gets selected. I consider that to be correct. However, if the amount of data that is plotted (number of data points along the time axis) is larger than the number of pixels on your screen, I can imagine this causing unexpected interactions. Can you try to reproduce the problem with a large screen compared to the number of data points, i.e. basically zoom in such that there are for certain fewer time points than pixels?
Robert Oostenveld - 2014-05-22 14:47:16 +0200
mac011> svn commit Adding inspect_bug2588.m Transmitting file data . Committed revision 9579.
Thomas Hartmann - 2014-05-22 15:54:51 +0200
(In reply to Robert Oostenveld from comment #1) hey robert, thanks a lot for the quick response. we just tried it out here and it behaves exactly as you said. maybe the problem is that the system is not "tolerant" enough? because practically what you are saying is, that if i miss, the last channel gets selected. or am i wrong here? would it be possible to have the system detect a miss and just do nothing? would it be possible to increase/adjust the tolerance? best, thomas
Robert Oostenveld - 2014-05-22 16:13:57 +0200
if channels have the same distance to the clicked-point (along the vertical direction), it seems that the last one that was plotted gets selected. In my case, clicking at latency where all channels are 0, the last one is as good as anyone else. You could argue that in the ambiguous case, no channel should be selected. That is a change that could be made to the code. But I suspect that the problem is more related to the mismatch between the data representation (samples) and how it is displayed on the screen (pixels). E.g. consider >> plot(randn(10000,1)) it looks perfectly fine at a glance. But I know that it gets displayed like this >> get(gcf, 'Position') ans = 1260 642 560 420 i.e. the figure has 560 pixels horizontally which, after subtracting the margins of the figure, means that there are about horizontal 450 pixels along which 10000 data points are being distributed. At each pixel I only have one vertical line (randomly going up or down), so the figure technically consists of 450 vertical lines representing 10000 data points. That means that 9550 data points actually cannot be visually represented in the window. It is similar to the visual artefacts you get with a = zeros(2,300); a(1,:) = 1; plot(a(:)); axis tight a = zeros(2,230); a(1,:) = 1; plot(a(:)); axis tight (you might have to play with the numbers to see the striping patterns). Here you get an aliasing effect: the data has higher frequency that the screen is able to sample. So I wonder whether it is something where tolerance would actually help. Could you reproduce the undesired behaviour in your data with a debug/keyboard stop at line 1363 in ft_databrowser, immediately after input? Then you can check (stepping through the code one line at a time) what val2nearestchan is making of it and whether that is consistent given the data at hand.
Thomas Hartmann - 2014-05-23 09:46:29 +0200
(In reply to Robert Oostenveld from comment #4) ok, i did some digging. it seems that you would have to click "inside" of the curve to get the channel. this is because the val2nearestchan.m only does a vertical search, taking the channel with the closest value, but does not do a horizontal search. so, you have some tolerance for the y-axis but non for the x-axis. i do not know if this is intended. however, knowing this, we can instruct people accordingly. i would like to suggest to include a sentence about this behavior in the documentation.
Robert Oostenveld - 2014-05-23 11:09:44 +0200
it would make sense that the search would also be along the horizontal direction. But the reason (I suspect) for Ingrid (who wrote this section) not doing this is that the units are not comparable (Tesla versus seconds). So horizontal and vertical difference are not trivial to combine. It is easier if you think about it in pixels, but that is presently not how the code works due to the nice abstraction that matlab has regarding the plots. Please suggest something that you would like to see added to the help.
Thomas Hartmann - 2014-05-23 11:36:40 +0200
(In reply to Robert Oostenveld from comment #6) robert, i agree 100%. adapting the code to also allow horizontal tolerance would be great but given the current status and the fact that the workaround is very trivial, i agree that it is not top priority. i did a pull request on github for that purpose. it is only a suggestion so feel free to alter it in any way you like....
Thomas Hartmann - 2014-05-23 12:31:27 +0200
ok, it seems that this problem is twofold as it is also a problem when both magnetometers and gradiometers are plotted because, in summary, the plotted data is scaled while the identification runs on the unscaled data. i opend a new bug for this: http://bugzilla.fcdonders.nl/show_bug.cgi?id=2591
Robert Oostenveld - 2014-05-23 13:22:14 +0200
(In reply to Thomas Hartmann from comment #7) mac011> svn commit ft_databrowser.m Sending ft_databrowser.m Transmitting file data . Committed revision 9588. Added a parapraph concerning the possibly unintuitive behavior of ft_databrowser when identifying a channel. See https://github.com/fieldtrip/fieldtrip/pull/41 and here.
Robert Oostenveld - 2014-05-23 13:24:26 +0200
I guess this resolves it.