Back to the main page.

Bug 3316 - add sampling rate information to artifact structures

Status NEW
Reported 2017-06-21 11:35:00 +0200
Modified 2017-06-21 13:50:39 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: All
Operating System: All
Importance: P5 enhancement
Assigned to:
URL:
Tags:
Depends on:
Blocks:
See also:

Thomas Hartmann - 2017-06-21 11:35:55 +0200

hi, i would like to propose adding a field to the artifact definitions produced by the ft_artifact and ft_databrowser function. the ft_rejectartifact function could then check whether the artifact and data sampling rate match. if this is not the case, an error could be thrown or the artifacts' boundaries, expressed in samples, could be converted automatically. there are certain use cases in which data is resampled during the analysis process. applying ft_rejectartifact to data using artifact definitions that do not match in their sampling rate is not detected (and not detectable!) at the moment. this is a "silent error" that goes undetected and might have a sever impact on the analysis. the use case becomes apparent when analyzing data recorded with a high sampling rate (e.g., 10kHz), which is necessary to analyze phenomena like the FFR. doing artifact rejection on that kind of data is very slow and takes up a lot of RAM. downsampling the data for this process helps a lot without any sacrifice to the accuracy of neither automatic nor manual artifact identification as artifacts are not that high in frequency. however, the resulting artifact definitions must eventually be applied to the original data. i would be happy to provide a prototype implementation for discussion if this proposal is seen as sensible by the developers. best, thomas


Robert Oostenveld - 2017-06-21 12:40:56 +0200

I understand and appreciate the problem, but am not sure if this is the best solution. There are other cases where artifact rejection would result in silent errors. E.g. after appending and/or after reconstructing sampleinfo. Perhaps another (not yet well thought trough) idea: how about adding "sampleinfoorig" when resampling?


Thomas Hartmann - 2017-06-21 13:50:39 +0200

(In reply to Robert Oostenveld from comment #1) thanks for the quick reply, robert! i think it is a good idea to tackle as many silent-error cases at the same time and, if possible, with on parsimonious solution. so, having something like sampleinfoorig in the structure after resampling would be good, i guess. however, we would need to make sure that all the other functions that rely on sampleinfo would honor this new field. and apart from that, wouldn't we still need some info in the artifact definition telling us about the "origin" of it, i.e. what "sampleinfo" it was created from?