Back to the main page.
Bug 3137 - ft_databrowser: upper and lower channels outside of plotting area when cfg.viewmode='vertical'
| Status | CLOSED FIXED |
| Reported | 2016-06-07 00:56:00 +0200 |
| Modified | 2019-08-10 12:33:10 +0200 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | Roemer van der Meij |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 2314 |
| See also: |
Roemer van der Meij - 2016-06-07 00:56:10 +0200
Created attachment 794 problem This has been bugging me for a while, time to fix. See the picture attached. The upper and lower channels are no longer visible. Only when flatlining the scale do they become visible. When using very few channels (say, 10) the problem is somewhat less, but it's still very easy to cause the channels to 'clip'. Of course, this is not intended. The primary purpose of using the databrowser is to see the data, not not-see the data ;). So, an improvement is warranted. However, I'm unsure where to fix this and what the final behavior should be. So I'm also creating this bug partly as a discussion.
Roemer van der Meij - 2016-06-07 00:57:04 +0200
Created attachment 795 how a solution could look like
Roemer van der Meij - 2016-06-07 01:03:25 +0200
I attached another figure, showing what a solution could look like. (Hacked by adding 5 NaN channels at the top and 5 at the bottom). The only way to keep the top and bottom channels visible, is to give them more space. The amount of white space added should: 1) depend on the number of channels 2) depend on the current ylim? (i.e., white space not necessary with small ylim) 3) not depend on figure window size (just saying) 4) not depend on the scale of the data (too variable) Any input?
Roemer van der Meij - 2016-06-07 01:45:11 +0200
Currently, my best guess for a spot to fix this is adding white space to the 'local axis limits'. It's unpredictable however, how all the other operations of the monster are affected. At least, so far so good. If anyone would like to try it out, the following adds white space dependent on the number of channels being plotted. On line 1734, I changed this: % determine the total extent of all virtual axes relative to the real axes ax(1) = min(opt.laytime.pos(:,1) - opt.laytime.width/2); ax(2) = max(opt.laytime.pos(:,1) + opt.laytime.width/2); ax(3) = min(opt.laytime.pos(:,2) - opt.laytime.height/2); ax(4) = max(opt.laytime.pos(:,2) + opt.laytime.height/2); axis(ax) To this: % determine the total extent of all virtual axes relative to the real axes ax(1) = min(opt.laytime.pos(:,1) - opt.laytime.width/2); ax(2) = max(opt.laytime.pos(:,1) + opt.laytime.width/2); ax(3) = min(opt.laytime.pos(:,2) - opt.laytime.height/2); ax(4) = max(opt.laytime.pos(:,2) + opt.laytime.height/2); % add white space to bottom and top so channels are not out-of-axis for the majority if strcmp(cfg.viewmode,'vertical') % might also be use for viewmode = component! nchan = numel(cfg.channel); % add an equivalent of 2.5% of channel space to top, and to bottom wsfac = (nchan*0.025) * abs(mean(diff(opt.laytime.pos(:,2)))); ax(3) = ax(3) - wsfac; ax(4) = ax(4) + wsfac; end axis(ax) With 2.5% of 'channel space' added as white space, it seems the top and bottom channels are in the axis most of the time (depending on their particular variance obviously), and it scales appropriately with the number of channels on the screen.
Robert Oostenveld - 2016-06-07 09:29:26 +0200
I don't think that you'll ever come up with something that always works. Imagine displaying a trigger channel (which happens a lot with me, containing values of 1-1024) as part of the channels, it always is much larger than any other channel (which is 10^-12). I agree that some padding at the edges is desired. Let me try to come up with heuristics. - if a single channel, no padding. - if less than 10 channels, also no padding. - if 10 channels, 0.5 Nan-channel on each side - if 20 channels or more , 1 Nan-channel on each side I don't think there should be the reason to do ever more padding by default. Imagine the option cfg.verticalpadding = number, can be 'auto'. the padding would be specified in fractions/multiples of the layout height. It should be realized by changing the axes, not by adding something invisible to the figure (like nan channels).
Roemer van der Meij - 2016-06-07 21:43:42 +0200
Thanks! Good idea to do it via an option and dependent on cfg.channel. I did the following: - added cfg.verticalpadding, default = auto - padding is applied to viewmode = vertical, and component - padding is specified in proportion of the axis height - when padding = auto, the padding depends on nchan as follows: <=6 - no padding (the same cutoff as special axis ticks >6 <=10 - 1% of height to top, 1% to bottom >10 - 2% The 6 is convenient because it will add padding to viewmode = component, which defaults at 10 components per window. From the past, I remember I wanted some padding here as well. I didn't make it dependent on ylim. I think having consistent channel positions isin general more useful while scaling up and down. I've set the default to auto. Initially I was thinking of setting the default to 0 to gain some more experience, but I'm pretty satisfied with the way it works now. It's almost always helpful, and not unnatural/obtrusive when not required. Pull requested
Robert Oostenveld - 2016-06-08 09:10:08 +0200
(In reply to Roemer van der Meij from comment #5) thanks, I merged it.