Back to the main page.
Bug 2106 - ft_rejectvisual: when cfg.mode = 'summary', plotting topographies using the 'trial plotter' results in an error
| Status | CLOSED FIXED |
| Reported | 2013-04-11 13:59:00 +0200 |
| Modified | 2014-01-29 13:39:51 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Roemer van der Meij |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=1477 |
Roemer van der Meij - 2013-04-11 13:59:33 +0200
(quick report, found during the toolkit) (just like the previous 2 bugs actually ;))
Jan-Mathijs Schoffelen - 2013-05-06 19:43:29 +0200
Hi Roemer, Can this be reproduced? Otherwise I suggest to wontfix this.
Eelke Spaak - 2013-06-03 10:33:46 +0200
Cannot reproduce here (with CTF275 or neuroscan16 data), so marking as worksforme. Feel free to reopen if it turns out to be a real bug :)
Roemer van der Meij - 2013-06-05 11:09:41 +0200
It can be replicated by: load('/home/common/matlab/fieldtrip/data/ftp/tutorial/cluster_permutation_freq/dataFIC.mat') cfg = []; cfg.layout = 'CTF151.lay'; cfg.method = 'summary'; ft_rejectvisual(cfg,dataFIC); And then plotting a random trial by putting a trial number in the 'plot trial' box and hitting enter. Error ending up in ft_checkdata. Assigning to me.
Roemer van der Meij - 2013-06-05 11:58:08 +0200
In ft_checkdata's raw2timelock subfunction, the time axis is being reconstructed after counting the number of samples pre and postzero. The error is caused by the reconstructed time-axis having 1 sample less than the actual time-axis, thus causing an indexing error later on. The miscounting itself is caused by numerical inaccuracies in the time-axis. Sampling/resampling rate of the tutorial data is 300Hz, and there is some machine noise surrounding the time-steps. Reconstructing the time-axis by mint:mean(diff(time)):maxt skips the last sample, because it is less than mean(diff(time)) away from the previous sample. So, in short, the problem is caused by an 'irrational' fractional time-step (infinite decimals). I guess we deal with this kind of thing in other places as well, and I'm not sure whether this is the appropriate place for a 'fix'. Note, this is not related to bug 1477.
Roemer van der Meij - 2013-06-05 12:06:03 +0200
(additional note, also fails when reading in tutorial data anew, so issue not related to old preprocessed data)
Roemer van der Meij - 2013-06-05 16:02:00 +0200
After discussing this in the ft-meeting, it became clear that the code where the sample was lost was part of the fix for bug 1477. Because the underlying issue was related to a 'irrational' sampling rate and/or numerical error in the time-axis, I tried to find a way to correct for this. However, any 'irrational' sampling rate (either truly irrational like 1/3 or numerically close to irrational like 1/278) will always lead to difference in time-steps of at least eps. I.e.: numel(unique(diff(time)))~=1. I do not think there is a way around this, unless we want to set a limit on the precision of the sampling rate. However, this brings back *dumdumdummmm* the fsample field from deprecation. If we decide to at some point, a time-axis fix can be implemented in ft_datatype_raw's fixtimeaxes subfunction. Considering it unlike we would ever do that (right?), I fixed the problem with irrational sampling rates in raw2timelock, ft_checkdata. Setting as fixed, more info in bug1477.
Eelke Spaak - 2013-06-05 16:09:49 +0200
I am strongly in favour of bringing back fsample! It should never have been deprecated in the first place. It just makes life so much easier. As said in the meeting, I always add it back anyway, because I like to be able to do stuff like cfg = []; cfg.toilim = [1 2-1/data.fsample]; data = ft_redefinetrial(cfg, data); to select exactly 1s of data (speeds up fft tremendously).
Jan-Mathijs Schoffelen - 2013-06-05 16:11:33 +0200
hehehe, I always do: cfg = []; cfg.toilim = [1 2-mean(diff(data.time{1}))]; data = ft_redefinetrial(cfg, data); This also speeds up the fft ;-)
Roemer van der Meij - 2013-06-05 16:25:45 +0200
or just do: cfg.padding = ceil(max(cellfun(@numel,data.time))./data.fsample); freq = ft_freqanalysis(cfg,data) To get a nice integer multiples in 1 freq-axis ;). @Jorn: hint! ;p Actually, if you're aiming for fast fft's, shouldn't it be a power of 2? cfg.padding = 2^nextpow2(max(cellfun(@numel,data.time))) ./ data.fsample;
Roemer van der Meij - 2013-06-13 10:38:50 +0200
fsample we love you! #OccupyPreprocessing