Back to the main page.
Bug 2830 - error in ft_sourcestatistics (spm_bwlabel CONN must be 6, 18 or 26)
| Status | CLOSED FIXED |
| Reported | 2015-02-09 11:27:00 +0100 |
| Modified | 2015-02-11 10:40:36 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eelke Spaak - 2015-02-09 11:27:57 +0100
The following error occurs when doing source statistics on 3D volume data, using code that still worked I think last week: Error using spm_bwlabel spm_bwlabel: CONN must be 6, 18 or 26 Error in clusterstat (line 189) [posclusobs, posnum] = spm_bwlabel(tmp, 2*numdims); % use spm_bwlabel for 2D/3D data to avoid usage of image toolbox Error in ft_statistics_montecarlo (line 358) [stat, cfg] = clusterstat(cfg, statrand, statobs); Error in ft_sourcestatistics (line 191) [stat, cfg] = statmethod(cfg, dat, design); Note that the input source still has a source.avg.
Eelke Spaak - 2015-02-09 11:29:50 +0100
(In reply to Eelke Spaak from comment #0) Sorry, the input is not 3D volume data, but source data with .pos
Eelke Spaak - 2015-02-09 11:32:03 +0100
In clusterstat.m:189, when breaking on this error, I find that K>> size(tmp) ans = 13662 1 which I think should have been 3D at this point. Also, numdims==2.
Eelke Spaak - 2015-02-09 11:34:19 +0100
(Line numbers are(In reply to Eelke Spaak from comment #2) Should be line 182, not 189 (I had some uncommitted local changes which I now reverted for the purposes of debugging this issue.)
Eelke Spaak - 2015-02-09 11:39:16 +0100
The error persists if I explicitly convert the input structures to volume before calling ft_sourcestatistics.
Robert Oostenveld - 2015-02-09 11:43:09 +0100
can you do cfg.debug='saveonerror' and send me the mat file?
Eelke Spaak - 2015-02-09 11:47:37 +0100
(In reply to Robert Oostenveld from comment #5) Would love to, but if I specify this I still get the same error and it does not look like any file is generated? Should it pop up in the current working directory?
Robert Oostenveld - 2015-02-09 11:54:28 +0100
(In reply to Eelke Spaak from comment #6) saveonerror should be handled by a pre/postamble and implement a try-catch. If it detects an error, it should save it to a file in /tmp and print the file name to screen. After that, the error is re-thrown. If saveonerror also does not work, that makes for a 2nd bug. Please give me the full input that you pass to the function from your script (e.g. in common/temporary).
Eelke Spaak - 2015-02-09 11:54:36 +0100
Unfortunately I'm under some pressure to get some figures rather quickly, so for now I've reverted my working copy using: svn merge -r HEAD:10136 . This results in normal operation again. Note that before that I reverted to revision 10137 (the big ft_selectdata) commit. In this case I did not get the mentioned error, but the code was still not working correctly: it seems that the data structure inside clusterstat() was again a 1D-vector (and so it was doing inefficient clustering using connectivity matrices) rather than a 3D array (which allows efficient image-based clustering).
Eelke Spaak - 2015-02-09 11:58:49 +0100
(In reply to Robert Oostenveld from comment #7) It's there now (/home/common/temporary/bug2830). I think the code snippet I added should reproduce the bug. It's almost certainly not dependent on the statfun I'm using, but in any case I'm providing that one as well.
Thomas Hartmann - 2015-02-09 16:05:57 +0100
hey, i have the same problem here. and i think i found the problematic piece of code: https://github.com/fieldtrip/fieldtrip/commit/8bcdb8f3c82bb261e98a09b124e76287371e9d25 line 148 in ft_statistics_montecarlo now looks for a dim field. if it finds one, it is assumed that the data is 3D. the problem is that ft_freqstatistics always adds a dim field to the input structures (line 134). cheers, thomas
Robert Oostenveld - 2015-02-10 15:23:14 +0100
I just started looking at it and can reproduce it with the provided data. I also was ale to reproduce the saveonerror not working: I just reported that in a separate bug 2832.
Robert Oostenveld - 2015-02-10 16:22:57 +0100
I found and fixed it. It had to do with cfg.dim=[npos 1] rather than cfg.dim=[nx ny nz] I realise that generic n-dimensional clustering of regular source data is not supported at the moment. E.g. what if it is a volumetric representation with source.dim = [10 1 1], i.e. a 3D volume that represents a strip of voxels? Or what if the dimensions are voxels [nx ny nz] by time by frequency? mac011> svn commit Sending ft_sourcestatistics.m Sending ft_statistics_montecarlo.m Sending private/clusterstat.m Adding test/test_bug2830.m Transmitting file data .... Committed revision 10192.
Eelke Spaak - 2015-02-10 16:30:35 +0100
(In reply to Robert Oostenveld from comment #12) I don't know too much about the scaffolding around it, but I know that bwlabel supports data of arbitrary dimensionality (and hence arbitrary neighbourhood).
Eelke Spaak - 2015-02-10 16:30:57 +0100
(In reply to Eelke Spaak from comment #13) bwlabeln that it is (note the n)
Robert Oostenveld - 2015-02-10 16:31:56 +0100
(In reply to Eelke Spaak from comment #14) Indeed. When ndim>3 it should switch to that (from the image processing toolbox).
Robert Oostenveld - 2015-02-10 16:49:24 +0100
the code was already in place in the low-level clusterstat, but in ft_sourcestatistics I had to add cfg.origdim to enable it. Seems to be working fine (at least it runs, I did not check whether it makes sense). mac011> svn commit Sending ft_sourcestatistics.m Sending private/clusterstat.m Sending test/test_bug2830.m Transmitting file data ... Committed revision 10193.
Robert Oostenveld - 2015-02-10 16:50:11 +0100
fixed.