Back to the main page.
Bug 2574 - ft_plot_topo: added imagesc+saturation for saving nicely vectorized topo's
| Status | CLOSED FIXED |
| Reported | 2014-05-12 16:06:00 +0200 |
| Modified | 2016-03-03 14:35:01 +0100 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 enhancement |
| Assigned to: | Roemer van der Meij |
| URL: | |
| Tags: | |
| Depends on: | 3000 |
| Blocks: | |
| See also: | http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2492 |
Roemer van der Meij - 2014-05-12 16:06:42 +0200
Hey all, I made this bug report to inform you about an experimental option in ft_plot_topo.m, that will plot a topo using imagesc and saturation masking. For saving pretty figures in vector format :). Defaults are unchanged. Let's discuss it over here (I might not join to many future meetings due to thesis-binging ;)). I added some random folks who might find this interesting. The option is accessible in ft_topoplotER/TFR via: cfg.style = 'straight_imsat' and 'both_imsat'. I made the names explicitly ugly cause I couldn't decide on a proper name and to make it sound experimental/temporary. So, two questions: 1) Neat? 2) If answer to 1) is yes, how shall we name the styles? cfg.maskstyle comes to mind, but it's a bit of a misnomer here. In ft_plot_topo NaNs are 'masked' by simply not being plotted as surface/contour-patch elements. (additionally, 'actual' masking using opacity is no longer possible, this has been disabled for some time apparently). It is implemented in ft_plot_topo.m as two additional styles: 'imsat' and 'imsatiso' (add contour lines), in the same naming scheme as the other styles. Apart from the above, it was necessary to add 'clim' as an additional input option to use saturation masking (as after the image is plotted using manipulated HSV values, the color axis is fixed).
Jörn M. Horschig - 2014-05-12 16:24:54 +0200
Didn't know that it was not possible to get vector gfx of topos. I used to save as .eps and Illustrator could take over from there. Why again is your fix necessary/better? Are you coincidentally here on Wednesday to discuss this?
Roemer van der Meij - 2014-05-12 16:47:53 +0200
Really? I tried saving as eps and svg, but the resulting topo in illustrator is very nasty (all tiny patches have visible and non-removable edges between them, probably not perfectly aligned). This is with with style = 'straight' though, if I plot with 'fill' (or something, filled iso lines) the result is neat and clean. Did you do that by any chance? Otherwise, this is just weird (using r2012b). Attached is what I get if I save as eps old style, and then open in illustrator (cs5), old and new style. The 'fix' is avoiding the plotting of surface patches (causing the ill-aligned vertices looking horrible), but just by plotting it with imagesc (with saturation masking for removing things outside the circle).
Roemer van der Meij - 2014-05-12 16:48:06 +0200
Really? I tried saving as eps and svg, but the resulting topo in illustrator is very nasty (all tiny patches have visible and non-removable edges between them, probably not perfectly aligned). This is with with style = 'straight' though, if I plot with 'fill' (or something, filled iso lines) the result is neat and clean. Did you do that by any chance? Otherwise, this is just weird (using r2012b). Attached is what I get if I save as eps old style, and then open in illustrator (cs5), old and new style. The 'fix' is avoiding the plotting of surface patches (causing the ill-aligned vertices looking horrible), but just by plotting it with imagesc (with saturation masking for removing things outside the circle).
Roemer van der Meij - 2014-05-12 16:48:40 +0200
Created attachment 623 ewww!
Roemer van der Meij - 2014-05-12 16:49:04 +0200
Created attachment 624 ewww and better
Robert Oostenveld - 2014-05-12 16:53:14 +0200
How does it compare to the similar(?) functionality in ft_plot_matrix?
Roemer van der Meij - 2014-05-12 17:03:32 +0200
(In reply to Robert Oostenveld from comment #6) Actually, it's mostly identical (ctrl+c/v). To be honest, I cannot see right now why we ever went the route to plot topo's as surfaces, instead of just images (like ft_plot_matrix). Although perhaps the option to set the shading to interp is perhaps why (only possible with patch objects). But for some reason it 'shrinks' the topo towards the lower right corner of the outline, and doesn't really work currently. And the same effect, of smooth color transitions, can be achieved by increasing cfg.gridscale... In principle, the two functions (ft_plot_matrix and ft_plot_topo) could share most (as far as I can see) plotting code, and differ mostly in data handling plus some extra's (contour lines, outline of the head, etc) I could totally be missing something of course.
Robert Oostenveld - 2014-05-13 11:19:29 +0200
Regarding the opacity masking: the use of maskimagetmp around line 240 was commented out by Jan-Mathijs in rev 2527 (as shown with svn blame) 2527 jansch %if exist('maskimagetmp') 2527 jansch % set(h, 'facealpha', 'flat'); 2527 jansch % set(h, 'alphadatamapping', 'scaled'); 2527 jansch % set(h, 'alphadata', maskimagetmp); 2527 jansch %end See https://code.google.com/p/fieldtrip/source/detail?r=2527 The comment suggests that it was only a change to x and y ("enforce x and y coordinates of channels to be column vector"). The use of Nan instead of opacity has to do with exporting to EPS and with renderer settings. I made some changes to the code to make the structure more clear, removing some old unused snippets. There should not be any functional changes. I also extended the documentation mac011> svn commit Sending ft_plot_topo.m Sending test/test_ft_plot_topo.m Transmitting file data .. Committed revision 9510. have a look at test_ft_plot_topo. The shading option is an interesting one (flat by default, but interp is much nicer).
Robert Oostenveld - 2014-05-13 11:23:03 +0200
Created attachment 625 topo with saturation x = randn(30,1); y = randn(30,1); % make something round between 0 and 1 val = -sqrt(x.^2 + y.^2); val = val-min(val); val = val./max(val); ft_plot_topo(x, y, val, 'datmask', val, 'style', 'imsat', 'clim', [0 1]);
Robert Oostenveld - 2014-05-13 11:25:02 +0200
(In reply to Robert Oostenveld from comment #9) I think the code/documentation is unclear with respect to "masking" (which I consider a binary/boolean operation) and "highlighting" (which can be implemented by emphasising some parts, or partially hiding other parts, e.g. using opacity/saturation).
Roemer van der Meij - 2014-05-13 11:38:49 +0200
I can't seem to find an test_ft_plot_topo.m, did you build it just now and forgot to commit? There are issues atm btw with non-binary saturation masking (in ft_plot_matrix/topo, same code), but binary masking should work fine. I agree we are a bit unclear now, it would be best to make a distinction between masking/highlighting (or some other terms).
Robert Oostenveld - 2014-05-13 12:08:17 +0200
(In reply to Roemer van der Meij from comment #11) it is in the fieldtrip/plotting/test subdirectory.
Robert Oostenveld - 2015-11-04 15:50:40 +0100
(In reply to Roemer van der Meij from comment #11) did you already have a chance to improve on test_ft_plot_topo?
Robert Oostenveld - 2015-11-04 17:58:42 +0100
(In reply to Robert Oostenveld from comment #13) could issue 2492 perhaps also be resolved by this?
Roemer van der Meij - 2015-11-05 19:33:25 +0100
(In reply to Robert Oostenveld from comment #14) It totally can! I implemented it for this purpose actually, I actually would have guessed I submitted both bugs at the same time. Looking into this bug now
Roemer van der Meij - 2015-11-05 23:34:05 +0100
Added bug 3000 to the dependency list, which this depends on. Short story: the answer to your question is actually no. And it never truly could (implement graded highlighting). It's just the cases in which this was obvious were rare (see bug 3000). I expanded test_ft_plot_topo with some additional test cases/
Roemer van der Meij - 2016-03-03 14:33:55 +0100
Closing time.