Back to the main page.

Bug 2554 - ft_appenddata does not copy fsample to the output data structure

Status CLOSED INVALID
Reported 2014-05-01 08:45:00 +0200
Modified 2019-08-10 12:28:20 +0200
Product: FieldTrip
Component: preproc
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P5 normal
Assigned to:
URL:
Tags:
Depends on:
Blocks:
See also:

Eric Maris - 2014-05-01 08:45:01 +0200

The summary says it all. I think this is inconvenient behavior because one cannot run e.g. ft_freqanalysis on the appended data. If the data can be appended then they must have the same fsample, and so the fsample should go to the output structure.


Eelke Spaak - 2014-05-01 09:07:07 +0200

(In reply to Eric Maris from comment #0) Hi Eric, I think ft_freqanalysis should work when the input data does not have an fsample field. The sampling rate is implicitly represented in the time axis. E.g., the following works fine for me: data = []; data.label = {'a'}; data.time = {0.001:0.001:1}; data.trial = {randn(1,1000)}; cfg = []; cfg.method = 'mtmfft'; cfg.taper = 'hanning'; freq = ft_freqanalysis(cfg, data); Does this example give an error on your end?


Eelke Spaak - 2014-05-01 09:30:24 +0200

(In reply to Eric Maris from comment #0) Having said that, I do agree that it would be good to copy over fsample. We have had a few discussions about this in the FT meeting, and the general opinion was that fsample should be deprecated/removed, as the same info is represented in the time axis. However, as the time axis occasionally is not exactly spaced with a rational number (because of floating point blabla), fsample in my opinion does give a convenient bit of extra information. Therefore I have tended to disagree with this general opinion :) I suspect the change was made in r9336 (https://code.google.com/p/fieldtrip/source/diff?spec=svn9336&r=9336&format=side&path=/trunk/ft_appenddata.m) by Robert (adding as cc); at line 225 in that revision now the output argument is explicitly initialized as []. Previously I guess the fsample was implicitly carried over from one of the input arguments. Robert, should we add 'fsample' to the 'copyfield' array (line 298)? I would find it convenient, but it would not be in line with deprecating fsample of course.


Robert Oostenveld - 2014-05-01 11:50:59 +0200

From the documentation: % FT_DATATYPE_RAW describes the FieldTrip MATLAB structure for raw data % % The raw datatype represents sensor-level time-domain data typically % obtained after calling FT_DEFINETRIAL and FT_PREPROCESSING. It contains % one or multiple segments of data, each represented as Nchan X Ntime % arrays. % % An example of a raw data structure with 151 MEG channels is % % label: {151x1 cell} the channel labels (e.g. 'MRC13') % time: {1x266 cell} the timeaxis [1*Ntime double] per trial % trial: {1x266 cell} the numeric data [151*Ntime double] per trial % sampleinfo: [266x2 double] the begin and endsample of each trial relative to the recording on disk % trialinfo: [266x1 double] optional trigger or condition codes for each trial % hdr: [1x1 struct] the full header information of the original dataset on disk % grad: [1x1 struct] information about the sensor array (for EEG it is called elec) % cfg: [1x1 struct] the configuration used by the function that generated this data structure % % Required fields: % - time, trial, label % % Optional fields: % - sampleinfo, trialinfo, grad, elec, hdr, cfg % % Deprecated fields: % - fsample % ... fsample has been deprecated for quite some time, as it represents the same information as represented in the time axis. As a general rule: information should not be represented twice, as that allows different field trip functions to use that information in different manners, resulting in possible inconsistencies (in code and in outcome of analyses).


Robert Oostenveld - 2014-05-01 11:57:00 +0200

The following functions seem still to be using data.fsample mac011> grep -l =.*\\.fsample *.m fieldtrip2fiff.m ft_appenddata.m ft_artifact_ecg.m ft_artifact_tms.m ft_componentanalysis.m ft_connectivityanalysis.m ft_connectivitysimulation.m ft_databrowser.m ft_dipolesimulation.m ft_freqanalysis.m ft_freqanalysis_mvar.m ft_freqsimulation.m ft_interpolatenan.m ft_megrealign.m ft_mvaranalysis.m ft_preprocessing.m ft_redefinetrial.m ft_rejectartifact.m ft_rejectcomponent.m ft_removetmsartifact.m ft_resampledata.m ft_timelockanalysis.m All functions should pass the input data through ft_checkdata, which presently will still always ensure that data.fsample is present (see line 142 of ft_datatype_raw, which si called by ft_checkdata). I.e. FieldTrip is still quite lenient with the use of data.fsample. In the future (if someone has time to go over all the code), data.fsample will not be used anymore in the FT code and it will permanently be removed from the raw data structure.


Robert Oostenveld - 2019-08-10 12:28:20 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue describing the issue on https://github.com/fieldtrip/fieldtrip/issues.