Back to the main page.
Bug 2886 - ft_freqstatistics crashes for freq/freq_time data without channels
| Status | CLOSED INVALID |
| Reported | 2015-04-30 14:46:00 +0200 |
| Modified | 2019-08-10 12:30:59 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Philipp Ruhnau - 2015-04-30 14:46:30 +0200
Created attachment 709 example of freqstatistic crash without channels present Hey there, i have run into a problem I didn't have on a previous version of fieldtrip. when i want to use cluster correction on time-freq data with only one channel (like average graph mapping or global field) the function crashes in the process (findcluster). I think the missing spatial dimension is not properly detected (ahem, detect something missing...). Anyway, I attach a little example script that shows the error. One can circumvent this by adding a singular channel dimension, see my code. but this is not so nice, either the help of ft_freqstatistics needs amending or a fix (reshape or so) needs to be done. tried this with a very recent fieldtrip (beginning of the week). it was working like half a year back. ciao philipp NB1: by the way ft_checkdata crashes without a label for structures of dimord 'time_freq', which in my view wouldn't need a label field, right? ... NB2: ft_singleplotTFR will not plot a stat structure which is (correcly) containing a dimord 'freq_time' without a singleton channel dimension, because a label field is required as input because of NB1... circulus vitiosus
Robert Oostenveld - 2015-04-30 18:08:01 +0200
Created attachment 710 updated script thanks for the clear script. some of the problems are caused by your lines where you %% now set up fake ft structures ft1 = []; ft1.powspctrm = set1; ft1.dimord = 'subj_freq_time'; ft1.freq = freqArray; ft1.time = timeArray; % for some reason we also need to define a label otherwise checkdata % crashes ft1.label = {'average'}; which fail to create a fully supported data structure. It is surprising that you get this far, since >> ft_datatype(ft1) ans = freq although ft_datatype_freq states that label is a required field (and hence chan should be part of the dimord). If I make the data as subj_chan_freq_tiume with a single chan, it works "better". At least I get through ft_singleplotTFR(cfg,stats). In your lines 72-76 I then use figure; imagesc(timeArray, freqArray, squeeze(stats.stat)) set(gca, 'YDir', 'normal') alpha(double(squeeze(stats.mask))) title('Yeah alpha effect') to make it work (squeezing out the singleton dimension). Could you try again with attached version and see whether your (perceived?) problem persists? If this solves it, then I think it is just an incorrect data handling. With your input data it should probably have given an explicit error early on.
Philipp Ruhnau - 2015-04-30 18:24:21 +0200
(In reply to Robert Oostenveld from comment #1) hey Robert, that is what I do from lines 123 sure that does work, I was just confused for 3 reasons 1) it did work in previous ft versions (who knows whether that was right) 2) the parametric (analytic) option does work. yet not the plotting, and nobody in the audience has any idea... 3) why would there be a necessity for a channel dimension? ok, i guess if you just define it that way i have to live with it, I find it simply uncomfortable to reshape and squeeze. so yeah, I guess one option is to stop the user (me) earlier and tell me what I'm doing wrong (but also adapt the help) or somehow ignore the non existent dimension. or reshape the data in ft_checkdata assuming a single dimension when there is only one label? dunno. you can also just ignore this, in the end it is minor and whoever reaches this specific problem did some data formatting himself and will figure out why cheers philipp
Robert Oostenveld - 2015-04-30 21:04:56 +0200
(In reply to Philipp Ruhnau from comment #2) it is in general not possible for us to predict how FT functions behave on unpredictable input data structures. If the structures are close to ones that are supported, it might work, but it might as well not work. Also "not working" might change over time, since we don't put efforts in backward compatibility for unsupported functionality. The ft_datatype_xxx functions describe (and define) the supported data structures. Furthermore, http://www.fieldtriptoolbox.org/faq/how_are_the_various_data_structures_defined lists the various structures and (some) functions that work on them. Please add there on the wiki if you have suggestions for improving general documentation.