Back to the main page.
Bug 2461 - 2014b, Handle Graphics 2 and FieldTrip
| Status | REOPENED |
| Reported | 2014-01-29 14:58:00 +0100 |
| Modified | 2015-07-15 13:46:34 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | All |
| Operating System: | All |
| Importance: | P5 minor |
| Assigned to: | Jörn M. Horschig |
| URL: | http://www.mathworks.nl/products/matlab/matlab-graphics/index.html |
| Tags: | |
| Depends on: | 27592760 |
| Blocks: | 2930 |
| See also: |
Ian Andolina - 2014-01-29 14:58:20 +0100
This is somewhat speculative and pre-emptive, but Matlab has been developing the next generation of graphics systems called handle graphics 2. Testing FT using HG2 most plots seems to initiate except the databrowser, but lots of plots error out before completion due to a simple bug caused by the following use of gcf: set(gcf, 'Name', sprintf('%d: %s: %s', gcf, funcname, dataname)); gcf now returns an object which sprintf chokes on. You can use: cf=gcf; set(gcf, 'Name', sprintf('%d: %s: %s', num, funcname, dataname)); and if strcmpi(class(gcf),'double') to check if gcf returns a HG1 (true) or HG2 (false) object. To run HG2 matlab use: > matlab -hgVersion 2 & http://undocumentedmatlab.com/blog/hg2-update/
Ian Andolina - 2014-01-29 15:00:08 +0100
sorry: cf=gcf; set(gcf, 'Name', sprintf('%d: %s: %s', cf.Number, funcname, dataname));
Ian Andolina - 2014-01-29 15:34:45 +0100
A more elegant way is to cast the object to a double, works for HG1 or HG2 without issue: set(gcf, 'Name', sprintf('%d: %s: %s', double(gcf), funcname, dataname));
Ian Andolina - 2014-06-27 15:27:01 +0200
Matlab 2014b will set HG2 as the default (about time!!!), this is a significant change but FT still seems to work OK with the changes I made here (I don't use the GUIs that much). There is a GUI migration tool I can try with the fieldtrip directory.
Jörn M. Horschig - 2014-06-30 09:42:27 +0200
Hi Ian, thanks for letting us know. I'll bring this up in the next FT meeting so that we can discuss this in more detail with our development team.
Ian Andolina - 2014-07-01 14:55:46 +0200
Created attachment 645 HTML Matlab report This is the report from the Matlab graphics updater run on my fieldtrip folder (that already contains the double(gcf) fixes), there are 132 issues, 38 of which are deemed "high impact". Some of these will be in contributed code, not FT directly...
Jörn M. Horschig - 2014-07-01 15:09:23 +0200
thanks a lot, that makes life a lot easier for us. Seems like we need to add some version checking for various things, but nothing dramatic. Most crucially we need to take care to not treat figure handles as numbers anymore. And some functionality is actually finally like I would have wanted/expected it anyway (e.g. uipanel behaviour or getframe). Now, I need to find out whether we got some Matlab14b flying around in our institute...
Jörn M. Horschig - 2014-07-16 14:01:24 +0200
I added some text to the code guidelines to remind future-us of this: http://fieldtrip.fcdonders.nl/development/guidelines/code?&#figure_handles_and_handle_graphics_2 Most importantly, I wrote down that all issues and fixes that we encounter in light of this bug will be posted to above linked code guidelines. We should not forget to do so.
Jörn M. Horschig - 2014-09-03 14:24:12 +0200
I checked the proposed fixes by the matlab report. Unfortunately, the substitutes (e.g. initiating a graphics handles as gobject instead of []) is not backwards compatible with older matlab version. Thus, we require fallback functions in case the matlab version predates 2014b. The most important change is indeed the change of graphic handles from being doubles to objects, thus we are not allowed to set a handle to 0 or 1 anymore. Apart from that, the report states mostly things concerning user interfaces (i.e. we need to check that they look alright, e.g. uipanels are now independent of axes and can stretch into nearby subplots). In the meanwhile, I will fix the 'Name' issue now by casting gcf to a double, which Ian reported to be compatible.
Jörn M. Horschig - 2014-09-03 15:59:08 +0200
svn ci ft_layoutplot.m ft_multiplot*.m ft_singleplot*.m ft_topoplotCC.m private/topoplot_common.m ft_databrowser.m -m "bugfix #2461 - figure handles for naming are now cast to double do be HG2 compatible" Sending ft_databrowser.m Sending ft_layoutplot.m Sending ft_multiplotER.m Sending ft_multiplotTFR.m Sending ft_singleplotER.m Sending ft_singleplotTFR.m Sending ft_topoplotCC.m Sending private/topoplot_common.m Transmitting file data ........ Committed revision 9778.
Robert Oostenveld - 2014-10-16 12:16:52 +0200
FYI, matlab2014b just arrived at the Donders. I installed it on my local (mac) machine, and soon we'll also get it on windows and linux. at startup, it states: "MATLAB R2014b introduces a new MATLAB graphics system. New default colors, fonts, and styles make your data easier to interpret. ... Some existing graphics-related code may need to be revised to work in R2014b." looking forward to revising FT plotting functions :-(
Robert Oostenveld - 2014-10-17 14:49:14 +0200
(In reply to Robert Oostenveld from comment #10) I noticed test_bug2096 failing due to ft_sourceplot/ft_plot_ortho dealing with handles as numbers, whereas in matlab2014a they are objects. This is a partial fix, there is more to be done. mac011> svn commit plotting/ft_plot_ortho.m Sending plotting/ft_plot_ortho.m Transmitting file data . Committed revision 9909.
Robert Oostenveld - 2014-10-18 18:02:23 +0200
(In reply to Robert Oostenveld from comment #11) Further with test_bug2096, I made some changes in ft_sourceplot. mac011> svn commit ft_sourceplot.m Sending ft_sourceplot.m Transmitting file data . Committed revision 9914. The underlying functions are still not fully compatible with hg2, which can be noticed if you click in an ortho and it tries to update.
Eelke Spaak - 2014-10-20 09:20:32 +0200
(In reply to Robert Oostenveld from comment #12) /trunk/ft_sourceplot.m r9914 line 1324: ft_plot_ortho(opt.ana, 'transform', eye(4), 'location', opt.ijk, 'style', 'subplot', 'parents', tmph, 'doscale', false, 'clim', opt.clim); This variable tmph is undefined, and so ft_sourceplot breaks since this commit. Can I replace it with [h1 h2 h3].*opt.update?
Robert Oostenveld - 2014-10-20 09:42:09 +0200
(In reply to Eelke Spaak from comment #13) No, you should not replace it with [h1 h2 h3].*opt.update, as that is precisely what broke in HG2/2014b. Figure handles are no numbers any more, so mathematical operations do not apply. There should have been a section tmph = [h1 h2 h3]; tmph(~opt.update) = 0; which I forgot to add for the ana case. mac011> svn commit ft_sourceplot.m Sending ft_sourceplot.m Transmitting file data . Committed revision 9920.
Nicholas Peatfield - 2014-10-21 13:14:35 +0200
I think this is directly related to the HG2 issue "bug" so I thought i'd post it here. The cfg.interactive = "yes" when using any of the plotting functions option no longer works for me (2014b 10.10 OSX). With the latest ft all the plotting functions seem to work fine.
Robert Oostenveld - 2014-10-30 16:52:17 +0100
Thanks for reporting the specific bug. There have been significant changes in the graphics in matlab2014b, which we are aware of. It will take time to resolve these issues. I hope that you can revert to matlab2014a for the time being. See also bug 2750. *** This bug has been marked as a duplicate of bug 2750 ***
Robert Oostenveld - 2014-10-30 16:54:01 +0100
(In reply to Robert Oostenveld from comment #16) Bummer, I meant to post that as comment to bug 2750 and revert it to this one. Sorry, let me try again.
Robert Oostenveld - 2014-10-30 16:55:00 +0100
*** Bug 2750 has been marked as a duplicate of this bug. ***
Tilmann Sander-Thommes - 2014-10-31 15:50:34 +0100
R2014b: I had it in topoplot_common as "abs not defined for matlab.graphics.axis.Axes" I do not understand, why Mathworks did not provide a compatibility switch to make a smooth transition. One should tell them that. I gues SPM community will be delighted too :-(( Cheers, Till
Robert Oostenveld - 2014-11-12 13:56:06 +0100
(In reply to Tilmann Sander-Thommes from comment #19) The specific pattern causing a problem is dataname = num2str(gca); dotpos = findstr(dataname,'.'); dataname = ['DATA' dataname(1:dotpos-1) 'DOT' dataname(dotpos+1:end)]; setappdata(gcf,dataname,varargin(1:Ndata)); which happens multiple times in 189-145> grep -l DATA.*dot *.m */*.m ft_singleplotER.m ft_singleplotTFR.m private/topoplot_common.m This change is a first attempt of Jim to deal with it U ft_singleplotTFR.m Updated to revision 9944.
Robert Oostenveld - 2014-11-12 14:52:32 +0100
(In reply to Robert Oostenveld from comment #20) I changed the three functions, and just now also added the reverse mapping. 189-145> svn commit ft_singleplotER.m ft_singleplotTFR.m private/topoplot_common.m Sending ft_singleplotER.m Sending ft_singleplotTFR.m Sending private/topoplot_common.m Transmitting file data ... Committed revision 9951.
Jörn M. Horschig - 2014-11-12 14:53:18 +0100
made a fix to the databrowser so that buttons do work again: Sending ft_select_range.m Transmitting file data . Committed revision 9949.
Jörn M. Horschig - 2014-11-12 15:11:50 +0100
svn ci rejectvisual_summary.m -m 'made rejectvisual summary mode working in matlab2014b' Sending rejectvisual_summary.m Transmitting file data . Committed revision 9953.
Jörn M. Horschig - 2014-11-12 15:57:09 +0100
databrowser fix 2: svn ci ft_databrowser.m -m 'bugfix - databrowser fixed for matlab 2014b' Sending ft_databrowser.m Transmitting file data . Committed revision 9957.
Robert Oostenveld - 2014-11-12 16:57:05 +0100
We addressed this issue in our bug binge. Various people have been testing different sections of the code, with a focus on whether there is an error (i.e. crash in the code) It seems that most functions now do not result in errors any more. However, the interaction (selection of electrodes and time/frequency/channel windows) is not fully working yet. So we cannot close the bug yet. roboos ft_topoplotCC.m -> DONE arjsto ft_layoutplot.m -> DONE jorhor ft_rejectvisual.m -> partially done (summary) jorhor ft_databrowser.m -> DONE jimher ft_multiplotTFR.m -> DONE jorhor ft_neighbourplot.m -> works partially, but there is still an issue with the callbacks nielam ft_movieplotTFR.m -> DONE nielam ft_movieplotER.m -> DONE nielam ft_multiplotER.m -> DONE tzvpop ft_multiplotCC.m -> DONE tzvpop ft_topoplotIC.m -> DONE tzvpop ft_connectivityplot.m -> DONE jansch ft_sourceplot.m -> DONE roboos ft_singleplotTFR.m -> DONE roboos ft_singleplotER.m -> DONE roboos ft_topoplotER.m -> topoplot_common.m -> DONE arjsto ft_topoplotTFR.m -> DONE roboos ft_clusterplot.m -> DONE
Jörn M. Horschig - 2014-11-12 20:32:30 +0100
ft_rejectvisual surprisingly works in the other modes as well without further adjustments
Jörn M. Horschig - 2014-11-12 20:36:54 +0100
btw, sure that the interactive selection does not work? I thought I fixed that when fixing ft_select_range. I quickly checked with some TFR data and it works fine. Not sure about source data/plotting though. I will work with 2014b from now on to see if there are more issues popping up. Maybe others can do the same and report back in detail on what is still not functioning.
Jim Herring - 2014-11-13 15:48:19 +0100
fixed a small bug related to using colormap('default') in ft_sourceplot. With all other colormaps you can assign colormap(COLORMAP) to a variable, but not when COLORMAP is 'default'. I changed it so that first the colormap is updated and then the current colormap is assigned to a variable.
Jörn M. Horschig - 2014-11-20 16:24:38 +0100
(In reply to Jörn M. Horschig from comment #7) we should remind ourselves to update the guidelines with all the decisions we made during the bug binge!
Jim Herring - 2014-11-27 12:08:46 +0100
Using ft_rejectartifact with cfg.artfctdef.zvalue.interactive = 'yes' produces the following error when pressing the buttons in the gui: No appropriate method, property, or field Key for class matlab.ui.eventdata.ActionData. Error in ft_artifact_zvalue>parseKeyboardEvent (line 1079) key = eventdata.Key; Error in ft_artifact_zvalue>keyboard_cb (line 680) key = parseKeyboardEvent(eventdata); Error using waitfor Error while evaluating UIControl Callback
Robert Oostenveld - 2015-02-27 08:57:08 +0100
(In reply to Jim Herring from comment #30) the problem with cfg.artfctdef.zvalue.interactive has been resolved as part of bug 2857.