Back to the main page.
Bug 1069 - singleplotTFR cannot plot mask of 1xNxM
| Status | CLOSED FIXED |
| Reported | 2011-10-24 12:42:00 +0200 |
| Modified | 2012-08-23 14:02:08 +0200 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P1 normal |
| Assigned to: | Jörn M. Horschig |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Jörn M. Horschig - 2011-10-24 12:42:29 +0200
The problem I encountered is that the singular dimension of the datamatrix will be removed in line 376, leading to an NxM matrix for plotting (that should be fine). The mask parameter *has* to be 1xNxM though, else the code will break around line 350, when it subselects the channel from the parameter. However, the mask-parameter will never be squeezed, resulting in a mismatch between data and mask matrix, ultimately crashing in ft_plot_matrix, line 208. Possible solutions: Either squeeze(mask) or subselect mask(channel, :, :) when calling ft_plot_matrix (Note that singleplotTFR works on one channel only, always) If one of the bug bosses confirms this, I'll change accordingly
Robert Oostenveld - 2011-10-24 14:50:20 +0200
ft_singleplotTFR constructs the mask in 342-374, where for the different options the mask is 2-D or 3-D if I understand the code correctly: line 349, 359, 364, 369 are 2-D line 351, 353 are 3-D It does not make sense that after the "end" on line 374 the mask can be either 2-D or 3-D, it should always have the same dimensions as datamatrix that is made on line 376. Probably squeezing line 351 and 353 is the best solution. I think that in ft_plot_matrix the following should hold if ~isempty(highlight) && ~isequal(size(highlight), size(cdat)) error('the dimensions of the highlight should be identical to the dimensions of the data'); end Can you add that to the code? Could you also improve the documentation of ft_plot_matrix a bit? And I suggest to add the same check on dimensions to ft_plot_vector, which is probably sensitive to the same vulnerability of input args.
Jörn M. Horschig - 2011-11-23 10:57:24 +0100
For ft_plot_vector, I am not sure what is masked there. Is it correct that the mask must have the same size as vdat? I included it like this, but this feature is not used in any ft_ function I extended test_ft_plot_vector accordingly (but does Matlab plot at all when there it's w/o GUI? Do plotting test functions make sense?) svn ci ft_singleplotTFR.m plotting/ft_plot_matrix.m plotting/ft_plot_vector.m plotting/test/test_ft_plot_vector.m -m "bugfix-#1069-singleplotTFR can handle masks correctly now. extended documentation of ft_plot_matrix and ft_plot_vector. Fixed highlighting in ft_plot_vector and extended testscript accordingly" Sending ft_singleplotTFR.m Sending plotting/ft_plot_matrix.m Sending plotting/ft_plot_vector.m Sending plotting/test/test_ft_plot_vector.m Transmitting file data .... Committed revision 4797.
Robert Oostenveld - 2011-11-23 13:09:18 +0100
(In reply to comment #2) > For ft_plot_vector, I am not sure what is masked there. Is it correct that the > mask must have the same size as vdat? yes, it should indeed be of equal size. Looking at the code I now realize that "mask" equals "highlight" in ft_plot_vector. The significant part (i.e. stat.mask) in ft_muliplotER is (or should be) indicated with a grey box behind it. So there is some naming confusion. It would be good to mention that highlight serves the same purpose (i.e. make something more salient compared to something else).
Jörn M. Horschig - 2011-11-23 14:42:04 +0100
hm, I don't follow. mask is not the same as highlight, it should be the exact opposite, shouldn't it? Further, is this documentation not sufficient: % highlight = a logical vector of size Y, where 1 means that the % corresponding values in Y are highlighted % (according to the highlightstyle)